From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Another Emacs incompatibilty Date: Mon, 17 Aug 2020 19:08:31 +0300 Message-ID: <83imdhgsqo.fsf@gnu.org> References: <86r1s648dc.fsf@shell.gmplib.org> <86wo1xz4lt.fsf@shell.gmplib.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19683"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: tg@gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 17 18:15:24 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 1k7hnA-0004zz-CD for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 17 Aug 2020 18:15:24 +0200 Original-Received: from localhost ([::1]:45990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7hn9-0002DR-7m for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 17 Aug 2020 12:15:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7hgp-0007WE-2i for help-gnu-emacs@gnu.org; Mon, 17 Aug 2020 12:08:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59523) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7hgn-0003TO-Ge; Mon, 17 Aug 2020 12:08:49 -0400 Original-Received: from [176.228.60.248] (port=4313 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k7hgk-0002Lt-L0; Mon, 17 Aug 2020 12:08:47 -0400 In-Reply-To: <86wo1xz4lt.fsf@shell.gmplib.org> (tg@gmplib.org) 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:123688 Archived-At: > From: tg@gmplib.org (Torbjörn Granlund) > Date: Mon, 17 Aug 2020 17:14:54 +0200 > > For example, changing the way something as fundamental as regions work > in a very mature editor is just a bad idea. It would help if you'd tell what changes in how region works you are alluding to. I use Emacs for the last 30 years, and the way region works for me didn't change at all, AFAICT. So I'm really puzzled by what you say here. > 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. Emacs doesn't change such basic traits of its usage, either. We haven't changed the command-line options, didn't change the documented APIs of Emacs primitives in incompatible ways, and '+' still adds, doesn't subtract. However, Emacs has several orders of magnitude more features as aspects than the likes of cp and mv, and as time passes and the Emacs audience changes, the popular demand for some of them also changes. In any case, whenever a backward-incompatible change happens, there's usually a way, called out in NEWS, to get back old behavior.