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.bugs Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode Date: Wed, 13 Nov 2024 22:42:19 +0200 Message-ID: <86msi2lvbo.fsf@gnu.org> References: <868qtnfd2d.fsf@gnu.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="21204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 74339@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 13 21:43:23 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 1tBKCw-0005Je-N8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Nov 2024 21:43:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBKCf-0007FX-4D; Wed, 13 Nov 2024 15:43:05 -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 1tBKCd-0007F8-9b for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 15:43:03 -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 1tBKCd-0000tZ-1G for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 15:43:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=lAdmTdMYV97cCHO89T7SokQZ8WfOqMjUJtYkUD0N9lY=; b=UEoCLu5rQfNvJj9D3/dhpHZxdYBYKTjKMJJolKz+0vuLl1lUV4ANkB611IruPHFe5pGhhiHvSpTyFTlsNFQZWYvbCDT+n8IVYhJciByL1FzwHpFzlu6RRJOs/C7veSYxS+flYJMGYAzTw9dy4ZTxuNe31e0saoEUvyK+zfO1Oy8zDUpkx7pON/TwGJ5I0IXxnRZQtLHzVqeh3/HZWMwrzialRaxNfYdGDQN/2JjRYD8aC614jVV7mOwVlxwoS4jHFu458T0wSaDvQdy+oBHVMrVSBEJu2fcZu6VjX8Pq0xOy5KL1wFFXSFSGMtgDuvF5Jh/Ri1fA5C7YJYkaV31ebg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBKCc-0002Bl-KL for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 15:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Nov 2024 20:43:02 +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.17315305528353 (code B ref 74339); Wed, 13 Nov 2024 20:43:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 20:42:32 +0000 Original-Received: from localhost ([127.0.0.1]:43823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKC8-0002Ad-5E for submit@debbugs.gnu.org; Wed, 13 Nov 2024 15:42:32 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKC5-0002AD-Dp for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 15:42:30 -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 1tBKBx-0000rS-Us; Wed, 13 Nov 2024 15:42:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lAdmTdMYV97cCHO89T7SokQZ8WfOqMjUJtYkUD0N9lY=; b=IxaKwFgjjFrkuvk7zifq o9hSunMZj4/F0z44PJUPVGYvqvYB16FviqpHRNORirFcrsTb6iZ//u9MtrkoTv7k4PpftYyMUV2lF YbSY74ft5mnim6yn1sJYOnkEtRthsw7pCaaT9UCPGicibREjNIDvomkGxVsCRWU1+Qvub3hmzlmNm BI2tsH/qvHdZS8ZLVHv0Niz4XiUQWJ5e8+G549lMyij2PuuDIke/khwk5jHVpVE2jMivCHgPE1njr 7AE7eiz+ukUcgWGsJjmRRs2dvyqKV2NJuW/liiuGnb2llLbRV0QWrpnkY+hlANjqTylTuc7nrxlom +vxtFzdMzjWI8Q==; In-Reply-To: (message from Stefan Monnier on Wed, 13 Nov 2024 15:28:08 -0500) 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:295289 Archived-At: > From: Stefan Monnier > Cc: 74339@debbugs.gnu.org, Alan Mackenzie > Date: Wed, 13 Nov 2024 15:28:08 -0500 > > I hadn't actually looked at that code. > > AFAICT it's the result of the decision to make `c-ts-mode.el` add itself > to `major-mode-remap-defaults` when the file is loaded (which AFAIK we > don't want to re-discuss). To defend against the case where that file > was loaded without the intention to use c-ts-mode everywhere the above > code "one ups" `c-ts-mode.el`s settings so as to take precedence > over them. > > Looks like an arms race to me. 🙂 Not a race, more like a knockout: once cc-mode is loaded, the race is over. > I think a "more fair" solution would be to do something like: > > ;; Make entries in `major-mode-remap-defaults' to ensure that when CC > ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's > ;; modes rather than c-ts-mode etc.. > (when (boundp 'major-mode-remap-defaults) > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > (let ((entry (assq mode major-mode-remap-defaults))) > (when entry > (setq major-mode-remap-defaults > (delq entry major-mode-remap-defaults)))))) > > The idea being that whichever file was loaded last (`c-mode.el` or > `c-ts-mode.el`) would take precedence. Yes, that's what I was suggesting. I don't understand why this was not done to begin with, except if the current code was a thinko. > Personally, my vote is for neither file to touch that > `major-mode-remap-defaults` variable when it is loaded. > Instead, they each could emit a message encouraging the user to > customize `major-mode-remap-alist`. > Maybe they could do that only when they see that the "other" file/mode > is also loaded (i.e. only once we have evidence that there is > a conflict). We can try other methods on master (and there's actually a discussion there about this). But on the release branch we cannot make such changes, we must instead fix this stuff so that, from the user perspective, Emacs 30 works the same as Emacs 29: if the user loads c-ts-mode, C/C++ files are visited in c-ts-mode, until cc-mode is re-loaded.