[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another Emacs incompatibilty

From: Torbjörn Granlund
Subject: Re: Another Emacs incompatibilty
Date: Mon, 17 Aug 2020 17:14:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

[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.

Please encrypt, key id 0xC8601622

reply via email to

[Prev in Thread] Current Thread [Next in Thread]