On Jan 13, 2015, at 6:07 PM, David E. Wheeler da...@justatheory.com wrote:
Pod::Simple 3.29 is on its way to CPAN now. I’m going to apply the change
proposed in the Pod::Simple can treat binary as pod due to
liberal/inconsistent regexp patterns thread now, and once you have the
EBCDIC and
On 01/12/2015 01:27 PM, Karl Williamson wrote:
On 01/12/2015 12:49 PM, David E. Wheeler wrote:
On Jan 12, 2015, at 11:46 AM, Karl Williamson
pub...@khwilliamson.com wrote:
I ran across this link, but didn't see what action was taken on it:
http://www.w3.org/TR/newline
Pardon my ignorance.
On Jan 13, 2015, at 10:31 AM, Karl Williamson pub...@khwilliamson.com wrote:
What Perl does to handle this is to simple swap the NEL and LF code points.
That makes \n mean NEL instead of LF. Apparently LF is unused in EBCDIC
applications, so it works. There is official support for this
On 01/12/2015 06:25 AM, Shawn H Corey wrote:
On Sun, 11 Jan 2015 20:57:26 -0700
Karl Williamson pub...@khwilliamson.com wrote:
To be clear, I think that assuming 1252 when there is no =encoding
line is a good idea. But I'm leery of overriding an actual =encoding
line.
Agreed.
I could
that could be =encoding ISO-8859-1.
If we *were* to assume CP1252 for Latin-1, I would want it to be consistent
with the precedent set by the W3C. Sean supplied this link:
http://www.w3.org/TR/encoding/#names-and-labels
Here’s the list of labels that they translate to Windows-1252:
ansi_x3.4-1968
it and not be overridden by us. Perhaps
that could be =encoding ISO-8859-1.
If we *were* to assume CP1252 for Latin-1, I would want it to be consistent
with the precedent set by the W3C.
That sounds reasonable.
Sean supplied this link:
http://www.w3.org/TR/encoding/#names-and-labels
Here’s
On 01/12/2015 12:49 PM, David E. Wheeler wrote:
On Jan 12, 2015, at 11:46 AM, Karl Williamson pub...@khwilliamson.com wrote:
I ran across this link, but didn't see what action was taken on it:
http://www.w3.org/TR/newline
Pardon my ignorance. Does that mean that `s/Latin-1/CP1252/g` could be
On 01/10/2015 11:35 PM, David E. Wheeler wrote:
On Jan 10, 2015, at 5:48 PM, Sean Burke sbu...@cpan.org wrote:
Helleu, Pod pals!
Short version about Re: Assume CP1252-- I advise: yes, assume CP1252 where
technically you were expecting Latin-1.
Thanks for chiming in, Sean.
I agree
On 01/11/2015 11:01 AM, Karl Williamson wrote:
On 01/10/2015 11:35 PM, David E. Wheeler wrote:
On Jan 10, 2015, at 5:48 PM, Sean Burke sbu...@cpan.org wrote:
Helleu, Pod pals!
Short version about Re: Assume CP1252-- I advise: yes, assume
CP1252 where technically you were expecting Latin-1
Helleu, Pod pals!
Short version about Re: Assume CP1252-- I advise: yes, assume CP1252
where technically you were expecting Latin-1.
~~
Long version:
I don't normally pipe up about (or keep up with anything about) Pod
stuff, because it's yall's language now-- but since an issue of my
On Jan 10, 2015, at 5:48 PM, Sean Burke sbu...@cpan.org wrote:
Helleu, Pod pals!
Short version about Re: Assume CP1252-- I advise: yes, assume CP1252 where
technically you were expecting Latin-1.
Thanks for chiming in, Sean.
I agree completely, go for it!
Yes:
* assume that input
* Grant McLean gr...@mclean.net.nz [2015-01-07T18:47:49]
I also agree this is a good idea. None of the Latin-1 control
characters that CP1252 replaces with printable characters should be
appearing in POD anyway.
Seems safe, I think. At first, I thought, They're disjunct!! but then I
realized
Pod Peeps:
perlpodspec says:
* Since Perl recognizes a Unicode Byte Order Mark at the start of files
as signaling that the file is Unicode encoded as in UTF-16 (whether
big-endian or little-endian) or UTF-8, Pod parsers should do the same.
Otherwise, the character
13 matches
Mail list logo
