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: Sat, 23 Nov 2024 10:50:22 +0200 Message-ID: <86mshqmj01.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19631"; 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 Sat Nov 23 09:51:11 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 1tElrB-0004vv-OF for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Nov 2024 09:51:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tElqd-0008Qj-Cv; Sat, 23 Nov 2024 03:50:35 -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 1tElqZ-0008QT-Sx for emacs-devel@gnu.org; Sat, 23 Nov 2024 03:50:32 -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 1tElqZ-00078s-FC; Sat, 23 Nov 2024 03:50:31 -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=czzF23PS0qAtU+SyRA1PtmMekPMU2jqe8j+wCBqdAqg=; b=eraSN3vX57dB pcXU6cdbjXkpYM+9hNeEqMc3MD1+aG/9S1DecNzQBRYxDXEXl8Hn5STz3m8fkLORd/Ceqz/9M2LZS GFQWlT3aiTTmLDUpbCyw5zlo00yuRiVFRVnflKP9TkYBI9BUnXDvM+M/T9qI9iNwgRpLPJQ3T220t 76ZU5TRS82NR4DILAVoepFHYHS+44xXziVe1YawQBrtwnEAwyPhUQ8Ng8rN0V7w1SPFrOOFeoU3Nv 5I0LVq0+pJ4ORFyqeLFCdG6ANNv3lnh6ZX1iIcu88hTWQjCBMLjVDlVYduXVLFOMuYWSBDXLPaTUh L5L8bsiI7igm/M9bsUAMFQ==; In-Reply-To: (message from Richard Stallman on Sat, 23 Nov 2024 01:10:30 -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:325609 Archived-At: > From: Richard Stallman > Cc: emacs-devel@gnu.org > Date: Sat, 23 Nov 2024 01:10:30 -0500 > > > Names are important. They have power. To take somebody's/somthing's > > name and misuse it is an exercise of aggression. Try using "Emacs" or > > even "free software" to mean something different, and see just how > > quickly you would hear back from Richard Stallman. > > Is this really the case? I am trying to figure out what concrete events > those descriptions could refer to, and I can't be sure. If I may summarize those events and the technical aspects of this, they are as follows: . Emacs 29 introduced a new user option called major-mode-remap-alist. It allows to "remap" one major mode into another, and is obeyed by normal-mode, so if FOO-mode is remapped to BAR-mode, then any time FOO-mode is found to be appropriate for a buffer, whether by virtue of auto-mode-alist, or file-local variables, or anything else, normal-mode would actually activate BAR-mode instead. . When we added to Emacs major modes based on the tree-sitter library for programming languages for which we already had "traditional" major modes, this mode remapping was suggested as the means for users to express their preference of using the tree-sitter modes (which by default are disabled, as auto-mode-alist still names the traditional modes for the respective file types, to preserve past behavior and avoid surprising users). I disagreed with using this feature, because the value of major-mode-remap-alist is not simple enough for users to customize. Instead, we arranged for the tree-sitter modes to modify auto-mode-alist when the mode is loaded, and told users that by loading the mode manually, they will have their preference be known to Emacs. . Changing global data structure, such as auto-mode-alist, when a Lisp package is merely loaded is not the best idea, and has some negative consequences. For example, byte-compiling a package in a running Emacs session loads that package, and thus might modify auto-mode-alist when the user didn't really mean that. And getting auto-mode-alist back to its previous value is not easy, unless you are a Lisp programmer. Moreover, modifying auto-mode-alist doesn't affect visiting files that have a mode cookie or set their major-mode in the file-local variables. So this solution had known issues, but was still used for its simplicity in the typical use case, where the user starts a session and wants to switch to using a certain tree-sitter mode from that moment onwards. . In March 2024 Stefan Monnier installed a change for Emacs 30 that introduced a new variable, major-mode-remap-defaults. This variable is consulted by normal-mode if major-mode-remap-alist (which is a user option, and thus can be changed only by users) doesn't have any associations for a mode, and if major-mode-remap-defaults does have such an association, the mode is remapped as described above. Stefan then used this new variable to replace the code which modified auto-mode-alist when a tree-sitter mode was loaded. Specifically, when c-ts-mode is loaded, it adds associations to major-mode-remap-defaults that remap c-mode and c++-mode to their tree-sitter counterparts; and when ruby-ts-mode is loaded, it adds associations that remap ruby-mode to its tree-sitter counterpart. The main motivation for these changes was that they make the process of preferring a tree-sitter mode by the user cleaner, by not messing with auto-mode-alist, and by making sure normal-mode will _always_ use the preferred mode. This change was discussed (as part of bug#69191), but it should have been discussed more, and in particular its effects on normal-mode and its callers should have been explicitly described and discussed. . In May 2024 Alan Mackenzie installed in cc-mode.el a change that countermanded the use of major-mode-remap-defaults for remapping c-mode and c++-mode to the tree-sitter counterparts. The change he installed defeated the code in c-ts-mode which added associations to major-mode-remap-defaults. The result was that loading c-ts-mode no longer had the effect of using c-ts-mode for C files, contrary to the documentation which said it would. The exact way this change worked was never described anywhere but the commit log message, although the change itself was announced in a message posted by Alan to emacs-devel (https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01294.html). Needless to say, the adverse effects of that change on people who prefer using c-ts-mode went unknown until Emacs 30 went into pretest. When asked (in bug#74339) to fix that code which allowed the documented procedure for users to express their preference for c-ts-mode to work, Alan said he will not agree to such a change, and proposed other ways of solving this, which would go back to using auto-mode-alist (something which we already decided we want to abandon in favor of better ways) and would delay the release of Emacs 30.1 due to non-trivial changes in data structures and code central to Emacs as a whole, not just to these two modes. I will leave it to Alan to describe why he thinks the mode-remapping feature is wrong when it affects c-mode, and/or why it is wrong to do that via major-mode-remap-defaults. From my POV, mode-remapping is just a convenience feature which allows users to substitute one mode for another without a lot of modifications in auto-mode-alist and similar data strictures used by normal-mode, editing all the files which have the mode cookie or specify the mode in file-local variables, etc. I don't see any problem with the user saying that the symbol c-mode should be interpreted as meaning some other mode should be invoked when normal-mode is called with that symbol as its first argument.