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: Thu, 14 Nov 2024 20:38:40 +0000 Message-ID: References: <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.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="39119"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 14 21:39:27 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 1tBgch-0009yb-9g for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Nov 2024 21:39:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBgcL-0003mT-5M; Thu, 14 Nov 2024 15:39: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 1tBgcJ-0003m4-7Z for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2024 15:39: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 1tBgcI-0001wS-SP for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2024 15:39: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=8u+9MMz/0D09Y/eMhgHwPuyHlem9bzHJetVoMeGglOo=; b=U/e6XeQlcn2CfhgcPqJfuYmhtpl7ef5WGdtqRqAO83c1KVgMHaDU5fTDWOArZCwRJHEmEwnTo3u2o401kfSpu5p9ZeVYRPP8zTzY2H9KZPb+ZSv8HuUiRNH2Nuomns0phRtjbaakJMtGAMr+HGqvfVYD1Q4qzDgJRQB0MOK7pbs1Jp4J/F3qhTJieXE7DoqC9PL0osk4+g1X5PMaYVysPpAtaFXv7VhQParoewr+0DsgMLhR6EXB5fLu7xk0dWKKUUl1te6P2d/IyyGZ90LG9pAKy1vJopFXrKqJyK5cpLl7g3VGqNg+xq/ISUSU85pcgQBwcDQHb8LdR0nOR+u9QQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBgcI-0002bT-D0 for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2024 15:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2024 20:39: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.17316167309988 (code B ref 74339); Thu, 14 Nov 2024 20:39:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 20:38:50 +0000 Original-Received: from localhost ([127.0.0.1]:47423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgc5-0002b1-Ku for submit@debbugs.gnu.org; Thu, 14 Nov 2024 15:38:50 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:14717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgc3-0002am-7e for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 15:38:48 -0500 Original-Received: (qmail 17529 invoked by uid 3782); 14 Nov 2024 21:38:41 +0100 Original-Received: from muc.de (pd953aec8.dip0.t-ipconnect.de [217.83.174.200]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 14 Nov 2024 21:38:41 +0100 Original-Received: (qmail 26880 invoked by uid 1000); 14 Nov 2024 20:38:40 -0000 Content-Disposition: inline In-Reply-To: <86zfm1in2p.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:295365 Archived-At: Hello, Eli. On Thu, Nov 14, 2024 at 22:21:02 +0200, Eli Zaretskii wrote: > > Date: Thu, 14 Nov 2024 19:53:33 +0000 > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > From: Alan Mackenzie > > > I prefer to make a simpler and more localized change, which only > > > manipulates major-mode-remap-defaults. I would not like to risk > > > changes like modifying auto-mode-alist, which might have other > > > unintended consequences, at least on the release branch. > > I thought we'd agreed to fix things by modifying auto-mode-alist. > I wasn't aware of that. I apologize if I missed some words to that > effect. I thought we were always talking about fixing the values > pushed into major-mode-remap-defaults. > > What we definitely agreed was that the old modes and the tree-sitter > > modes should be handled symmetrically, and that C Mode and friends > > wouldn't be disadvantaged. > Yes. > > > Let's stay with major-mode-remap-defaults, since we already understand > > > well enough what the code does, and need just to tweak it in minor > > > ways. > > OK, then the following suggests itself. We have symbols like > > `current-c-mode' which would be remapped in major-mode-defaults-alist, > > and would be the cdrs of the entries in auto-mode-alist. We would remap > > `current-c-mode' each time cc-mode.el or c-ts-mode.el was loaded. This > > would avoid the need to modify auto-mode-alist at run time, and also > > avoid all the disadvantages of remapping `c-mode' itself. > There's no current-c-mode in Emacs now. So doing it that way would > mean significant changes to Emacs, and I'd like to avoid that on the > release branch. > What I meant is to modify cc-mode so that it removes the entries > pushed to major-mode-remap-defaults by c-ts-mode and then pushes its > own entries which map c-mode etc. to themselves. And c-ts-mode will > be changed to do the opposite. This is a small, localized change, > which will leave everything else intact, and will allow users to > express their preferences by just loading the mode they want to use. How is that symmetrical between c-mode and c-ts-mode? The very nature of the entries you're intending to make in major-mode-remap-defaults is asymmetric, in that they would remap `c-mode', but wouldn't remap `c-ts-mode'. Or have I missed something? -- Alan Mackenzie (Nuremberg, Germany).