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 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>. 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<...>>. The list of elements in either set can be just a single element, like so: =extend M C Q The first term (here an "M") has to be a single uppercase letter that isn't from the set of established Pod formatting codes (i.e., B C E F I L S X Z). But it can be a code that's been =extend'd earlier in this document; this will redefine how to process future instances of M for the rest of this document. 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". Otherwise it's interpreted as the list of elements that should be used when none of the elements in the third term are accepted. For example, in "=extend N B,I Y,W", if the Pod applicatoin doens't understand Y or W, then N<foo> will be processed like B<I<foo>>. 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 If the application has said it understands "strikethru" elements (or all elements, via "*"), T<...> will come across as <strikethru>...</strikethru>. Otherwise if the application has said it understands "strikethrough" elements, T<...> will come across as <strikethrough>...</strikethrough>. Otherwise if the application has said it understands "format:strikethrough" elements, T<...> will come across as <format:strikethrough>...</format:strikethrough>. There's currently no way to similarly extend the set of =foo codes. I think =for foo / =for :foo is the way to get the same semantics. -- Sean M. Burke http://www.spinn.net/~sburke/
