From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode Date: Wed, 13 Nov 2024 18:58:01 +0000 Message-ID: References: <868qtnfd2d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="680"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 74339@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 13 19:59:19 2024 Return-path: Envelope-to: geb-bug-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 1tBIaF-000AXY-2h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Nov 2024 19:59:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBIa2-0007dy-6u; Wed, 13 Nov 2024 13:59:06 -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 1tBIZy-0007dW-FN for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 13:59:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tBIZy-0006RW-2h for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 13:59:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=nEwa+juShvJetdLUvEGRWYM3q3YNdurRkSRd/2L08zo=; b=Fy2TRY9dzJ4JA2sPckcg0efhBFuAGOUjW1i8l2o2PAKPWM6ShmXGtnJCjF55SUojI3isHtEkFLJAzD5a1d9iA3xHw3GUzeLVzu1YGj6tCdvRkE/IA8K9CnGaMNmxa0AcjybYy/abztwZIzzAVcegVi6huVg6hCWzUDdzlEI2ISRE6t2s4q9oEiHN4S2UL9Ug08Bp8BiY694YB3BmTv1hZp2zJfDjHsYIIr4n1ZguOXTOCEh4/DgIW38x0gNJCJdEH2FE8YjLUnXpb1B9kLK99ymgTrcH5THgT2obCQEN1XDW+bmDGXSmyYMLYeL9s1WBKX4Luu+hkZ2lH1xmWuXxFw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBIZx-0005nz-Ky for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 13:59:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Nov 2024 18:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74339 X-GNU-PR-Package: emacs Original-Received: via spool by 74339-submit@debbugs.gnu.org id=B74339.173152429822256 (code B ref 74339); Wed, 13 Nov 2024 18:59:01 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 18:58:18 +0000 Original-Received: from localhost ([127.0.0.1]:43645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBIZF-0005mu-Fo for submit@debbugs.gnu.org; Wed, 13 Nov 2024 13:58:18 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:49896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBIZC-0005me-CA for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 13:58:15 -0500 Original-Received: (qmail 55490 invoked by uid 3782); 13 Nov 2024 19:58:03 +0100 Original-Received: from muc.de (p4fe1558f.dip0.t-ipconnect.de [79.225.85.143]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 13 Nov 2024 19:58:02 +0100 Original-Received: (qmail 14464 invoked by uid 1000); 13 Nov 2024 18:58:01 -0000 Content-Disposition: inline In-Reply-To: <868qtnfd2d.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295284 Archived-At: Hello, Eli. On Wed, Nov 13, 2024 at 16:00:58 +0200, Eli Zaretskii wrote: > To reproduce: > emacs -Q > M-x load-library RET c-ts-mode RET > C-x C-f src/buffer.c > M-: major-mode RET > => c-ts-mode > So far, so good: the user loads c-ts-mode, which means she prefers > C/C++ TS Mode for C and C++ files, so visiting a C file turns on > c-ts-mode instead of the default CC Mode. > But: > emacs -Q > C-x C-f src/dispnew.c RET > M-x load-library RET c-ts-mode RET > C-x C-f src/buffer.c > M-: major-mode RET > => c-mode > This is unexpected. It means that if even a single file loads CC > Mode, the user's preference of using C TS Mode is effectively ignored. [ .... ] > The above snippet from cc-mode.el was installed this last May, with > the following log message: > In normal-mode, make c-mode call c-mode when CC Mode is loaded > As regards which mode normal-mode calls for the symbols c-mode, > etc., the first of the following which applies holds: > (i) If the user has made a pertinent entry in > major-mode-remap-alist, this is used. > (ii) If CC Mode has been loaded, c-mode is called. > (iii) If library c-ts-mode has been loaded, c-ts-mode is > called. > (iv) Otherwise c-mode is called. > * lisp/progmodes/cc-mode.el (top level): Add entries to > major-mode-remap-defaults to implement the above. When I installed that patch, it was because c-ts-mode was stomping all over C Mode. I expected there to have been some negative feedback about my patch, and was somewhat surprised that it was apparently accepted. > I don't quite understand the rationale (and even less the > implementation), and don't recall any discussions of this; .... The rationale was to protect the symbol `c-mode' (and friends) from being misused to mean c-ts-mode, etc. I believe that at the beginning of development of the tree-sitter modes, there was an agreement, or at least an understanding, that the new modes would not usurp the names of the existing modes. The mechanism of major-mode-remap-defaults violates that understanding. I'm not aware of the discussions which led to the major-mode-remap-defaults mechanism, even having searched for them, and I was unaware they were taking place. I certainly wasn't invited to participate, despite the fact that CC Mode was central to the problem being discussed. There _was_ discussion of the problem leading to the patch, in particular, starting from this post in emacs-devel: Date: Wed, 29 May 2024 11:16:44 +0000 To: Stefan Monnier Cc: Eli Zaretskii , emacs-devel@gnu.org Subject: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.] .. My final post in that thread, which nobody replied to, was: Date: Thu, 30 May 2024 11:02:13 +0000 To: Eli Zaretskii Cc: acorallo@gnu.org, dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org , in which my last paragraph was >>>> Anyhow, I see a way forward. I will amend CC Mode also to make >>>> entries in major-mode-remap-defaults. This would appear to be in >>>> the spirit of that undocumented variable. It doesn't feel ideal, >>>> though. I did indeed amend CC Mode as I suggested, and that was the patch currently under discussion. It is indeed not ideal. > .... there's also no bug number for it. But clearly the result is not > acceptable, and I very much hope that there's some simple bug here > that can be fixed real soon. Having looked at it in detail in the summer, I'm afraid the bug is anything but simple. For example, M-x revert-buffer has the habit of silently changing C Mode into c-ts-mode, or vice versa. I did some work privately on this problem some months ago, coming up with a solution where revert-buffer worked properly, -*- c -*- worked properly, and the major mode chosen for a file was controlled solely by auto-mode-alist (and maybe major-mode-remap-alist). Some of that work might now be relevant. > If the above is not a bug, but the intended (by you, Alan) behavior, > then we need to talk about changing it, because this is not how user > preferences in this regard are supposed to be heeded by Emacs. I'm not unhappy about the need for change, and as I said, I was expecting such feedback back in May. It didn't come then. As for changing things, I insist as strongly as I'm allowed to on this mailing list that the symbols `c-mode' and `c++-mode' are essential properties of CC Mode, belong to CC Mode, and must not be stolen and misused in any way to mean `c-ts-mode' and `c++-ts-mode'; unless the user so decides and makes such a setting in major-mode-remap-alist. > The expected behavior is: as soon as the user loads c-ts-mode, all the > subsequent C/C++ files are visited using C/C++ TS Mode. To revert > back to CC Mode, the user must load cc-mode again. I don't think that reloading worked when I tried it, though that was some while ago. I think newly visited C files just went into c-ts-mode regardless. Amending Emacs to behave like this on loading a library might be a good way to fix the current problem. > In GNU Emacs 30.0.92 (build 21, i686-pc-mingw32) of 2024-11-11 built on > ELIZ-PC > Windowing system distributor 'Microsoft Corp.', version 10.0.22631 > System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.4460) [ .... ] -- Alan Mackenzie (Nuremberg, Germany).