Re: Pod::Elemental, a standards-snubbing pod mungler
* Allison Randal <[EMAIL PROTECTED]> [2008-10-26T15:33:16] > I'd say you already know where the greatest challenges will lie. That's good to hear. I hate thinking that I'm 80% done, only to have someone point out that I totally missed the major problem and that my design is never going to survive the next 15%. > - You're not currently paying any attention to the content of the X<> > tags. Eventually, someone will want to make a smart formatter for L<> > link tags for HTML, PDF, XML, etc, and will need more intelligence in > handling these tags. But, you can punt for a long time just by handing > the formatter a raw blob of text and letting the formatter parse it. Yeah, I'm totally treating all textual paragraphs (text, verbatim, data) like verbatim paragraphs. I -think- this is safe, because I don't think this is ever considered legal: =begin møøse ... =end mEEse After I do a bit more work reading and digesting perlpodspec, I hope I can help make it more explicit in a few cases, especially to make it clear that formatting codes never affect understanding paragraph syntax. > - Sooner or later, people will want to use Pod::Elemental or > Pod::Eventual as a drop-in replacement for Pod::Parser or Pod::Simple. > (A headache, but a worthwhile one.) That's when you'll need perlpodspec. I'm hoping that I can somehow manage to keep any form of formatting code parsing on the n+1 tier, so that the product would go: pod2sgml is built on Pod::Exegete is built on Pod::Elemental is built on Pod::Eventual is built on rock and roll Actually, I'm hoping to never need to deal with formatting codes, but L. -- rjbs
Re: Pod::Elemental, a standards-snubbing pod mungler
Ricardo SIGNES wrote: I released Pod::Elemental a few days ago, and just write up a blog post about it. I'd be interested in comments from the list, if anybody cares enough to look at it. http://rjbs.manxome.org/rubric/entry/1690 Never let the establishment stand in the way of experimentation. :) Your pluggable tree-like semantics are the most significant innovation here. Depending on how they're implemented, this should make it easier to output formats that have real tree structures (XML, HTML, etc). I'd say you already know where the greatest challenges will lie. - You're not currently paying any attention to the content of the X<> tags. Eventually, someone will want to make a smart formatter for L<> link tags for HTML, PDF, XML, etc, and will need more intelligence in handling these tags. But, you can punt for a long time just by handing the formatter a raw blob of text and letting the formatter parse it. (That means a hundred modules reinventing the parsing of links and link titles, but eventually a pattern will emerge, and you'll merge it back into the core.) - Sooner or later, people will want to use Pod::Elemental or Pod::Eventual as a drop-in replacement for Pod::Parser or Pod::Simple. (A headache, but a worthwhile one.) That's when you'll need perlpodspec. The beauty of Pod is that it's so simple. The pain of Pod is that it's so simple. Allison
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 someone is going to say, "You will encounter great problems if you don't support X because it's the secret problem we have been most often dealing with in recent POD" or "it would be great to use this for Y if only you had a simple method for Z." -- rjbs
Re: Pod::Elemental, a standards-snubbing pod mungler
On Saturday 25 October 2008 20.09.24 Ricardo SIGNES wrote: > I released Pod::Elemental a few days ago, and just write up a blog post > about it. I'd be interested in comments from the list, if anybody cares > enough to look at it. > > http://rjbs.manxome.org/rubric/entry/1690 I cared enough to look at it. Then what? I think we are stuck to POD as it because we, the community at large, are a bunch of lazy snakes that more interrested in doing other things than work with POD (like drinking beer and other activities our high moral standards forbid me to talk about) I believe 95% are happy with boring documentation, in form or content (when it is there to start with). POD is just right for documentation couch potatoes. What about the 5% left (most of them are on this mailing list and I can't say that I'm drowning in posts). We hack our ways around POD but no one is questioning if POD should be replaced (by something less whitespace verbose I'd like). And to be fair to POD, we've build a jungle of POD related modules. It is not easy for new comers to know what to use or what to use it for. 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. When someone states "standards-snubbing" it is usualy because there is something they don't like about the standard not to show how good they are at iterative development. So, again, what is it you want so I might contribute my 2 cents (or not)? Thank you for your aditional module and I'll keep it in mind should I want to write a pre-processor. Cheers, Nadim.
Pod::Elemental, a standards-snubbing pod mungler
I released Pod::Elemental a few days ago, and just write up a blog post about it. I'd be interested in comments from the list, if anybody cares enough to look at it. http://rjbs.manxome.org/rubric/entry/1690 -- rjbs
