Marek Rouchal DAT CAD HW Tel 25849 sent the following bits through the ether:
> We probably could argue for centuries about this
Yes, indeed ;-). I'm going to compare this to XML::Parser, where the
main (default) style is proper event-based parsing. Alternative styles
(such as XML::DOM) exist wh
Marek Rouchal DAT CAD HW Tel 25849 wrote:
>
> I would not want to delete the warnings, I'd prefer an option to suppress
> them or a configurable handler to deal with them (like poderror in
> Pod::Parser).
Sorry, I assumed you'd noticed that most of them are already in
mponents: the parser engine (perhaps migrating stuff to Pod::StdParser
BS>or Pod::Parser), and the tree builder.
This sounds reasonable to me.
BS> The cmd_ and seq_ dispatching
BS>I'm borrowing and extending (a bit) from Russ's Pod::Text allow easy addition
BS>of extensio
u find.
> There are two differing requirements here: On the one hand, we need a
> fast! parser for online viewing, on the other a base framework for complex
> converters to avoid coding the same all over again.
We agree. One possibility is that Pod::Compiler should be factored into
two co
On Tue, 5 Sep 2000, Barrie Slaymaker wrote:
BS>Brad Appleton wrote:
BS>>
BS>> Marek has been doing similar work on an experimental
BS>> Pod::Compiler module that sounds suspiciously like your
BS>> Pod::StdParser. Definitely make sure you look at each
BS>> o
Brad Appleton wrote:
>
> Marek has been doing similar work on an experimental
> Pod::Compiler module that sounds suspiciously like your
> Pod::StdParser. Definitely make sure you look at each
> other's code before going too much further.
I haven't seen it published a
On Tue, Sep 05, 2000 at 01:30:11AM -0400, Barrie Slaymaker wrote:
> In http://slaysys.com/src/Pod-StdParser-0.001.tar.gz you
> should find an experimental Pod::StdParser, with a Pod::Tests
> and a tweaked Pod::Parser and a Pod::Text that's undergoing a
> transplant from P
In http://slaysys.com/src/Pod-StdParser-0.001.tar.gz you should find an
experimental Pod::StdParser, with a Pod::Tests and a tweaked Pod::Parser and a
Pod::Text that's undergoing a transplant from Pod::Select to Pod::StdParser (yes,
I know, that'd break Pod::Usage). I've disabl
Marek Rouchal DAT CAD HW Tel 25849 <[EMAIL PROTECTED]> writes:
> First of all I'd like to stress that "perlpod" has to be rephrased to
> reflect the abilities of existing parsers. For example, I see a lot of
> possible misinterpretations when trying to auto-link bare text like
> "foo(1)", "func()
On Mon, Aug 07, 2000 at 03:00:13PM -0400, Barrie Slaymaker wrote:
> One thing I've found useful in XML::Parser is the ability to
> change handlers mid-stream. But not that often, I guess.
Ohh - you could change the handlers mid-stream thru the
registration mechanism no problem. You just can't ch
er your message of Friday, but I'm tuit-starved
at the moment.
Or I'd have already toosed together a Pod::StdParser to test how
factorable things like Pod::Text are and to demonstrate C<=also>.
- Barrie
Barrie Slaymaker writes:
> I was proposing Pod::StdParser as a more low-level approach that
> generated callbacks:
Hmmn - not sure what you mean by "generate" callbacks.
Pod::Parser already provides for registration and invocation
of callbacks in a number of ways, same which use
Marek Rouchal DAT CAD HW Tel 25849 wrote:
>
> Hello all,
>
> I didn't manage to read all of your discussion, but let me elaborate a
> little on Pod::StdParser or Pod::Compiler and its benefits.
I was proposing Pod::StdParser as a more low-level approach that generated
Hello all,
I didn't manage to read all of your discussion, but let me elaborate a
little on Pod::StdParser or Pod::Compiler and its benefits.
First of all I'd like to stress that "perlpod" has to be rephrased to
reflect the abilities of existing parsers. For example, I s
14 matches
Mail list logo
