questions about =cut

I'm pretty sure that Pod::Eventual has a bug or two related to =cut, but I haven't written the tests yet because I'm not sure how I want to procede. This POD: This is text. =head1 HEADER ...and some text. =cut Text again. results in something roughly like this: { type: text,

Re: Pod::Elemental, a standards-snubbing pod mungler

* nadim khemir [EMAIL PROTECTED] [2008-10-26T04:57:45] So Ricardo, what is it you want? I know this sounds strange but it's what I find myself thinking at this point. It is difficult to comment on anything you have written because you have it all right. Well, mostly I'm just wondering if

Re: CPP-style #includes in POD

* David Cantrell da...@cantrell.org.uk [2009-05-21T10:26:48] The obvious solution is to have both module and script #include the appropriate chunk of POD. So I'm thinking: =begin cpp ... =end cpp has anyone already done this? And if not, am I correct in thinking that I need to write

Pod::{Weaver,Elemental,Eventual} work begun

I have begun work on my Pod-mangling grant, described here: http://rjbs.github.com/pod-weaver/ ...so you can expect me to talk about stuff here while I go along. The first thing I'm doing is re-reading Lperlpodspec, this time with a closer eye for detail. I'm finding a number of little

Pod POD pod poD pOd or P.O.D.

I am not clear on whether this paragraph says or means much: Throughout this document, Pod has been the preferred spelling for the name of the documentation format. One may also use POD or pod. For the documentation that is (typically) in the Pod format, you may use pod, or Pod, or POD.

Re: X vs. X

* Allison Randal alli...@perl.org [2009-05-24T19:13:22] I've been pondering how to simplify how some things are explained, and that's one place where I think the spec itself could be simplified without any real problems. To simplify the explanation without changing the implementation, just

Pod::Elemental back on track

I'm still working on my pod mangling tools, as funded by TPF, after an unfortunately protracted distraction. I recently blogged a very simple overview of what the tools can do hre: http://rjbs.manxome.org/rubric/entry/1805 You can see the code producing the demo (which is now better than

=encoding [is making me crazy]

Right now, all my Pod-handling code basically ignores =encoding. It doesn't know anything about what it does or what it's for. I do not plan to add support for much of it, because for the most part I don't think it's worth the time. My plan is to, more or less, do this: * assume documents

Re: expanding =begin

* Allison Randal alli...@perl.org [2009-12-01T05:44:02] David E. Wheeler wrote: Makes sense to me, but I think that you need to update the regex to include the (optional) parameter. Something like: Cm/\A:?[−a−zA−Z0−9_]+(?:\s+[−a−zA−Z0−9_]+)?\z/ Best is to keep the regex the same for

is LFoo::Bar|Foo::Bar still needed?

I'm still in the habit of writing: This code is built with LKosher::Salt|Kosher::Salt. To avoid: This code is built with the Kosher::Salt manual page. Has this behavior been eliminated in all the common Pod translators? I haven't seen it in some time. -- rjbs

Re: deprecating LSection

* Nicholas Clark n...@ccl4.org [2009-12-01T13:57:18] Although I note (without investigating) http://perl5.git.perl.org/perl.git/blob/HEAD:/Porting/Maintainers.pl#l1295 # XXX these two files correspond to similar ones in blead under # pod/, but the blead ones have newer

Re: allowing Ltext|href

* David E. Wheeler da...@kineticode.com [2009-12-01T14:16:39] On Dec 1, 2009, at 2:03 AM, Allison Randal wrote: The relevant tests are in t/fcodes_l.t, with a few more in t/xhtml01.t. Yeah, and it looks like it pretty well matches what RJBS and I sketched out. Ricardo, are you looking to

XHTML formatter 'xhtml' regions

I recently got my Advent calendar converted entirely to Pod::Simple where it had previously used Pod::Parser. I needed two features added. I sent Allison and David a pull request for the first, this morning. It allows you to say =head1 becomes h2 or becomes h3 and so on, which makes it easier

Re: XHTML formatter 'xhtml' regions

