On 4 Aug 2000, Russ Allbery wrote:
> Tim Jenness <[EMAIL PROTECTED]> writes:
> > On 4 Aug 2000, Russ Allbery wrote:
>
> >> [I'd love to know how the POD translator is supposed to do that.]
>
> > It wouldn't. It would get one of those Pod::Hyperlink objects (part of
> > Pod::ParseUtils) and do w
Tim Jenness <[EMAIL PROTECTED]> writes:
> On 4 Aug 2000, Russ Allbery wrote:
>> [I'd love to know how the POD translator is supposed to do that.]
> It wouldn't. It would get one of those Pod::Hyperlink objects (part of
> Pod::ParseUtils) and do what it wants with that. A perl manpage would
> not
On 4 Aug 2000, Russ Allbery wrote:
> Tim Jenness <[EMAIL PROTECTED]> writes:
>
> > This suggests to me that $variable should be written as if the author
> > had written I<$variable>, manpage(3r) should be written as
> > L etc. [with the L<> construct distinguishing between perl
> > man pages an
Tim Jenness <[EMAIL PROTECTED]> writes:
> This suggests to me that $variable should be written as if the author
> had written I<$variable>, manpage(3r) should be written as
> L etc. [with the L<> construct distinguishing between perl
> man pages and generic manpages]
[I'd love to know how the P
On 4 Aug 2000, Russ Allbery wrote:
> Tim Jenness <[EMAIL PROTECTED]> writes:
>
> > It's clear that a generic translator class should also be able to handle
> > the automatic podifying of variables and functions etc.
>
> It can't. The markup for such things doesn't correspond to any standard
>
Barrie Slaymaker <[EMAIL PROTECTED]> writes:
> If we document C<=for code>/C<=begin code> to do this, and tweak all the
> translators, I don't can live with it (I just want to use whatever
> syntax we cook up), but those do look like new two-word primitives to
> me, and strike me as being less cl
Barrie Slaymaker <[EMAIL PROTECTED]> writes:
> ...I wasn't proposing putting =for/=begin...=end processing in
> Pod::Parser, but in Pod::StdParser. Not sure if you were clear on that,
> but other readers of your reply might be confused by it.
Right, sorry. I wasn't sure it was a good place to
Russ Allbery wrote:
>
> > - moving $self->cmd_foo() dispatch to Pod::Parser,
> > - allows =for/=begin...=end filtering
that second bullet was under the "creating a Pod::StdParser" item
in my original, so
> This is certainly doable (although I question whether Pod::Parser is the
> right pl
Tim Jenness <[EMAIL PROTECTED]> writes:
> It's clear that a generic translator class should also be able to handle
> the automatic podifying of variables and functions etc.
It can't. The markup for such things doesn't correspond to any standard
POD sequences. Consider foo(1) in Pod::Man, for e
Russ Allbery wrote:
>
> I can sort of see the point, although I'd personally use a considerably
> simpler approach for extracting code excerpts for testing, probably more
> ad hoc. That may be a mistake on my part, and I can see why people would
> want to do this in some more formal way.
That's
Tim Conrow <[EMAIL PROTECTED]> writes:
> My problem with X<> it is that it's disruptive to the readability of the
> text if it's embedded and used too much, as it might well be for
> indexing. I was trying to navigate a way around that problem. I confess
> I haven't worked out how to deal with fi
Barrie Slaymaker <[EMAIL PROTECTED]> writes:
> Agreed, especially if volunteers can be found to port existing Pod::Foo
> converters to use this new Pod::StdParser (or whatever). I like the way
> that Pod::Text does $self->cmd_foo(...) dispatch, perhaps
(As an aside, please do bear in mind that
Marek Rouchal DAT CAD HW Tel 25849 <[EMAIL PROTECTED]> writes:
> I'd like to assent to this idea. While coding a new POD to HTML
> converter (MarekPodHtml-0.41) and starting with POD to MIF (FrameMaker),
> I found that much of the code is reusable.
I thought I discovered that too, with Pod::Text
Brad Appleton <[EMAIL PROTECTED]> writes:
> Besides, I think there is still need for a Pod::Translator of
> Pod::Compiler module that uses (or is subclassed from) Pod::Parser to be
> the *real* base parser that people use (the one that actually knows the
> commands, just not necessarily the outpu
Barrie Slaymaker <[EMAIL PROTECTED]> writes:
> The C<=also for|begin|end> commands are shorthand having two copies of a
> section of POD (typically an example), one normal copy, and one
> delimited by C<=for> or C<=begin> ...C<=end>. This supports
> semi-literate programming techniques, allowing
On Fri, 4 Aug 2000, Barrie Slaymaker wrote:
> I'm not going to volunteer for a POD DOM approach, but I am volunteering
> to help
>
> - factor the $self->cmd_foo() dispatcher from Pod::Text to Pod::Parser
> or (new) Pod::Dispatcher or something
> - implement a Pod::StdParser that adds support f
Marek Rouchal DAT CAD HW Tel 25849 wrote:
>
> On Thu, 3 Aug 2000, Brad Appleton wrote:
>
> BA>Besides, I think there is still need for a Pod::Translator
> BA>of Pod::Compiler module that uses (or is subclassed from)
> BA>Pod::Parser to be the *real* base parser that people use (the
> BA>one that
> Do tests go against bugs, or do they go against patches, or do they go against
> versions, or what etc?
I think tests can be against any of these. Maybe something like this:
.--. .--.
| test | | bug_test |
|--| |--|
| test_id +--
On Fri, Aug 04, 2000 at 08:42:50AM +0200, Marek Rouchal DAT CAD HW Tel 25849 wrote:
> contents in plain text (important for links, TOC, index). There is a
> Pod::Tree module out there that might serve as a basis for
> this.
Unfortunately, the Pod::Tree module does not use Pod::Parser.
It does it
19 matches
Mail list logo
