Re: RFC 216 (v1) POD should tolerate white space.
Frankly, I thought it was absurd when I first wrote it... but then I looked at again, and now I'm not so sure I dislike it! =head1 CHANGES =over 4 =item * Detailed implementation description =item * Add a new pragma 'varlock' for controlling the concurrencySNIP =back 4 =head1 DESCRIPTION Looks transparent to me! Cool. Recall that the P in "pod" stands for *plain*. If pod has a "problem", it is that the plainness is broken by the fact that markup tags can nest. But for that, parsing is easy--to some extent because of the notion of paragraphs. There are certainly other issues, such as people expecting it to be (as "powerful" as) HTML or troff, or that they think that translators can/should/do perform no magic inferring of proper formatting, and thus mark the danged document up until it is completely illegible. --tom
Re: RFC 216 (v1) POD should tolerate white space.
On Wed, Sep 13, 2000 at 07:18:15AM -, Perl6 RFC Librarian wrote: POD should tolerate white space where it now requires empty lines I used to trip over this problem alot in my code. In fact, patches #5507 and #5493 to perl were just about stripping whitespace out of POD, IIRC. I can't think any reason why POD tags require "\n" instead of /^\s*$/. I mean, there's some ludicrous cases of ambiguities: use constant for = 2; $foo =for + 2; Does $foo == 4 or is that a POD tag? Very contrived, I don't think this sort of thing will be a problem. I can't think of a time when I've ever put an '=' flush left. I'm sure this has come up on p5p before, but I can't find anything relevent in the archives. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #89: Electromagnetic energy loss
Re: RFC 216 (v1) POD should tolerate white space.
On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE POD should tolerate white space. I don't want any newlines needed at all, though I think I stand somewhat alone here. I don't like the emty space on my screen when I have to do things like (cut from see RFC 130): | |=head1 CHANGES | |=over 4 | |=item * | |Detailed implementation description | |=item * | |Add a new pragma 'varlock' for controlling the concurrency control. | |=back 4 | |=head1 DESCRIPTION | Where's the info? There's to much empty lines in there! One has to search for the info. It better be written as (be able to): |=head1 CHANGES | |=over 4 |=item * |Detailed implementation description | |=item * |Add a new pragma 'varlock' for controlling the concurrency control. | |=back 4 | |=head1 DESCRIPTION Or for the real compression freaks, no empty lines at all. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl5.005.03, 5.6.0 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 216 (v1) POD should tolerate white space.
On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: POD should tolerate white space. I don't want any newlines needed at all, though I think I stand somewhat alone here. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) I agree! I thought that was too radical to propose... I will think about adding that to the RFC -- -ken rich
Re: RFC 216 (v1) POD should tolerate white space.
I can't think any reason why POD tags require "\n" instead of /^\s*$/. Because then you can set $/ = "" and sail through a source file, of course! --tom
Re: RFC 216 (v1) POD should tolerate white space.
POD should tolerate white space where it now requires empty lines [...] =head1 IMPLEMENTATION Seems like it should be just a regexp stuck in somewhere I think this is a specific problem calling for a more general solution. I can think of two possible ones: 1. A standard library function to safely but forgivingly read in a "paragraph". I have cc'd perl6-stdlib since this strikes me as a sensible candidate for the standard library. 2. Allowing $/ (or its successor, perhaps set on a per-filehandle basis) to be a regular expression, not a string. (Surely there's an RFC on that somewhere.) Once either of those solutions is implemented, then then it's a simple matter for pod tools using it instead of $/ (or whatever). Since you made this proposal, would you be willing to pursue either of these options further? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 216 (v1) POD should tolerate white space.
H.Merijn Brand wrote: On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE POD should tolerate white space. I don't want any newlines needed at all, though I think I stand somewhat alone here. No newlines at all? That means you could write =head1 CHANGES =over 4 =item * Detailed implementation description =item * Add a new pragma 'varlock' for controlling the concurrency control. =back 4 =head1 DESCRIPTION for you example. -- John Porter We're building the house of the future together.
Re: RFC 216 (v1) POD should tolerate white space.
On Wed, 13 Sep 2000 10:19:38 -0400, John Porter [EMAIL PROTECTED] wrote: H.Merijn Brand wrote: On 13 Sep 2000 07:18:15 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE POD should tolerate white space. I don't want any newlines needed at all, though I think I stand somewhat alone here. No newlines at all? That means you could write =head1 CHANGES =over 4 =item * Detailed implementation description =item * Add a new pragma 'varlock' for controlling the concurrency control. =back 4 =head1 DESCRIPTION for you example. Are we being clever again? Rephrase: "No empty lines". I know you understood, but ... (no, I won't say it) -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl5.005.03, 5.6.0 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 216 (v1) POD should tolerate white space.
H.Merijn Brand wrote: Are we being clever again? Rephrase: "No empty lines". I know you understood, but ... (no, I won't say it) Frankly, I thought it was absurd when I first wrote it... but then I looked at again, and now I'm not so sure I dislike it! =head1 CHANGES =over 4 =item * Detailed implementation description =item * Add a new pragma 'varlock' for controlling the concurrency control. =back 4 =head1 DESCRIPTION Looks transparent to me! -- John Porter We're building the house of the future together.
Re: RFC 216 (v1) POD should tolerate white space.
On Wed, 13 Sep 2000 10:58:51 -0400, John Porter [EMAIL PROTECTED] wrote: H.Merijn Brand wrote: Are we being clever again? Rephrase: "No empty lines". I know you understood, but ... (no, I won't say it) Frankly, I thought it was absurd when I first wrote it... but then I looked at again, and now I'm not so sure I dislike it! =head1 CHANGES =over 4 =item * Detailed implementation description =item * Add a new pragma 'varlock' for controlling the concurrency control. =back 4 =head1 DESCRIPTION Looks transparent to me! Cool. Now someone has to write podlators that do not depend on $/ = ""; But it looks nice for a short piece of proza, but will it still be workable when: =head1 CHANGES =over 4 =item * Detailed ... This is some text describing this point into such detail that it extends more than one line. this text would be dealt with as pre-formatted in older podlators. What would it be now? =item * Next piece of info etc. You get the drift. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl5.005.03, 5.6.0 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 216 (v1) POD should tolerate white space.
Andy Dougherty wrote: 1. A standard library function to safely but forgivingly read in a "paragraph". I have cc'd perl6-stdlib since this strikes me as a sensible candidate for the standard library. I like this idea a lot. It would work very well with my RFC 79. 2. Allowing $/ (or its successor, perhaps set on a per-filehandle basis) to be a regular expression, not a string. (Surely there's an RFC on that somewhere.) This is a good idea too, and should probably be considered independently. -- John Porter We're building the house of the future together.
Re: RFC 216 (v1) POD should tolerate white space.
At 09:19 AM 9/13/00 -0700, I wrote: At 10:38 AM 9/13/00 -0400, John Porter wrote: 2. Allowing $/ (or its successor, perhaps set on a per-filehandle basis) to be a regular expression, not a string. (Surely there's an RFC on that somewhere.) This is a good idea too, and should probably be considered independently. *Applause* There is no RFC on it unless it is hopelessly mistitled. This is something I've wanted for a long time. Someone working on the RFC? Actually the RFC isn't hopelessly mistitled; it's RFC 93, "Regex: Support for incremental pattern matching". It has everything in there, it just might benefit from explicitly saying, "This is how people who want $/ to be a regex can get what they want" even though it may not be called $/ in Perl 6. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 216 (v1) POD should tolerate white space.
At 10:38 AM 9/13/00 -0400, John Porter wrote: 2. Allowing $/ (or its successor, perhaps set on a per-filehandle basis) to be a regular expression, not a string. (Surely there's an RFC on that somewhere.) This is a good idea too, and should probably be considered independently. *Applause* There is no RFC on it unless it is hopelessly mistitled. This is something I've wanted for a long time. Someone working on the RFC? -- Peter Scott Pacific Systems Design Technologies
