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: Fri, 15 Nov 2024 13:04:25 +0000 Message-ID: References: <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.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="37274"; 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 Fri Nov 15 14:05:20 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 1tBw0l-0009Vq-Cr for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Nov 2024 14:05:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBw0W-0001Rt-T0; Fri, 15 Nov 2024 08:05: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 1tBw0U-0001QX-MI for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2024 08:05: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 1tBw0T-0003Ex-TE for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2024 08:05: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=pFUlQN0bOVSSDmxL3+3RBofxu9Hs2LCLVQQuVtnWF/k=; b=p46+gv4pycO+ZvDOz77pxhPy5pfsnjH3mgNmGr3oFkVeJH89IxFJ7Z3X/qSP00w2LkdgvBCa8WmsNWH3fuhVB9fQSp82q+NkLNVemlQCiFtRskpaWk3hMkN32qSXRHXFRIIFksgkL87M+wMSNVHcGq9bctZEYgKaJtJbhIDSdF1V3QOHpdKsPBc0VlYqNioaQibTRHLuvZr6FuJ6GymIQ6kxi88LRdqXarTuZaiT6GL4bDeO666wRTJuohOLBu8g6pjUnokhQKydTNdAYdzn285efHVzXw1mY7vLFjM9I3NuTrLuO7QEICh2enkL6pIYanZB7s96Oa+KsQUrGc5zgg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBw0T-0003iu-Jb for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2024 08:05: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: Fri, 15 Nov 2024 13:05: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.173167587714276 (code B ref 74339); Fri, 15 Nov 2024 13:05:01 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 13:04:37 +0000 Original-Received: from localhost ([127.0.0.1]:48967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBw04-0003iA-Gb for submit@debbugs.gnu.org; Fri, 15 Nov 2024 08:04:37 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:59511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBw01-0003hw-9f for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 08:04:34 -0500 Original-Received: (qmail 5887 invoked by uid 3782); 15 Nov 2024 14:04:26 +0100 Original-Received: from muc.de (p4fe1581d.dip0.t-ipconnect.de [79.225.88.29]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 15 Nov 2024 14:04:25 +0100 Original-Received: (qmail 9693 invoked by uid 1000); 15 Nov 2024 13:04:25 -0000 Content-Disposition: inline In-Reply-To: <86wmh5hrya.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:295392 Archived-At: Hello, Eli. On Fri, Nov 15, 2024 at 09:33:17 +0200, Eli Zaretskii wrote: > > Date: Thu, 14 Nov 2024 20:38:40 +0000 > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > From: Alan Mackenzie > > > 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? > The symmetry that I was talking about is in handling c-mode > specification in auto-mode-alist: it will either invoke c-mode or > c-ts-mode. Excuse me, but that is NOT symmetry. It is grossly assymetric. If you weren't agreeing to symmetry why did you say you were? > This is the issue at hand: to allow users to express their preferences > about c-mode in a way that is reversible. See, it's starting already: the abuse of `c-mode' to mean "the current mode handling C" rather than "C Mode". It is this dilution of CC Mode's trademarks which will be so damaging to CC Mode. `c-mode' means C Mode, and must carry on meaning that. Why did you use `c-mode' in that way? You agreed, I think yesterday, that the solution we come up with will not damage CC Mode. I would like to be sure that this is still the case. > The symmetry is in what cc-mode and c-ts-mode do with > major-mode-remap-defaults: each one of them removes the existing > elements that remap c-mode and adds its own elements which prefer > itself for C files. IOW, the symmetry is in allowing users to prefer > c-mode or c-ts-mode as they wish, and allow them to change the > preference during a session with predictable results, regardless of > the preference: the preferred mode will be used after its file is > reloaded. Yesterday, you made several decisions/concessions: your post at Thu, 14 Nov 2024 18:59:53 +0200 read as follows: ######################################################################### > Date: Thu, 14 Nov 2024 16:20:37 +0000 > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > From: Alan Mackenzie > > > > I think so, provided there was symmetry between the tree-sitter > > > modes and CC Mode. I would suggest the obvious fix; loading > > > either one of the libraries should append its entries to > > > auto-mode-alist, having removed any "lower down" entries. > > > That's what I suggested. If you agree, let's make that change and > > move on. > > OK. It would seem there is then no need to put entries for > c-mode/c-ts-mode into major-mode-remap-defaults. I don't think this > solution is optimal, though. Perhaps we can come up with something > better for Emacs 31. But let's just go with this "last loaded wins" > strategem for Emacs 30. OK, thanks. So I guess you will soon make that change in cc-mode.el on the release branch? ######################################################################### As can be seen, you agreed to fix the bug by making entries in auto-mode-alist and not using major-mode-remap-defaults. Less than 24 hours later, you've changed your mind. How am I meant to keep up with this form of discussion? What changed between yesterday and today, that using auto-mode-alist is now no longer acceptable? I suggest again, that the use of auto-mode-alist in the way we agreed yesterday is the best way forward. It is simple, well understood, and has been in use for, perhaps, 40 years. It does not have the unpredictable effects that the use of major-mode-remap-defaults would have. No substantial objections to this fix have been raised, beyond "it's new code late in a release cycle". Whichever fix we use, there is going to be new code in the release branch. In any of these fixes, the code is going to be simple, easily tested, and well understood. So let's choose a fix for more substantial reasons. > There was never a feature in Emacs to invoke c-mode when a file > specifies c-ts-mode. (There are also no files which specify c-ts-mode > in their file-local variables, and auto-mode-alist doesn't mention > c-ts-mode, so such a remapping has a largely academic value.) The > current code in cc-mode.el, which adds elements to > major-mode-remap-defaults, doesn't remap c-ts-mode to c-mode, either. > So this interpretation of "symmetry" is a separate issue that should > be discussed separately, and we definitely don't want to add such > features to the release branch at this point, even if we agree to > having that in the future. > (Stefan's thinking is that it's probably wrong to specify c-ts-mode in > in auto-mode-alist and in file-local variables anyway, although this > is still under discussion. This is a critical point. I don't know why Stefan thinks it would be wrong to use auto-mode-alist. He hasn't said. I think it's the best solution available at the moment, as well as being the one we agreed to yesterday. > If we agree to that, it would mean that specifying c-mode in > auto-mode-alist and -* c -*- cookies in a file does not necessarily > mean to invoke c-mode literally, but instead to invoke the mode in > which the user wants to visit C files, i.e. a mode that is subject to > user options. How then would it be possible to specify C Mode in auto-mode-alist? It wouldn't. My proposal yesterday of using `current-c-mode' would solve this problem neatly - the user would be able to enter any of `current-c-mode', `c-ts-mode', or `c-mode' to express her meaning precisely. As I've already said, I think the -*- c -*- cookie ought to mean the current C mode, not C Mode, and that I've an implementation which does that. But that is surely a different issue from what we're discussing in this thread. > With that concept, remapping c-ts-mode to c-mode makes very little > sense. But this all is not yet finalized, certainly not in Emacs 30, > and thus is not relevant to the release branch, which is my main > concern in this bug report.) -- Alan Mackenzie (Nuremberg, Germany).