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 (minus the letters already used) > that are available for Pod formatting codes. I understand the problem, but I can't say I really like that solution. It means that if you look at a piece of POD and it says Y<...>, you have no way of knowing what that means without looking for =extend commands. Feels like action at a distance to me. And worse, it may mean something entirely different than what Y<...> means somewhere else. 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 sure it fits with the point of POD at all. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
