Re: cperl-mode quick question/gripe

Matt> However, I can certainly see the value in Matt> compatibility. Presumably the best thing to do would be to Matt> either rename the variable(s) in question or provide aliases Matt> to them to maintain GNU Emacs compatibility. Of the two, I Matt> think I prefer the aliasing unless someone has a strong Matt> argument against it. Yes, I have one. We should not encourage developers to use incompatible APIs for compatible functionality. A single standard has to be _very_ bad to be worse than competing APIs for the same functionality. In cases like extents vs. text properties, where the functionality is different (remember the n^2 bug in font-lock? all Ben did to fix that was change to using the text property interface, which automatically coalesces abutting extents with the same property), it's worth doing. Where we innovate the functionality, we should keep our names. But when we're porting from the GNU project, we should make every effort to make sure calling code "just works" in any Emacsen that provides the functionality. In general, the GNU developers have shown zero interest in maintaining compatibility with XEmacs (except that, following RMS's position which created the fork, they think it's great if we work to their spec). We use a lot of their development work; it falls to us to do the compatibility work. Fair? Maybe not, it's a tough call, even though it's their own decision to not use our work. But _somebody_ should do compatibility. If they won't, that leaves us. This is my personal opinion; I will not enforce it as a condition of putting code into 21.4. I will reiterate it when appropriate, though. ;-)