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 22:34:19 +0000 Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.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="11736"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Stefan Monnier , 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 23:35:29 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 1tBLxQ-0002s0-LM for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Nov 2024 23:35:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBLxC-0005gZ-HF; Wed, 13 Nov 2024 17:35:15 -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 1tBLx1-0005cC-KE for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 17:35: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 1tBLx0-0006KV-TT for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 17:35:03 -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=GwlTLiDa3+su90XYjfSMDAMj0a2my0Kz7ItNVWTaVjE=; b=c7hUpPt7AvjD6UI+m/qW1IzU5LHAYzqHsutbAvcwqemoA9STJKOIhSSg3MyNG3jpXmqTfImQAlugioJHgEI7UxNOwGoq2VUO0s954Ve3sTsDjUT8YYN9RKwTjBfHZ7CbCFrkVkVhgbXPHDegRf7VcNg19OpKI4J+PfuxUzhaM7QnS5HtsndxIEasjiQGJiJmup7zNEXMC7wjEu96Vdf3y4HZ1t1cOw1KoWPwDvbX0DUnWVKUsfeq8sEp4ENNfRv+XZFKKraY58nhnsiOUCC8o4dGjehJmpOFhBsgCfO+JkAx6PtBlur9gyAaOwEZ0VgrGBeGH9qPoYirvs0v7Bba8w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBLx0-00075R-E6 for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 17:35: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: Wed, 13 Nov 2024 22:35: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.173153727127193 (code B ref 74339); Wed, 13 Nov 2024 22:35:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 22:34:31 +0000 Original-Received: from localhost ([127.0.0.1]:44028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBLwU-00074W-20 for submit@debbugs.gnu.org; Wed, 13 Nov 2024 17:34:30 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:13690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBLwR-00074D-7K for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 17:34:28 -0500 Original-Received: (qmail 1059 invoked by uid 3782); 13 Nov 2024 23:34:20 +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 23:34:20 +0100 Original-Received: (qmail 17950 invoked by uid 1000); 13 Nov 2024 22:34:19 -0000 Content-Disposition: inline In-Reply-To: <86r07elwoh.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:295296 Archived-At: Hello, Eli. On Wed, Nov 13, 2024 at 22:13:02 +0200, Eli Zaretskii wrote: > > Date: Wed, 13 Nov 2024 18:58:01 +0000 > > Cc: 74339@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > 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. > c-ts-mode was not stomping over anything. It was. > When the user expresses her desire to use c-ts-mode, Emacs arranges for > C files to use c-ts-mode. That's what users expect from Emacs when > they express their preferences. Yes, and if the said user wants to go back to C Mode, she should be able to. Before my patch this was difficult. Anybody wishing to use c-ts-mode can use it, by use of the symbol `c-ts-mode'. > > I expected there to have been some negative feedback about > > my patch, and was somewhat surprised that it was apparently accepted. > You have never explained the actual effect of your changes: that once > CC Mode is loaded once, there's no way for the user to have c-ts-mode > used for visiting C/C++ files, except by manually turning on c-ts-mode > in each and every buffer, after the file is visited. Does that sound > to you as reasonable behavior? That's what this bug is about. I put in the commit message precisely how it would behave. Admittedly, the restriction to 63 character lines made it a little less clear, but the full description was there. > > > 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. > The symbol was not misused. The implementation of the user's > preference to use c-ts-mode was via major-mode remapping, that's all. The user expressing preference by setting major-mode-remap-alists was unaffected by my patch. > Why you take that personally is beyond me. Perhaps because I've been working over 20 years on CC Mode, care about it, and am loathe to see it consigned to oblivion by the surreptitious diversion of its users to c-ts-mode, etc. You would take it personally if somebody started using "Eli Zaretskii" to refer to some other Emacs maintainer. If you want to kill off CC Mode, then change the symbols `c-mode' and `c++-mode' to mean something else, so that its users can't find the modes they want. > Don't you agree that when the user wants to use c-ts-mode, Emacs needs > to obey? Well, currently it doesn't! Are you really okay with that?? When the user wants c-ts-mode she should be able to use the symbol `c-ts-mode', somehow. Likewise for C Mode and `c-mode'. If some user adds an entry to auto-mode-alist with `c-mode' in its cdr, do you really think it correct to start c-ts-mode? Because that was the state of Emacs -Q before my patch. Don't you agree something needs to be fixed, there? > > 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. > No, it doesn't. It uses remapping, that's all, and it does that only > if the user says-so. "Remapping" is a euphemism for stealing. And it is done not by the user but by the maintainer of c-ts-mode.el, who decided to "remap" `c-mode' away from C Mode and onto c-ts-mode. > Why is that a problem? More importantly, why the "solution" is to > completely subvert user settings?? It's a problem because it prevents CC Mode users from easily finding their preferred modes. The "solution" (my patch) didn't touch user settings. It altered default settings only. > > 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. > This is immaterial to the subject of this bug report. It's the main reason the bug happened. > This bug report is not about the lack of discussion, it is about the > current behavior of Emacs 30 which IMNSHO is simply unacceptable. I'm not arguing with that. > There's no precedent to Emacs ignoring user preferences. I think that's perhaps being a touch optimistic. Diverting C Mode into c-ts-mode is ignoring user preferences. We shouldn't do it. > I'm surprised you are arguing for this buggy behavior, instead of > discussing how to fix it, and fix it soon. Because we cannot possibly > release Emacs 30 with this bug. I've made quite a few suggestions about a fix. > > >>>> 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. > And you consider that sufficient to expect any meaningful response? Actually, yes. I'm only surprised it took nearly 6 months. > You haven't even hinted on what the solution will do, and certainly > didn't say that it would mean users will be _unable_ to make c-ts-mode > their preferred mode for C/C++ files. I described my patch in the customary detail in its commit message, giving a complete rundown of its mechanism. > Did you really mean that to be the result of your changes? No, I intended to spark some discussion about the faults in the then current implementation, namely that it would steal users away from CC Mode. > > I did indeed amend CC Mode as I suggested, and that was the patch > > currently under discussion. It is indeed not ideal. > It isn't "not ideal", it is simply buggy! We cannot possibly ignore > user preferences in this way. Users are used to load c-ts-mode and > expect that all the C/C++ files after that are visited using that > mode. Now this expression of user preferences is completely ignored! Can I take it that you will respect the choice of users who wish to remain on CC Mode as much as those who wish the new tree-sitter modes? > > 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. > If the user prefers to use c-ts-mode, then revert-buffer _should_ use > c-ts-mode, not c-mode. The same happens if you change the way > normal-mode determines the mode and then revert the buffer. This > change in what revert-buffer does is now another user expectation your > change has broken, and it, too, must be fixed. And if a user has made no such choice, normal-mode will forcibly change the major modes of their buffers, whether they like it or not. As I said earlier, I have a fix for this which I have not pushed to Savannah. > > 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. > I'm not interested in having revert-buffer ignore user preferences of > using c-ts-mode, ..... Instead Emacs ignores the perfectly reasonable preference to have buffers modes stay the same as when the user set them. > .... and I'm not interested in having the -*- c -*- cookie invoke > c-mode when the user prefers c-ts-mode. My fix here was having the cookie invoke the user's preferred mode. > So any changes in that direction are not welcome. > > > 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. > What happened in May is besides the point now, .... A large part of your recent posts has been about criticising me. What happened in May and before is the reason for this bug report. I certainly intend to learn from it. > .... but you cannot expect any meaningful responses if you don't > describe the solution. And if you thought the solution you were about > to install could be controversial, you should have triggered the > discussion yourself, by pointing the aspects which could be > controversial. That would have been responsible behavior of a mode > maintainer. Again, if the controversial aspects of the major-mode-default-alist plan hadn't been witheld from me, I would perhaps have been able to contribute to a solution in a more reasonable fashion. > But all this is water under the bridge now. The only thing I'm > interested in is how to fix this bad breakage, and how to fix it fast. > Because Emacs 30 is in the last stages of pretest, and I don't want to > delay the release. You've read my protests about how Emacs was before my patch. I ask for the fix not to disadvantage CC Mode again the way it was, and if possible to respect CC Mode's ownership of the pertinent symbols. > > 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. > Sorry, I disagree (and find your insistence unreasonable). Please > drop these arguments, they are not going to lead to anything > constructive. > > > 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. > If we can fix Emacs to behave like I described, i.e. return to the > state where C/C++ files are visited in cc-mode rather than in > c-ts-mode, just by reloading cc-mode, would you agree with such a fix? 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. > If yes, please start by explaining why you chose to modify > major-mode-remap-defaults to have this form, after cc-mode is loaded: > ((c-or-c++-mode) (c++-mode) (c-mode) (c-or-c++-mode . c-or-c++-ts-mode) (c-mode . c-ts-mode) (c++-mode . c++-ts-mode) (LaTeX-mode . latex-mode) (plain-TeX-mode . plain-tex-mode) (TeX-mode . tex-mode)) > Why do you need those (c-or-c++-mode) (c++-mode) (c-mode) entries > there, and why did you not remove the elements which remap to > c-ts-mode instead? The root cause of the bug is that the original > remapping entries are left in the list, and so add-to-list does > nothing. If this is on purpose, and not a simple thinko, then you > have a lot of explaining to do. Of course it was on purpose. I wanted to provoke discussion and argument, with the aim of getting a solution which would be fair to CC Mode, as well as to c-ts-mode. The previous state of the code was grossly unfair. Again, if I had been involved in the original discussions, none of this would have happened. -- Alan Mackenzie (Nuremberg, Germany).