Re: replace-match: GNU vs XEmacs
Hrvoje Niksic writes:
Darryl Okahata <darrylo(a)sr.hp.com> writes:
> > XEmacs accepted that option long before FSF introduced their own
> > extension. The extension existed, and people would have used it.
> > By removing it or tossing it around, I'm afraid we send a "fuck
> > you" note to those of our users who actually care to use our
> > extensions.
>
> Well, I suggested that on the theory that we want to keep XEmacs as
> compatible as possible.
Yes, this has often be the way we did things. But I'm not sure if
it's a good idea, really. Smart people have said before: the more we
try to emulate FSFmacs, the more we suffer. I'm guilty of that sin
myself.
I will not force redemption on anyone, though. If you take
responsibility over the code, it's mostly up to your best judgement.
The review board can still veto your decision, but I don't think
that's likely to happen.
> I understand that XEmacs is already incompatible in a number of
> areas, but this parameter seemed almost like a
> inadvertent/gratuitous incompatibility (perhaps I'm wrong, but that
> was my first impression).
It is my impression too, but the point is that Stallman doesn't seem
to care about compatibility, so it's always up to us to make
incompatible changes. How much more of that are we going to cater to?
Clearly we shouldn't punish our users for the sake of Emacs
compatibility. The incompatibility problem is never going to go
away, so we should lay out a general policy as to how we deal
with API imcompatibilities, assuming that we do anything at all.
For example, we could set aside part of the namespace, e.g.
fsf-compat-*, and put all the FSF compatibility functions
there. fsf-compat-replace-match would be the Emacs compatible
replace-match function. I would prefer this approach, instead
of doing tricks with replace-match's argument types.