* David E. Wheeler da...@kineticode.com [2009-12-11T12:56:28] =for xhtml tag.../tag ...pass the XHTML right through. This is invaluable for producing my colorized code samples. (I assume it also works as a begin/end block.) If it is welcome, I will add it to Pod::Simple::XHTML

Re: XHTML formatter 'xhtml' regions

* Ricardo Signes perl@rjbs.manxome.org [2009-12-11T13:36:32] * David E. Wheeler da...@kineticode.com [2009-12-11T12:56:28] Sounds useful. What does the patch look like? Right now, it's a subclass. I will make a patch in a branch on Github... That was easy! http://github.com

Re: XHTML formatter 'xhtml' regions

* David E. Wheeler da...@kineticode.com [2009-12-11T14:02:33] I asked Graham earlier this week if he'd consider switching to Pod::Simple::XHTML, and his comment was that, if we did that, and someone had invalid html in a `=for html` section, it would make the whole document invalid. Of course,

Re: XHTML formatter 'xhtml' regions

* Ricardo Signes perl@rjbs.manxome.org [2009-12-11T14:40:52] David and I spoke on AIM. This is 99.99% a regression introduced in October! I will fix it. I've fixed this problem, added tests, and created a new method, accept_targets_as_html. This acts like _as_text, but the collected texts

Re: Pod::Simple fullstop_space_harden Attribute

* David E. Wheeler da...@kineticode.com [2009-12-17T17:31:16] I've released it as Pod::Simple 3.13. Enjoy. Great news, thanks! -- rjbs

Re: All tests fail

