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 17:58:35 +0000 Message-ID: References: <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.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="39892"; 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 18:59:21 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 1tC0bJ-000ADg-Ns for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Nov 2024 18:59:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tC0b3-0004hz-91; Fri, 15 Nov 2024 12:59: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 1tC0b0-0004hh-G1 for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2024 12: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 1tC0az-0005kj-Vu for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2024 12: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=auTpOO9gnP1lLVVgomXIJUUCME+pS+Jqg1CKqeA3hKg=; b=tUAyJeO2iOjc879cRXYWgboib+S7+P5Mq5CPRoSDFYNe2dGmri5IumS6LIEG3z9Ftnr10MXzVPUl9w+Qo0M17o+r0xpvd50USD+mSmmR2clQ0jWBle0DBq0Pijrwl5ck2GU5l9dJrmT4DcNhnbsWkkAD4bs5lNjdWh1s2Uao5UinhRrxso78fCQyI7su0iHufGK5J+LzdYQsmk4LrH6zl8tXZfeM8JkIzj1NiuLPr8kUX8UEtuy1gdkV9Vu+qaDZ3XxKZBYgTRwTc+gCwdMm8PaRAb4QiE2wSogsn8/czIiZWiOGZWOlMLL0tY5DJBY37XISUb4teYrXA1sjy1oIbg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tC0az-0000Bm-KB for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2024 12: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: Fri, 15 Nov 2024 17: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.1731693526704 (code B ref 74339); Fri, 15 Nov 2024 17:59:01 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 17:58:46 +0000 Original-Received: from localhost ([127.0.0.1]:50787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC0aj-0000BH-Hz for submit@debbugs.gnu.org; Fri, 15 Nov 2024 12:58:46 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:20797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC0ah-0000B4-B0 for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 12:58:44 -0500 Original-Received: (qmail 4137 invoked by uid 3782); 15 Nov 2024 18:58:36 +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 18:58:36 +0100 Original-Received: (qmail 17771 invoked by uid 1000); 15 Nov 2024 17:58:35 -0000 Content-Disposition: inline In-Reply-To: <86cyiwimlr.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:295409 Archived-At: Hello, Eli. On Fri, Nov 15, 2024 at 16:43:28 +0200, Eli Zaretskii wrote: > > Date: Fri, 15 Nov 2024 13:04:25 +0000 > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > From: Alan Mackenzie > > > 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? > It appears that we meant two different meanings of "symmetry" here. I > was agreeing to the meaning I had in mind, which I explained above. One can write, in the Local Variables: section mode: c-ts .. This will cause the buffer to start in c-ts-mode regardless of any other current settings. As from Emacs 30, you are proposing that there be no analogous setting for c-mode. Up to now, one has been able to write: mode: c .. When that line is followed by setting other CC Mode variables (as is surely common for any such use of the major mode setting) that will signal some sort of error on opening the buffer, should c-mode have been "remapped" to c-ts-mode. Or if it doesn't do that, those local variables will be disregarded. This is a Bad Thing. This symmetry between c-ts-mode and c-mode should be preserved. > > > 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? > We treat c-mode as a general indication that the file's contents is > written in C. That is how major-mode-remap-* machinery treats a > mode's symbol. Once we started supporting mode remapping, the literal > meaning of foo-mode to mean a single mode is no longer accurate, > because remapping might mean the actual mode that is turned on is a > different mode. When did this come up for discussion? I surely wasn't involved in any such discussion, and such a massive, far reaching change definitely ought to have been discussed. The consequence of that is that there is now no way unambiguously to refer to c-mode. > > 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. > I don't see any damage in what I propose. See my example above for an example of damage. The very fact that should this change go ahead, there will be no way for a user to specify c-mode unambiguously is damage. It hollows out the very substance of CC Mode, namely it's names. > Mode remapping doesn't denigrate the remapped mode, it is just a > vehicle for users to prefer a different mode without a lot of > customizations and changes to actual files. It is analogous to > changing the attributes of a face: the face is still called by the same > name, but its attributes can be very different. The face's functionality remains unchanged. "Remapping" mode names changes the functionality substantially. [ .... ] > > 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? > I've misread your proposal, sorry. I didn't see the reference to > auto-mode-alist, only to major-mode-remap-defaults. Avoiding adding > the c-mode entries to major-mode-remap-defaults is fine by me, if > c-mode will instead remove the entries put there by c-ts-mode. > (Although I think that it is better to add '(c-mode) after such > removal, for better reliability.) That's not what I meant by "avoiding adding the c-mode entries to major-mode-remap-defaults". What I meant was avoiding adding the c-mode entries to major-mod-remap-defaults. In particular by other modes which have no business messing with CC Mode's symbols. > > What changed between yesterday and today, that using auto-mode-alist is > > now no longer acceptable? > Nothing changed. I never wanted to change auto-mode-alist, as that > would mean going back. I simply missed your single reference to that, > sorry. So, it would appear the agreement we came to yesterday evening was totally illusory. There was no agreement. Neither of the two criteria we agreed upon look like they will be respected: (i) Symmetry between c-mode and c-ts-mode; (ii) No damage to CC Mode in the change; I don't see what you mean by "that would mean going back", or what would be bad about that; new doesn't always mean better. What's wrong with using auto-mode-alist for this purpose? It lacks the disadvantages of major-mode-remap-defaults, and I don't see what disadvantages it has itself. Can't we at least use it for Emacs 30, so that we have the opportunity (which there hasn't been up till now) to discuss the "remapping" without the pressure of an impending release? > > 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. > The new code I have in mind (similar to what Stefan posted) is a > simple change of the current code, and affects the same variable. The > suggestion to modify auto-mode-alist, by contrast, is a much more > significant change wrt what we have now. So I prefer the former, at > least for the release branch. The change to use auto-mode-alist would be minimal, and well within the scope of simple code review and testing. We are only discussing the release branch here; the damage done to CC Mode by the "remapping" of its symbols in Emacs 30, should it be implemented, namely loss of users, will be permanent, and not recoverable in future Emacs versions. Let's get it right, now. > > > 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. > He did, in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74339#77 : OK, thanks. He is proposing that the meaning of -*- c -*-, `c-mode' as used in normal-mode, etc., should, from the user's point of view, be changed in an opt-out fashion. He is proposing that there be no way to specify C Mode in a local variables section. Such changes should be opt-in, not opt-out. They would certainly need an entry in NEWS. if there's not already one there. > > >> Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`. > > > Why "always"? > > Because the preference between `c-mode` and `c-ts-mode` should apply not > > only to those files whose mode is decided by `auto-mode-alist` but also > > to those where this is decided via other means such as via a file-local > > `mode` setting, or via `magic-mode-alist`, or ... > > > 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. > If the user prefers to use c-ts-mode, Emacs should honor that. If the user expresses a preference for C Mode using "mode: c" in the Local Variables: section, that should be respected, too. c-ts-mode can be loaded without any preference being expressed by the user. M-x c-ts-mode does not necessarily mean the user prefers that mode, or wants "remapping"; she could equally well be just trying out the new mode. We should perhaps provide users with a means explicitly to express such a preference. > Users who want to use c-mode are supported by default, and don't need > to do anything. Thus, it is already possible to specify C Mode in > auto-mode-alist: that's the only mode mentioned there for C files. So > I don't quite understand your question: it is already possible to > specify C Mode, and we are actually doing that by default. That only applies to users using only CC Mode. Any deviation from this stricture (e.g., by having a c-ts-mode buffer in a desktop file) will break it. > > 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. > This can be discussed for master, but it is not appropriate for the > release branch, for the reasons I explained already. It is only the release branch, not master, which is going to damage CC Mode. We need to sort out these issues now. Why weren't they discussed long ago? -- Alan Mackenzie (Nuremberg, Germany).