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:13:02 +0200 Message-ID: <86r07elwoh.fsf@gnu.org> References: <868qtnfd2d.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24463"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 74339@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 13 21:14:31 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 1tBJl0-0006ES-P8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Nov 2024 21:14:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBJke-0006yl-38; Wed, 13 Nov 2024 15:14:08 -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 1tBJkb-0006yO-B9 for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 15:14:05 -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 1tBJkZ-0005w2-Bp for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 15:14:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=ktzJny2UUU00cmYFTuphIFS/OBrzZ9gXI7rEv4c5VKU=; b=llbyN8HkBPcWB4f6yzJHJZJzM/zCoGieOgxnQlLGY0CaE7YiG+YSXtd5ijRFm5EufLapuTVlUUgFncMOff5GO0dqoEpSn2O6mBqgECReZg+JDzXUw6UWsKA+ZdF31F14qgpQraJxF3HbfL7fuOZB6Q62J6ByuiReCRZ30aD8kerMeqb2zwli5Uvbh82ytZCFXwhvyHkEVV76hX23aV3jeXBRaQVRiQ4/FDlLvjw5ORq/IDwE+PdWu1/uGbPHq1ewG5J/T/erD4Nks1AnOV8tG0A/Da9qMICBmjznkJSd6kEblDP6+ekpDlEXdxTtC9u9xkusQcsH+DNZig0Hh3Oc1A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBJkY-0000oS-5a for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 15:14: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:14: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.17315287953066 (code B ref 74339); Wed, 13 Nov 2024 20:14:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 20:13:15 +0000 Original-Received: from localhost ([127.0.0.1]:43758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBJjm-0000nN-Lv for submit@debbugs.gnu.org; Wed, 13 Nov 2024 15:13:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBJjk-0000n8-Es for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 15:13:13 -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 1tBJjd-0005tE-FM; Wed, 13 Nov 2024 15:13:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ktzJny2UUU00cmYFTuphIFS/OBrzZ9gXI7rEv4c5VKU=; b=V6+z3yUwnCjn 1Bq878d2Vdi73r7pVsaq7HF317LOW6mK6mtQ0iS9h5bYZJl7Mc7Q3ud0YczDS7XFbe0bVfOJIm0a7 6IuQ/i06fewTovdl+OKf8syK8Lhefps8raB5bpRL8InENIV+qVetZXHY3TjvKfyEWZw9wobHX8uOB BLAARg4HQ3O0dQESpi1KSwfWa9h2YZyKPb/Y4rbYN+zT2c4SmC4F+qHvMObPCf2ecRUDcpBL6Mriz GbQrWri4q6r9GLA5abaCkFmDCXrrPE+wcZFqfgDEq/87TKCWhLpO8a7fD30NjS5dyxswdbVetaajO NLXj2oNAOEupLuWXxqf17Q==; In-Reply-To: (message from Alan Mackenzie on Wed, 13 Nov 2024 18:58:01 +0000) 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:295286 Archived-At: > 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. 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. > 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 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. Why you take that personally is beyond me. 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?? > 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. Why is that a problem? More importantly, why the "solution" is to completely subvert user settings?? > 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. This bug report is not about the lack of discussion, it is about the current behavior of Emacs 30 which IMNSHO is simply unacceptable. There's no precedent to Emacs ignoring user preferences. 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. > >>>> 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? 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. Did you really mean that to be the result of your changes? > 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! > 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. > 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, and I'm not interested in having the -*- c -*- cookie invoke c-mode when the user prefers c-ts-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, 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. 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. > 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? 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.