From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tg@gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Newsgroups: gmane.emacs.help Subject: Re: Another Emacs incompatibilty Date: Mon, 17 Aug 2020 17:14:54 +0200 Message-ID: <86wo1xz4lt.fsf@shell.gmplib.org> References: <86r1s648dc.fsf@shell.gmplib.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21854"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 17 17:41:50 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k7hGg-0005ZM-4H for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 17 Aug 2020 17:41:50 +0200 Original-Received: from localhost ([::1]:41624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7hGf-0005M1-3o for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 17 Aug 2020 11:41:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7gqg-0003kx-Ju for help-gnu-emacs@gnu.org; Mon, 17 Aug 2020 11:14:58 -0400 Original-Received: from martin.gmplib.org ([130.242.124.102]:51472 helo=shell.gmplib.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7gqe-0003Lt-Lq for help-gnu-emacs@gnu.org; Mon, 17 Aug 2020 11:14:58 -0400 Original-Received: by shell.gmplib.org (Postfix, from userid 1001) id 58D8EFBEE; Mon, 17 Aug 2020 17:14:54 +0200 (CEST) In-Reply-To: <86r1s648dc.fsf@shell.gmplib.org> (=?utf-8?Q?=22Torbj=C3=B6rn?= Granlund"'s message of "Sun, 16 Aug 2020 22:57:03 +0200") Received-SPF: none client-ip=130.242.124.102; envelope-from=tg@gmplib.org; helo=shell.gmplib.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/17 11:14:54 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=1, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:123683 Archived-At: [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. --=20 Torbj=C3=B6rn Please encrypt, key id 0xC8601622