Re: Another Emacs incompatibilty

[Torbjörn Granlund]

[Unfortunately, since I am not subscribed to this mailing list, this
follow-up mail will not have the right thread backlinks.]

To define this as a matter of balance between development progress and
compatibility is a false dichotomy.

No, emacs development is not "too fast" for me, as somebody suggested.
Any rate of fundamentally incompatible changes is too fast.

For example, changing the way something as fundamental as regions work
in a very mature editor is just a bad idea.  A really really bad idea.
By all means, define some other type of region and let that have other
semantics, or, let users opt in to incompatible regions by having them
set a variable in their .emacs.

And please do explain why inserting gremlins in my buffers upon window
focus changes is progress.

If the current emacs developers feel an urge to break emacs
compatibility, I think they should fork it and break the fork all they
want.  We GNU hackers need an editor which we can rely upon.  Some of
you might think hacking elisp is the best way of spending your time.
The rest of us prefer not getting interrupted in order to further GNU.

Please respect your users.  I do, and therefore I will not change the
options of cp, mv, or rm.  I will not push a change for swapping
operands or memcpy, strcpy, etc.  I will not suggest changing gcc's
command line options, or "improving" the C syntax it accepts.  And I
will still let GMP's mpz_add add its operands, and not do a subtract.

-- 
Torbjörn
Please encrypt, key id 0xC8601622