Oh, just FYI, I forgot to mention that you can just do:
=extend Y C,I
(with out the terminal foo,bar,baz list)
That means: whenever I do Y<...>, treat it as if I just did C>.
It's just a degenerate case of "=extend Y C,I list", except with an empty list.
--
Sean M. Burkehttp://search.cpan
* Russ Allbery wrote, in an earlier email:
> I'm not sure why you'd express it that way rather than just expressing it
> like this:
>
> =extend N Y W B,I
>
> In other words, the first argument is the new code, and the subsequent
> arguments are the replacements to use in order of decreasing pr
Iain 'Spoon' Truskett <[EMAIL PROTECTED]> writes:
> You get notified when a paragraph starts/end and can easily just
> construct a paragraph starting from the start tag and then postprocess
> the paragraph when you get the end tag. By the time you've got the end
> tag, all the interior sequences
* Russ Allbery ([EMAIL PROTECTED]) [13 Oct 2002 15:36]:
> Iain 'Spoon' Truskett <[EMAIL PROTECTED]> writes:
[...]
> So the idea is to instead have a registry of XML-style names for
> attributes and then people can map the available single characters to
> the appropriate attributes in each POD fil
At 20:38 2002-10-12 -0700, Russ Allbery wrote:
>My understanding of the point of =extend was to allow us to add new
>interior sequences without breaking all the existing parsers, not to let
>people create their own mini-languages using POD syntax. The latter is
>kind of interesting, but I'm not s
Sean M Burke <[EMAIL PROTECTED]> writes:
> It's so that if I (the person writing the pod) want to use Y for
> strikethru (or whatever), I can. If I want to use Q for it, I can.
> Etc.
> That's how I handle the fact that the universe of possible useful
> extension-features is larger than A-Z (mi
At 20:22 2002-10-12 -0700, Russ Allbery wrote:
>Why wouldn't the parser pass Y to the formatter if it said it understood
>it?
Yes.
>I don't understand the point in the pseudo-XML tag names.
It's so that if I (the person writing the pod) want to use Y for strikethru
(or whatever), I can. If I
Iain 'Spoon' Truskett <[EMAIL PROTECTED]> writes:
> On the other hand, it allows the authors to do what they like. The main
> problem is that of redundancy. e.g. all my Pod will end up with
> something like:
> =extend M module-name C,I
> =extend N method-name C
So why don't we instead agree t
Sean M Burke <[EMAIL PROTECTED]> writes:
> I use XML as a notation to express the parse treelet, or event stream,
> or tag stream. "Y<...>" is fine as anotation for those, but
> "format:strikethru<...>" is not clear. Using XML as the notation is
> handy in that we can always tell the difference
"Iain 'Spoon' Truskett" <[EMAIL PROTECTED]> writes:
> Plus, I'm thinking of my perl books site. [...] it would be nice to
> be able to have things map to book-title, author-name, etc.
You're about to wake a sleeping dog.
-- Johan
Sean M Burke <[EMAIL PROTECTED]> writes:
> Spelunkers of the Pod::Simple dist will have noticed the file
> t/ac_c_extend.t, which tests Pod::Simple's implementation of the =extend
> directive some months ago we that we discussed adding. It works like
> this:
> =extend N B,I Y,W
Initial impress
At 17:47 2002-10-12 -0700, Russ Allbery wrote:
> > This means "I want to extend Pod with a new formatting code N<...>. If
> > the Pod application has told the parser it understands Y elements, then
> > when I say N<...>, expres that to the application as a
>
>You mean as a Y<>, right? POD
12 matches
Mail list logo
