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 impression: A too-complex way of expressing this, although close
to the right idea, I think.
> 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 <Y>...</Y>.
You mean as a Y<>, right? POD doesn't have syntax like <Y>...</Y>. :)
> Otherwise if the Pod application has told the parser it understands W
> elements, then when I say N<...>, express that to the application as a
> <W>...</W>. Otherwise, when I say N<...>, express that to the Pod
> application as B<I<...>>.
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 preference.
> The second term (here a "C") has to be a comma-separated non-empty list of
> uppercase letters (from the set B C E F I L S X Z), can be a "0", or can
> be a "1". If it's a "1", then "foo M<bar> baz" will be parsed like "foo
> bar baz". If it's a "0", then "foo M<bar> baz" will be parsed like "foo
> baz".
The 0 and the 1 seems fine.
> The last term (here a "Q") has to be a comma-separated non-empty list of
> XML element names. For example:
> =extend T B strikethru,strikethrough,format:strikethru
POD isn't XML, thank heavens. The POD specification shouldn't assume that
the parser or translator is going to understand anything like XML, IMO.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
