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.devel Subject: Re: My resignation from Emacs development Date: Thu, 19 Dec 2024 10:26:40 +0200 Message-ID: <86ldwckri7.fsf@gnu.org> References: <169c6564-4722-4338-a049-5f8f3ce69394@alphapapa.net> <86ldxbofgw.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21694"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 19 09:27:35 2024 Return-path: Envelope-to: ged-emacs-devel@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 1tOBsd-0005W6-2O for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Dec 2024 09:27:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOBs5-00031b-KG; Thu, 19 Dec 2024 03:27:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOBry-0002wh-6x for emacs-devel@gnu.org; Thu, 19 Dec 2024 03:26:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOBrx-0002Yw-8m; Thu, 19 Dec 2024 03:26:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=I4frmeBlHHuQPRr5Jv6ObzBLcAlxuR/6d7AOsaS4kxY=; b=nhPMzzI1nxrR ++859KNzYzoIFk5tSsXTA6r3BWAXwx7DPnxNSOdQUov6GHIVPx8ASHmtwaNz0GcU4Zl5tdalgpx56 tnL/mHdOi1/pyH4c81eZ/YL+WJSvODQULkR3+n2P3hpwVl5nDbiAH7V3ja0GufukkAqYcx5D9WnhK QQew/GyfAVUu4e0GCPLjYiX8X/7E0ZpCa8prIS7P/cAc1JdI2CqesOlCNkhEsqgtY6lqwthZOOMb9 fsy2EPhZwdGiPD9WfV67yZGA2NmNlJIkk0Qq/mjtPH7K0bN74lvYKF+rHfxE0NF1n/3fRKM+gQYr6 4xHmAU1ttp6fmQNBGiLZug==; In-Reply-To: (message from Richard Stallman on Wed, 18 Dec 2024 23:22:01 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326704 Archived-At: > From: Richard Stallman > Cc: emacs-devel@gnu.org > Date: Wed, 18 Dec 2024 23:22:01 -0500 > > > What has been implemented, "remapping", is a sort of extreme version of > > advice: it supersedes a symbol's function by some other function. > > I agree. I don't agree. This is not the first (nor the last) time we have similar "remapping" in Emacs. We have " " in keymaps (see "Remapping Commands" in the ELisp manual). We have face-remapping-alist, which remaps a named face into some different face. We have shortcuts, which "remap" symbols. And I'm sure I can find more examples of similar "remappings". > > What's more, it is the core Emacs functions which do this, not some > > wierd user setting. CC Mode's symbol `c-mode' now sometimes means C > > Mode, sometimes c-ts-mode. > > This situation is complex because what was previously a single > operation has to be replaced by a choice of two partly similar > operations. That is always somewhat messy, but we can make it less > messy than this. > > One of the two new operations is, "Select C mode, no TS." > the other new operation is, "Select my usual mode for C." > They used to be entirely equiva;ent, but now they are not. > > We could define a name for each of those operations. > > Maybe there could be `c-no-ts-mode' and `c-ts-mode', as well as > `c-mode' which would follow the user's previously stated choice > between the other two. > > > The lack of available compromise is largely due to needing/wanting to > > get the upcoming release released on time, without making any > > significant changes to the code which might make an extra pretest > > necessary. > > That is not necessarily a horrible error if it is _temporary_. > What would be horrible is to let this hurried expedient decide > the commands of Emacs forever. We are discussing the various ways of having a cleaner set of commands and features in future Emacs releases. But none of them will remove major-mode-remap-alist from Emacs, though we might decide not to use it for some of these features.