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?
> That's what I did for `buffer-string'; however, I did it
only because
> the FSF version really made more sense. And yet, even with the
> compatibility fix, my solution broke in some cases and had to be fixed
> by wmperry.
Well, I'm willing to implement either (or some other) solution. I
just want to know what to do.
Decide for yourself. If you want to implement the change,
the buffer-string solution would do, I guess. :-(