* Mike Brown br...@mrvideo.vidiot.com [2009-12-25T20:12:21] Yep, all of the tests fail. :-( Summary of my perl5 (revision 5 version 8 subversion 4) configuration: That's a five and a half year old version of perl5, with quite a few locally applied patches, which makes me really nervous to

Re: Fwd: [rt.cpan.org #55602] Bug #12239 was a mistake (nested formatting codes)

* David E. Wheeler da...@kineticode.com [2010-03-15T13:32:28] Comments? From perlpodspec (presented as verbatim text): =item C $thing-stuff(Idodad) Further, I see nothing that implies that C Cfoo should be rendered as Cfoo rather than foo I don't know that I realized this was the

Re: [rt.cpan.org #55602] Bug #12239 was a mistake (nested formatting codes)

* David E. Wheeler da...@kineticode.com [2010-03-15T14:56:48] C open(X, thing.dat) || die $! C $foo−bar(); which is presumably easier to read than the old way: Copen(X, EgtEgtthing.dat) || die $! C$foo−Egtbar(); My

Re: [rt.cpan.org #55602] Bug #12239 was a mistake (nested formatting codes)

* David E. Wheeler da...@kineticode.com [2010-03-15T19:28:15] Well, should it change to that? If we can all agree on a proper solution and update the spec to be specific, I'm happy to modify Pod::Simple (if I can find the tuits) to match that. FWIW, I blogged about this when 3.09 came out:

Re: Ansi color tag

* nadim khemir na...@khemir.net [2010-04-16T20:07:27] Hi, I think it would be nice if pod had a new tag for defining colors. I think the most useful thing to add would be a generic formatting tag, analagous to =for/=begin, for endless extensibility. Off the top of my head, I'd say: G type (

Re: SPEC UPDATE: [rt.cpan.org #55602] Bug #12239 was a mistake

* David E. Wheeler da...@kineticode.com [2010-04-17T16:46:23] Looks good to me. Hopefully, this is how Pod::Simple worked before I changed it to escape everything. If so, it should be as simple as applying this patch:

Re: SPEC UPDATE: [rt.cpan.org #55602] Bug #12239 was a mistake

* David E. Wheeler da...@kineticode.com [2010-04-19T13:17:13] I think I'd rather pull in that commit and have you and Madsen verify that it's compliance with the new wording of the spec *before* I release it. Seem reasonable? Sounds great, I'll get this done in the next 2-3 days. -- rjbs

Re: `=item 1. Text` Doesn't Produce Ordered List Item

* David E. Wheeler da...@kineticode.com [2010-07-20T16:40:18] perlpodspec says that the former is an unordered list and the latter is a description list. I think pod2html is wrong here. If so, my next question would be: how dependent are people on this? Is it something we want to consider

Re: `=item 1. Text` Doesn't Produce Ordered List Item

* David E. Wheeler da...@kineticode.com [2010-07-25T13:40:24] For the purposes of this thread, my question is: Should we support `=item 1. foo` as creating an ordered list item the way we support `=item * foo` as creating an unordered list item? I vote yes, as it seems more consistent, and

Re: `=item 1. Text` Doesn't Produce Ordered List Item

* David E. Wheeler da...@kineticode.com [2010-11-11T23:06:22] Coming back to this, now that we're trying to get Pod::Simple ready for Perl 5.14. Anyone else want to vote? The only other thing I'd add is that pod2html (which IIRC uses Pod::Parser) treats `=item 1. foo` and `=item 1 foo` as

Re: no deprecation warning for Lsection

* Karl Williamson pub...@khwilliamson.com [2011-04-27T13:52:50] I notice that perldoc does not warn on this being deprecated. Is this by design? I can't say with certainty, but I would wager that this is an oversight. Maybe we can get that addressed after 5.14 and, better, can get it into

Re: no deprecation warning for Lsection

* Michael Stevens mstev...@etla.org [2011-04-28T17:03:36] Has it got a victim^Wvolunteer? Yup. Marc Green (the student) and David Wheeler and I will have our first meeting to kick things off in a few days. From there on, a state of constant progress! -- rjbs

Re: no deprecation warning for Lsection

* Nicholas Clark n...@ccl4.org [2011-05-01T05:34:08] a: move to maintaining Pod-Parser as part of the core or b: more to eliminating the need for Pod-Parser and the consensus seems to be that (b) is far less insane. I think that what's then gone wrong is that no-one wants to start on it,

Re: Pod::Html's cross referencing of C links

* Marc Green pongu...@gmail.com [2011-05-20T16:24:21] links. More specifically, I understand how it resolves L links, but I am confused as to why you resolve C links. From reading the source, I gather that C links are resolved by searching pod documents for =item directives, and storing their

Re: Removal of specific Pod::Checker warnings

* Marc Green pongu...@gmail.com [2011-08-11T06:40:17] perlpodspec states Pod processors must tolerate a bare =item as if it were =item *. Is Pod::Checker's behavior still in line with perlpodspec? Is the use of '=item' without any parameters deprecated? Or should that warning be removed from

Re: Deprecation of alternate text in hyperlinks

* Karl Williamson pub...@khwilliamson.com [2012-01-23T12:26:27] So, you're saying I believe the text in perlpodspec that was the motivation for these changes should be removed, and that Pod::Parser should revert to its old behavior of not checking for this. After all the care taken to be sure

Re: Fwd: [rt.cpan.org #74389] Pod::Simple::Pullparser get_title should ignore X...

* David E. Wheeler da...@justatheory.com [2012-01-25T15:12:03] Subject: [rt.cpan.org #74389] Pod::Simple::Pullparser get_title should ignore X... Date: January 25, 2012 12:10:00 PM PST Reply-To: bug-pod-sim...@rt.cpan.org With Pod::Simple 3.14. If a pod file has index entries

Re: an 'anchor' command is missing from Pod

* Shawn H Corey shawnhco...@gmail.com [2012-01-27T19:51:50] I thought they were using the Z code for it: =item open FILEHANDLE,EXPR =item open FILEHANDLE,MODE,EXPR =item open FILEHANDLE,MODE,EXPR,LIST Zopen You're thinking of X -- Z should always be empty, and is a zero-effect

Re: an 'anchor' command is missing from Pod

* Shawn H Corey shawnhco...@gmail.com [2012-01-28T08:41:35] On 12-01-27 11:14 PM, Ricardo Signes wrote: You're thinking of X -- Z should always be empty, and is a zero-effect code. Xopen is used to help indexing. It isn't how perldoc -f works, though. No, I've encountered unempty Z

please test perl5.git's Pod-Html

I've already asked for some testing on p5p, but oh ye devoted pod people: If you have the time, install perl from git, commit ac2b477 or later, and play around with pod2html and let us know what is broken. I think it's mostly working now, although there is one chunky bug report to work through

Re: Fwd: Topic/metacpan.org (#36)

* David E. Wheeler da...@justatheory.com [2012-08-13T12:41:31] I got a pull request to switch to metacpan.org for L http links. AFAIK search.cpan.org is not deprecated, and is still the official community CPAN search site. If there is some discussion about changing it, or if Graham thinks it's

Re: Version comments in POD output

* Russ Allbery r...@stanford.edu [2012-12-26T17:47:41] Do people feel this comment line provides much real utility in Pod::Man output? I could add a flag to suppress it, but I'm tempted to just drop it entirely, since I'm not sure that it's really doing anyone any good. I have often found

Re: Pod::Simple doesn't warn when the text of a definition =item matches /[\*\d]/; and a fix to this bug

* Marc Green pongu...@gmail.com [2012-02-19T16:19:08] When given the following input, Pod::Simple does not warn that the [text] portion of the 2nd and 3rd =item is invalid. =over =item a definition some text =item * a bullet =item 1 a number =back [perlpodspec cited] I am not

Re: Pod::Simple doesn't warn when the text of a definition =item matches /[\*\d]/; and a fix to this bug

* David E. Wheeler da...@justatheory.com [2013-01-18T12:33:52] Good idea, though it will require that older versions of Perl install a JSON parser just to run the tests… I believe it could be bundled, and would be worth the hassle. Maybe. :-) -- rjbs signature.asc Description: Digital

Re: podlators broken by Pod-Simple 3.24

* Russ Allbery r...@stanford.edu [2013-02-20T20:24:58] I haven't had a chance to look yet (still recovering from a cold), but will try to take a look soon. I'm glad you're recovering. :) I suspect the problem is as simple as the podlators test suite including a test for handling of

Re: Is Pod::Simple::POD worth pursuing?

* John SJ Anderson geneh...@genehack.org [2013-05-21T19:33:14] * Is this a worthwhile idea? (The recent How do I get Pod::Simple to extract pod thread suggests the answer is yes.) It's hard to judge this without the context in which you're considering it. The GH issue to which you linked is

Re: Assume CP1252

* 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

Re: Pod::Simple can treat binary as pod due to liberal/inconsistent regexp patterns

* David E. Wheeler da...@justatheory.com [2015-01-08T00:38:04] I agree that’s too liberal. I suggest /\A=([a-zA-Z]+\d*)\b/ trolling? Surely you want [0-9] instead of \d, lest we end up with =head୩ ! /trolling? -- rjbs signature.asc Description: Digital signature

Re: Allow Whitespace in L URLs?

* David E. Wheeler da...@justatheory.com [2015-01-08T13:42:10] I think that is probably sane, but maybe there are other opinions? Should we allow whitespace in L URLs? If so, I think we would just change \S to . I didn't scrutinize the regexp (which is present in perlpodspec) closely, but URLs

Re: podlators 4.05 released

* Russ Allbery [2016-01-16T17:36:02] > I'm pleased to announce release 4.05 of podlators. Thanks, Russ! I can only assume that moving back to the *.PL was a bit of a disappointment. Thanks for helping to keep things great on all platforms! -- rjbs signature.asc Description:

Re: podlators 4.07 released

* Dave Mitchell [2016-03-21T04:56:11] > I vote for this being merged into blead despite the code-freeze. I can > vouch for the 1st and 3rd fixes, I know nothing about the second. +1 -- rjbs signature.asc Description: Digital signature

Re: podlators 5.00 released

On Fri, Nov 25, 2022, at 17:53, Russ Allbery wrote: > This is the first major release of podlators, which provides Pod::Man and > Pod::Text, in some time. Thanks, Russ! These libraries are really important and probably you don't get enough kudos for the many years you've spent keeping them

Re: POD formatter version comments

On Wed, Mar 20, 2024, at 18:34, Karen Etheridge wrote: > I believe the paragraph in the docs should stay, but change the MUST to a > SHOULD, with a proviso that there should be a way to disable it (for the > purposes of repeatable builds etc). If the paragraph is removed entirely, no > one