From unknown Tue Aug 19 01:58:26 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#74339 <74339@debbugs.gnu.org> To: bug#74339 <74339@debbugs.gnu.org> Subject: Status: 30.0.92; CC Mode stomps C TS Mode Reply-To: bug#74339 <74339@debbugs.gnu.org> Date: Tue, 19 Aug 2025 08:58:26 +0000 retitle 74339 30.0.92; CC Mode stomps C TS Mode reassign 74339 emacs submitter 74339 Eli Zaretskii severity 74339 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 09:01:54 2024 Received: (at submit) by debbugs.gnu.org; 13 Nov 2024 14:01:54 +0000 Received: from localhost ([127.0.0.1]:41316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBDwQ-0000E9-8r for submit@debbugs.gnu.org; Wed, 13 Nov 2024 09:01:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:36396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBDwO-0000E0-Os for submit@debbugs.gnu.org; Wed, 13 Nov 2024 09:01:53 -0500 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 1tBDwK-0008B9-TL for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 09:01:52 -0500 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 1tBDw1-0005SB-HF for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 09:01:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=E28xLmGTdsxMDXfCC/ZH5uc7nplRjzR+kyORy3v1UUE=; b=JFWXKcsFua78Nh VsaWpVUfYDMWCCjqVeSapqfja98OMjEJI5kMmM9ANMQi6dMCKy86Hv4VqoPWxbX/rNUrAMQi1dCLD Kz3qUTnFGLfincDWYzHZaGGB6gyRmFp0uxM6RPOAVQPJIqbCxmN2rOiUzDT7ABnIhk3SRQFt5tczL fVp3wbCpQa2ylJsz4vhJ6y9dyScy844tgbziuSR3xCsVzAC1jeiRcJRBDGiBhrEM5kvr6HEJdY9kl 77bKAj0CNWFKRP0ichAuF9Uc4+tV9VDn0V59+waJfOw7FAp1mywe9yDm1Y318QkeBWWge+3Y2/RHj 2zzDiuUaJWD0oXrWOH4g==; Date: Wed, 13 Nov 2024 16:00:58 +0200 Message-Id: <868qtnfd2d.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 30.0.92; CC Mode stomps C TS Mode X-Debbugs-Cc: Stefan Monnier X-Debbugs-Cc: Alan Mackenzie X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) To reproduce: emacs -Q M-x load-library RET c-ts-mode RET C-x C-f src/buffer.c M-: major-mode RET => c-ts-mode So far, so good: the user loads c-ts-mode, which means she prefers C/C++ TS Mode for C and C++ files, so visiting a C file turns on c-ts-mode instead of the default CC Mode. But: emacs -Q C-x C-f src/dispnew.c RET M-x load-library RET c-ts-mode RET C-x C-f src/buffer.c M-: major-mode RET => c-mode This is unexpected. It means that if even a single file loads CC Mode, the user's preference of using C TS Mode is effectively ignored. This seems to happen due to this code in cc-mode.el: ;; Make entries in `major-mode-remap-defaults' to ensure that when CC ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's ;; modes rather than c-ts-mode etc.. (when (boundp 'major-mode-remap-defaults) (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) (let (entry) (dolist (mode '(c-mode c++-mode c-or-c++-mode)) (if (and (setq entry (assq mode major-mode-remap-defaults)) (null (cdr entry))) (setq major-mode-remap-defaults (delq entry major-mode-remap-defaults))) (push (cons mode nil) major-mode-remap-defaults)))) Here's what major-mode-remap-defaults looks like when I load c-ts-mode into "emacs -Q": ((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)) And here's how it looks if I first visit a C file (which loads cc-mode): ((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)) The above snippet from cc-mode.el was installed this last May, with the following log message: In normal-mode, make c-mode call c-mode when CC Mode is loaded 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. I don't quite understand the rationale (and even less the implementation), and don't recall any discussions of this; there's also no bug number for it. But clearly the result is not acceptable, and I very much hope that there's some simple bug here that can be fixed real soon. 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. 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. In GNU Emacs 30.0.92 (build 21, i686-pc-mingw32) of 2024-11-11 built on ELIZ-PC Windowing system distributor 'Microsoft Corp.', version 10.0.22631 System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.4460) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs --without-native-compilation 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils c++-ts-mode c-ts-mode c-ts-common treesit cl-loaddefs cl-lib thingatpt find-func rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process emacs) Memory information: ((conses 16 49304 16294) (symbols 48 6997 0) (strings 16 17805 2859) (string-bytes 1 375146) (vectors 16 10077) (vector-slots 8 114927 6271) (floats 8 25 6) (intervals 40 301 140) (buffers 896 10)) From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 10:13:55 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 15:13:55 +0000 Received: from localhost ([127.0.0.1]:43119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBF47-0003yN-Bg for submit@debbugs.gnu.org; Wed, 13 Nov 2024 10:13:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBF46-0003yA-67 for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 10:13:54 -0500 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 1tBF3y-00063i-Ug; Wed, 13 Nov 2024 10:13:47 -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=Yjw6CQ8daflrlwP6LgXiIYBbkUYgsKdO+hM0F2O2zWs=; b=GopMfzFA415x p5gezfNyQ/yJCcTyksFpLuk/M2dP7pHbpI5T9rid+BejZKF/1ChSiNjEzOOjF795u6UWphk74NEG1 7mXTkK+jpgsWLa6qdrGA28q3PPlm/LLzS9VJUbjRLrzlZRCa/g+kQoMerQFL0QEbpKvwx+KpyLeov cR1nrnGSiD4RqmCfaEMaJEaoG+1tYCm+9JODv7MT2b2iTIb4HYHURyJ5Ls6u7xfj/G4Sh74T9ExYd ZX3h5vq1v03Jxt6ejeUC0NldGxaiiC7jKB4ra1LIf17sVoRKQGKSvEL/6H5VpKFf+ELP+A1Y0R2mV acf2zWGF12evnGpXazwawA==; Date: Wed, 13 Nov 2024 17:13:36 +0200 Message-Id: <86ttcbkvz3.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: <868qtnfd2d.fsf@gnu.org> (message from Eli Zaretskii on Wed, 13 Nov 2024 16:00:58 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Alan Mackenzie > Date: Wed, 13 Nov 2024 16:00:58 +0200 > From: Eli Zaretskii > > To reproduce: > > emacs -Q > M-x load-library RET c-ts-mode RET > C-x C-f src/buffer.c > M-: major-mode RET > => c-ts-mode > > So far, so good: the user loads c-ts-mode, which means she prefers > C/C++ TS Mode for C and C++ files, so visiting a C file turns on > c-ts-mode instead of the default CC Mode. > > But: > > emacs -Q > C-x C-f src/dispnew.c RET > M-x load-library RET c-ts-mode RET > C-x C-f src/buffer.c > M-: major-mode RET > => c-mode > > This is unexpected. It means that if even a single file loads CC > Mode, the user's preference of using C TS Mode is effectively ignored. > > This seems to happen due to this code in cc-mode.el: > > ;; Make entries in `major-mode-remap-defaults' to ensure that when CC > ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's > ;; modes rather than c-ts-mode etc.. > (when (boundp 'major-mode-remap-defaults) > (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) > (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) > (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) > (let (entry) > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > (if (and (setq entry (assq mode major-mode-remap-defaults)) > (null (cdr entry))) > (setq major-mode-remap-defaults > (delq entry major-mode-remap-defaults))) > (push (cons mode nil) major-mode-remap-defaults)))) > > Here's what major-mode-remap-defaults looks like when I load c-ts-mode > into "emacs -Q": > > ((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)) > > And here's how it looks if I first visit a C file (which loads > cc-mode): > > ((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)) > > The above snippet from cc-mode.el was installed this last May, with > the following log message: > > In normal-mode, make c-mode call c-mode when CC Mode is loaded > > 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. > > I don't quite understand the rationale (and even less the > implementation), and don't recall any discussions of this; there's > also no bug number for it. But clearly the result is not acceptable, > and I very much hope that there's some simple bug here that can be > fixed real soon. 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. > > 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. And adding Stefan to the discussion, since he wrote the major-mode-remap-defaults stuff in c-ts-mode.el. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 13:58:18 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 18:58:18 +0000 Received: from localhost ([127.0.0.1]:43645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBIZF-0005mu-Fo for submit@debbugs.gnu.org; Wed, 13 Nov 2024 13:58:18 -0500 Received: from mail.muc.de ([193.149.48.3]:49896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBIZC-0005me-CA for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 13:58:15 -0500 Received: (qmail 55490 invoked by uid 3782); 13 Nov 2024 19:58:03 +0100 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 19:58:02 +0100 Received: (qmail 14464 invoked by uid 1000); 13 Nov 2024 18:58:01 -0000 Date: Wed, 13 Nov 2024 18:58:01 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <868qtnfd2d.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868qtnfd2d.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Nov 13, 2024 at 16:00:58 +0200, Eli Zaretskii wrote: > To reproduce: > emacs -Q > M-x load-library RET c-ts-mode RET > C-x C-f src/buffer.c > M-: major-mode RET > => c-ts-mode > So far, so good: the user loads c-ts-mode, which means she prefers > C/C++ TS Mode for C and C++ files, so visiting a C file turns on > c-ts-mode instead of the default CC Mode. > But: > emacs -Q > C-x C-f src/dispnew.c RET > M-x load-library RET c-ts-mode RET > C-x C-f src/buffer.c > M-: major-mode RET > => c-mode > This is unexpected. It means that if even a single file loads CC > Mode, the user's preference of using C TS Mode is effectively ignored. [ .... ] > The above snippet from cc-mode.el was installed this last May, with > the following log message: > In normal-mode, make c-mode call c-mode when CC Mode is loaded > 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. I expected there to have been some negative feedback about my patch, and was somewhat surprised that it was apparently accepted. > 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. 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. 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. There _was_ discussion of the problem leading to the patch, in particular, starting from this post in emacs-devel: Date: Wed, 29 May 2024 11:16:44 +0000 To: Stefan Monnier Cc: Eli Zaretskii , emacs-devel@gnu.org Subject: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.] .. My final post in that thread, which nobody replied to, was: Date: Thu, 30 May 2024 11:02:13 +0000 To: Eli Zaretskii Cc: acorallo@gnu.org, dmitry@gutov.dev, monnier@iro.umontreal.ca, emacs-devel@gnu.org , in which my last paragraph was >>>> 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. I did indeed amend CC Mode as I suggested, and that was the patch currently under discussion. It is indeed not ideal. > .... there's also no bug number for it. But clearly the result is not > acceptable, and I very much hope that there's some simple bug here > that can be fixed real soon. 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. 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. > 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. 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. > 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. > In GNU Emacs 30.0.92 (build 21, i686-pc-mingw32) of 2024-11-11 built on > ELIZ-PC > Windowing system distributor 'Microsoft Corp.', version 10.0.22631 > System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.4460) [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 15:13:15 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 20:13:15 +0000 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 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 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==; Date: Wed, 13 Nov 2024 22:13:02 +0200 Message-Id: <86r07elwoh.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 13 Nov 2024 18:58:01 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Stefan Monnier , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 15:28:20 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 20:28:20 +0000 Received: from localhost ([127.0.0.1]:43794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBJyN-0001UQ-ND for submit@debbugs.gnu.org; Wed, 13 Nov 2024 15:28:20 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBJyL-0001UC-EF for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 15:28:18 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DEA27100126; Wed, 13 Nov 2024 15:28:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731529691; bh=wSz/etLbk5osYi3A3/C16UaPlH6jOvfhGJbkNSc5CCI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jevCnLBMouuwpHvVfRjv2MkDsKLuH8nQrocb68f+/p9hLJrJa7JrTwQVQb+65cU/3 52scikHiuEsf9hdBY6Xp95ChsMM6Lbh8boqRG2hihd20oPufd36qEitslH+q0gM6rn aro2MfH4pxOoWjJ1p/iKRoENtFFn7CFgcvn8ky3FE2a+VDik3C+bzNfefhacKbdTDG pJFuCy7xeFGnKtQvPriHY1I+NymusolcZBRBYCBH4aB9gEt8s3ICRhGHVfFvayo/Xe N+AG0BPJscoOuZ2jv5wHk6v9yO//prV18yqtQaDmmNro169NS+npXYgXxeoyONKVaT BZGgNOLNUbpBQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 10A4A100042; Wed, 13 Nov 2024 15:28:11 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F003C12047F; Wed, 13 Nov 2024 15:28:10 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <868qtnfd2d.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Nov 2024 16:00:58 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> Date: Wed, 13 Nov 2024 15:28:08 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.182 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Alan Mackenzie , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > This seems to happen due to this code in cc-mode.el: > > ;; Make entries in `major-mode-remap-defaults' to ensure that when CC > ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's > ;; modes rather than c-ts-mode etc.. > (when (boundp 'major-mode-remap-defaults) > (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) > (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) > (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts= -mode)) > (let (entry) > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > (if (and (setq entry (assq mode major-mode-remap-defaults)) > (null (cdr entry))) > (setq major-mode-remap-defaults > (delq entry major-mode-remap-defaults))) > (push (cons mode nil) major-mode-remap-defaults)))) Interesting! I hadn't actually looked at that code. AFAICT it's the result of the decision to make `c-ts-mode.el` add itself to `major-mode-remap-defaults` when the file is loaded (which AFAIK we don't want to re-discuss). To defend against the case where that file was loaded without the intention to use c-ts-mode everywhere the above code "one ups" `c-ts-mode.el`s settings so as to take precedence over them. Looks like an arms race to me. =F0=9F=99=82 I think a "more fair" solution would be to do something like: ;; Make entries in `major-mode-remap-defaults' to ensure that when CC ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's ;; modes rather than c-ts-mode etc.. (when (boundp 'major-mode-remap-defaults) (dolist (mode '(c-mode c++-mode c-or-c++-mode)) (let ((entry (assq mode major-mode-remap-defaults))) (when entry (setq major-mode-remap-defaults (delq entry major-mode-remap-defaults)))))) The idea being that whichever file was loaded last (`c-mode.el` or `c-ts-mode.el`) would take precedence. Personally, my vote is for neither file to touch that `major-mode-remap-defaults` variable when it is loaded. Instead, they each could emit a message encouraging the user to customize `major-mode-remap-alist`. Maybe they could do that only when they see that the "other" file/mode is also loaded (i.e. only once we have evidence that there is a conflict). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 15:42:32 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 20:42:32 +0000 Received: from localhost ([127.0.0.1]:43823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKC8-0002Ad-5E for submit@debbugs.gnu.org; Wed, 13 Nov 2024 15:42:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKC5-0002AD-Dp for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 15:42:30 -0500 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 1tBKBx-0000rS-Us; Wed, 13 Nov 2024 15:42:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lAdmTdMYV97cCHO89T7SokQZ8WfOqMjUJtYkUD0N9lY=; b=IxaKwFgjjFrkuvk7zifq o9hSunMZj4/F0z44PJUPVGYvqvYB16FviqpHRNORirFcrsTb6iZ//u9MtrkoTv7k4PpftYyMUV2lF YbSY74ft5mnim6yn1sJYOnkEtRthsw7pCaaT9UCPGicibREjNIDvomkGxVsCRWU1+Qvub3hmzlmNm BI2tsH/qvHdZS8ZLVHv0Niz4XiUQWJ5e8+G549lMyij2PuuDIke/khwk5jHVpVE2jMivCHgPE1njr 7AE7eiz+ukUcgWGsJjmRRs2dvyqKV2NJuW/liiuGnb2llLbRV0QWrpnkY+hlANjqTylTuc7nrxlom +vxtFzdMzjWI8Q==; Date: Wed, 13 Nov 2024 22:42:19 +0200 Message-Id: <86msi2lvbo.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 13 Nov 2024 15:28:08 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 74339@debbugs.gnu.org, Alan Mackenzie > Date: Wed, 13 Nov 2024 15:28:08 -0500 > > I hadn't actually looked at that code. > > AFAICT it's the result of the decision to make `c-ts-mode.el` add itself > to `major-mode-remap-defaults` when the file is loaded (which AFAIK we > don't want to re-discuss). To defend against the case where that file > was loaded without the intention to use c-ts-mode everywhere the above > code "one ups" `c-ts-mode.el`s settings so as to take precedence > over them. > > Looks like an arms race to me. 🙂 Not a race, more like a knockout: once cc-mode is loaded, the race is over. > I think a "more fair" solution would be to do something like: > > ;; Make entries in `major-mode-remap-defaults' to ensure that when CC > ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's > ;; modes rather than c-ts-mode etc.. > (when (boundp 'major-mode-remap-defaults) > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > (let ((entry (assq mode major-mode-remap-defaults))) > (when entry > (setq major-mode-remap-defaults > (delq entry major-mode-remap-defaults)))))) > > The idea being that whichever file was loaded last (`c-mode.el` or > `c-ts-mode.el`) would take precedence. Yes, that's what I was suggesting. I don't understand why this was not done to begin with, except if the current code was a thinko. > Personally, my vote is for neither file to touch that > `major-mode-remap-defaults` variable when it is loaded. > Instead, they each could emit a message encouraging the user to > customize `major-mode-remap-alist`. > Maybe they could do that only when they see that the "other" file/mode > is also loaded (i.e. only once we have evidence that there is > a conflict). We can try other methods on master (and there's actually a discussion there about this). But on the release branch we cannot make such changes, we must instead fix this stuff so that, from the user perspective, Emacs 30 works the same as Emacs 29: if the user loads c-ts-mode, C/C++ files are visited in c-ts-mode, until cc-mode is re-loaded. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 15:46:37 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 20:46:38 +0000 Received: from localhost ([127.0.0.1]:43836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKG5-0002NL-Hx for submit@debbugs.gnu.org; Wed, 13 Nov 2024 15:46:37 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKG3-0002N8-45 for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 15:46:35 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 65E24444A75; Wed, 13 Nov 2024 15:46:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731530788; bh=XzySCjwTA5TQ6eUy45G0ouPbPh/PX+f38j9UhXDEm0o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=W/tgEeVRf5XYUAzp7P5WRYizQsz61Ln2V/S267UM5rtmy5TYsHHD15ZDqiEnwfYxM xhsKIGPTb4TJxl87JQR8NR7rV9VB5Wm2v8P1sd0PpzbIKpMrOArYwBsPRrSoIzbkuW hMGz1H/hzlVvpdFpKE7Ud9vcbbENC1RjLRyyZtAVWWJOeThiqYpkt1wSQ2I68CuP51 d+wKiLdJL4s9/tzy2FkPkwNhuaFMX47/uDSzfMBiWdF3qiCYBp8TXBe6zApPEPymhz pFTcq2yeqlH9gkcEMTh76OG+LhIJLjuIYQefKNb61iEPdF49+fEF/kA/iMJr4ik2eg XjHb7iNwWBLOg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 59BDC444A66; Wed, 13 Nov 2024 15:46:28 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 45DFB1200A3; Wed, 13 Nov 2024 15:46:28 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86msi2lvbo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Nov 2024 22:42:19 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86msi2lvbo.fsf@gnu.org> Date: Wed, 13 Nov 2024 15:46:27 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.206 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> AFAICT it's the result of the decision to make `c-ts-mode.el` add itself >> to `major-mode-remap-defaults` when the file is loaded (which AFAIK we >> don't want to re-discuss). To defend against the case where that file >> was loaded without the intention to use c-ts-mode everywhere the above >> code "one ups" `c-ts-mode.el`s settings so as to take precedence >> over them. >>=20 >> Looks like an arms race to me. =F0=9F=99=82 > > Not a race, more like a knockout: once cc-mode is loaded, the race is > over. That's because you haven't seen the coming patch to `c-ts-mode.el` which removes the `cc-mode.el` entries, after which `cc-mode.el` will use another, yet sophisticated approach, etc... Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 17:34:31 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 22:34:31 +0000 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 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 Received: (qmail 1059 invoked by uid 3782); 13 Nov 2024 23:34:20 +0100 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 Received: (qmail 17950 invoked by uid 1000); 13 Nov 2024 22:34:19 -0000 Date: Wed, 13 Nov 2024 22:34:19 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86r07elwoh.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, Stefan Monnier , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 17:58:06 2024 Received: (at 74339) by debbugs.gnu.org; 13 Nov 2024 22:58:06 +0000 Received: from localhost ([127.0.0.1]:44055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBMJJ-000863-V4 for submit@debbugs.gnu.org; Wed, 13 Nov 2024 17:58:06 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBMJI-00085X-03 for 74339@debbugs.gnu.org; Wed, 13 Nov 2024 17:58:04 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2107D444AFF; Wed, 13 Nov 2024 17:57:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731538676; bh=DZTX8oMQIh9OQ0HCM+ipBqpnkRvpn31fOTlkTmIakKY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OqMPOutHbARjF35dTLbfy6zqyoEZqhc5XL7Ykk4U9F2IsljL7z47EcQf4MEdLA5dJ swr/L7yF9yU6EUms06NV6kG3msumpApt3kFjHPkOk9zTjbEYcfQa1paCZK40eynXRz iyuf7XhPONv5TU/WHyEXG/piTp8MgaOTI7SVy69stRDEOx11g4t0VBdkz4F7cG9hiE 1pDyj2vS4d8WFnf04K2dzAGeHrkBnaCtpmDmN5tNZkn7hajwHhyhutRz11HEcJRBZr mzWAaKiqtsSQUISi3onwech6t04LW1NRSE759RkbcpKvZZQ4vVFgl1+D3WbZ0ZmU6U Var6BVReRsHpQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EBEC7444AFC; Wed, 13 Nov 2024 17:57:55 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D3C0A120176; Wed, 13 Nov 2024 17:57:55 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "Wed, 13 Nov 2024 22:34:19 +0000") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> Date: Wed, 13 Nov 2024 17:57:55 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.204 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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. It was (and still is) a small matter of configuring `major-mode-remap-alist`. > Anybody wishing to use c-ts-mode can use it, by use of the symbol > `c-ts-mode'. In order to work on all C files, this is done by ... configuring `major-mode-remap-alist`. Not sure why you say one of them is "difficult" but not the other. >> 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-alist was > unaffected by my patch. Indeed, and I think we should help the users add such a setting rather than have them depend on unreliable defaults which depend on which file is loaded or not or when. > 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. Really? I find that hard to believe when reading the code. AFAICT, in `emacs -Q` `major-mode-remap-defaults` is: ((LaTeX-mode . latex-mode) (plain-TeX-mode . plain-tex-mode) (TeX-mode . tex-mode)) and `auto-mode-alist` maps `.c` files to `c-mode` so I can't see how and why a C file would be put into `c-ts-mode` without some explicit action on the part of the user. > Don't you agree something needs to be fixed, there? I agree what you describe would be a bug, but I think there's something missing in your description. [ Sorry, that's all for now, I didn't have time yet to finish your message. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 01:59:44 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 06:59:44 +0000 Received: from localhost ([127.0.0.1]:44704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBTpP-000532-Hu for submit@debbugs.gnu.org; Thu, 14 Nov 2024 01:59:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBTpN-00052l-1J for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 01:59:41 -0500 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 1tBTpG-0007g9-80; Thu, 14 Nov 2024 01:59:34 -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=7q4GfwjN3lQbqUW9UKIm1uviMwts4GixqLXjnPddbxY=; b=BCnU57UHUWIe RpK6gJrnfq+SV7yCakYdN/rwZgGEwLkt0hHVy86+XTcxaflsG886X+26eSnfo0x542dim3zKLLznc tKu1+ULTIRN2QoAZF4eWySwJhs2OmsfA3Cez1j3yIXuZy5Zih+oj49aXNstDcvb5yW2nnUImT77WD M6WUU18aBxUdlNbMYm22p8N2ez41Rabf3LjLpwtlZp9DYybozScdwZdx+Lg2G9+30LItV+Zu2bbxe gnZJhvFHaPyS/MJqDqsRhiwc0WJEX88avxWJjFkVoSplrISn6RacgVu7xPI7M7Cw/svtOg1UVxVIr brWJkcPW0/DfxCBtqsSoUw==; Date: Thu, 14 Nov 2024 08:59:32 +0200 Message-Id: <86h68al2qz.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 13 Nov 2024 22:34:19 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 13 Nov 2024 22:34:19 +0000 > Cc: 74339@debbugs.gnu.org, Stefan Monnier , > acm@muc.de > From: Alan Mackenzie > > > > 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? Of course! That's what happens by default if the user didn't load c-ts-mode, and (under my suggested idea of a change) will happen if the user loads cc-mode after loading c-ts-mode. IOW, the last mode loaded will "win". > > 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. No, it won't. This could happen only if the user loads c-ts-mode in-between, which means the user prefers c-ts-mode. Without that, normal-mode will always revert to c-mode in the default Emacs configuration. > > 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. Reverting the buffer activates whatever major mode corresponds to the file name and other relevant settings at the moment of the reverting. If you modify those settings in-between, it is quite possible (and expected!) that normal-mode will activate a different mode. This is how Emacs always behaved (and should keep behaving). Anything else is against user expectations. > > 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. That's what I suggested. If you agree, let's make that change and move on. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 04:24:45 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 09:24:45 +0000 Received: from localhost ([127.0.0.1]:45040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBW5l-0003eY-4R for submit@debbugs.gnu.org; Thu, 14 Nov 2024 04:24:45 -0500 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]:41837) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBW5j-0003eL-Lg for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 04:24:44 -0500 Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfhigh.stl.internal (Postfix) with ESMTP id 5CB0525400E0; Thu, 14 Nov 2024 04:24:38 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Thu, 14 Nov 2024 04:24:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1731576278; x=1731662678; bh=f7+FjaUFRNfQ/AN5UAgrrijNbUMhkJJws0mHy+Ptqr4=; b= YH5EAZ6iOUr33cHrRmyNy9jh7lk/ya67/3O/AX4bFJaYKtTMq4Dfs5ywgG1UMoQP wC5hS0POSeBQE84gtI8mIh059CK8K/rw+yCE7j43jf/3cz6aGfqDvPG3i5XezXG6 tKGngRj1YB1qUfqFaQoOH1vEjJ0+/+3E0kTVVTRS4CjsqU/dgOXuCtJ4ugOgVyz5 enL9GSicbC8RAdaF1808BJKModGZeH3tU/4dk8go8NWILk9nv02yZPTHmw5GKEVw Zy174qeIIeJ5k8t9HcQ6v/lIJlztoMTrxGSzIAKV+58Q31G7So1U0NHgj8Af62/1 Tqz+HQfoI60hs/AuHYBqgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1731576278; x= 1731662678; bh=f7+FjaUFRNfQ/AN5UAgrrijNbUMhkJJws0mHy+Ptqr4=; b=N 7I0ym0P9SJetww/wY8m4f0ythoeRQA+HZ9pMPBZtJOImW8J+r9aCaJDSEXsSAB41 DbfaOfn+xqUn0WXpzlU1tho0sDT68ufCqLYyMMT9oS49zVnEtn4wJK1+F5EIppdh hSZv4mZ721319nK+anqvJI0phQN/bKf9taZZhXsQMwLSJs3kMzps2hEyfztMg8HM Uhc+OCPIKTShaUz+vZIaimBZyl2hYreaQbQ+RmNS7tPhibCYlQ9Br3NvPWbkLWj/ cPsJW7D5WjORlet3ShpjDUldyuBJ+olAjke0L7DYWgaSIwf7XogHq7upxir9ppKn RiD3gK9kEEk0jmoU2R23Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrvddvgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpd hrtghpthhtoheprggtmhesmhhutgdruggvpdhrtghpthhtohepmhhonhhnihgvrhesihhr ohdruhhmohhnthhrvggrlhdrtggrpdhrtghpthhtohepjeegfeefleesuggvsggsuhhgsh drghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Nov 2024 04:24:35 -0500 (EST) Message-ID: <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> Date: Thu, 14 Nov 2024 11:24:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii , Alan Mackenzie References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86h68al2qz.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 14/11/2024 08:59, Eli Zaretskii wrote: >> 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? > Of course! That's what happens by default if the user didn't load > c-ts-mode, and (under my suggested idea of a change) will happen if > the user loads cc-mode after loading c-ts-mode. IOW, the last mode > loaded will "win". JFYI, 'M-x js-ts-mode' loads cc-mode. >> 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. > No, it won't. This could happen only if the user loads c-ts-mode > in-between, which means the user prefers c-ts-mode. Without that, > normal-mode will always revert to c-mode in the default Emacs > configuration. I'm personally skeptical that loading a package (or invoking a mode) indicates a strong user preference, but ok, let's call it that. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 05:05:26 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 10:05:26 +0000 Received: from localhost ([127.0.0.1]:45132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBWj7-0005iE-Ip for submit@debbugs.gnu.org; Thu, 14 Nov 2024 05:05:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBWj2-0005hv-3E for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 05:05:24 -0500 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 1tBWiv-0008EX-0q; Thu, 14 Nov 2024 05:05:13 -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=//AzZYMqlSl4cUbxt3CnQashyBq96Qy4ApkDkQpEyzk=; b=fbouCi0bgrDL ujevfVSxu3MVGPrK0zs1ix5HZCkwIOn7XLJUQIwid/aQHaE7P3wpTGKy5wCb4TY674SH2AESvho8e fOtSQXjdyWxcDv1LML7HYQT97LDHVRkZ4OftvqknICYv/7TCjrjeJPhglN/sz0X+C9x3Y7RJ3iVOy tNqS9ceUIQYqS+60I+6BrRIZDY0xKhPWnB3+557m5vAJGeKPv/t3OruqtRzSFPYQvsWtqOL6A6mnK edmuQZwa1oGUO6cJTPKD2/EG09CZkjED/dPlOjhMuVOUp3Vqe4pkPJdLD7Udo0n5qZLgG7ZAoE3YC 3P6bejRqoboqH74fdfH1Dg==; Date: Thu, 14 Nov 2024 12:05:07 +0200 Message-Id: <86msi2jfl8.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> (message from Dmitry Gutov on Thu, 14 Nov 2024 11:24:32 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 14 Nov 2024 11:24:32 +0200 > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > From: Dmitry Gutov > > On 14/11/2024 08:59, Eli Zaretskii wrote: > >> 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? > > Of course! That's what happens by default if the user didn't load > > c-ts-mode, and (under my suggested idea of a change) will happen if > > the user loads cc-mode after loading c-ts-mode. IOW, the last mode > > loaded will "win". > > JFYI, 'M-x js-ts-mode' loads cc-mode. That's because js.el does that. This was so in Emacs 29 already. And there are other packages that do the same: $ fgrep -R "(require 'cc-mode)" ../lisp --include="*.el" ../lisp/generic-x.el:1275:(require 'cc-mode) ../lisp/org/ob-C.el:39:(require 'cc-mode) ../lisp/org/ob-fortran.el:36:(require 'cc-mode) ../lisp/progmodes/antlr-mode.el:84:(require 'cc-mode) ../lisp/progmodes/cmacexp.el:91:(require 'cc-mode) ../lisp/progmodes/csharp-mode.el:34:(require 'cc-mode) ../lisp/progmodes/cwarn.el:107:(require 'cc-mode) ../lisp/progmodes/hideif.el:120:(require 'cc-mode) ../lisp/progmodes/js.el:48:(require 'cc-mode) I guess users who use these features and want to use c-ts-mode as their C major mode will need to use with-eval-after-load to restore the preferences after loading one of these packages (or customize major-mode-remap-alist). Ugh! > >> 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. > > No, it won't. This could happen only if the user loads c-ts-mode > > in-between, which means the user prefers c-ts-mode. Without that, > > normal-mode will always revert to c-mode in the default Emacs > > configuration. > > I'm personally skeptical that loading a package (or invoking a mode) > indicates a strong user preference, but ok, let's call it that. We can change this in Emacs 31, but it's too late for Emacs 30. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 10:51:43 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 15:51:43 +0000 Received: from localhost ([127.0.0.1]:46830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBc8F-0005gF-DO for submit@debbugs.gnu.org; Thu, 14 Nov 2024 10:51:43 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBc8D-0005fy-MF for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 10:51:42 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 55BB3100180; Thu, 14 Nov 2024 10:51:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731599495; bh=EdVGodqxWZQp+8KLifHcYi3bUuC4L8DhA9jzB4rA+SY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Emw7zO7vu5crdTp5xEvmbSpe2WtyCTiP9PsQ88gOwpF4iHPxutH2u0GbxFs6iWDwY hiXS/Vnr1PYLZRIhbpSKCQZwL4eKIWjpMdOB51E5giYGBW1r00HjvFTH4ZlnWKTl+3 q6EsUOTPiPQFcLNcuEH3nUPR4duN1XG+JATpFGU6eeZTLveutI8baUUP0UYkGBgao0 PqDjWeG/tPE20YwY/KJNJSF6VwuYiyiX2uazzxeRB37dwHeQLQdO3hG6eGULpBvvPt CeJTGJ6Rm15aFTo9edMjG/7NzcbwducrXL8Md3x+92RA/3leaDtf837MDCkYrEnj3N RFRe1K8Xs24hw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AB1E9100043; Thu, 14 Nov 2024 10:51:35 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8462B120346; Thu, 14 Nov 2024 10:51:35 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> (Dmitry Gutov's message of "Thu, 14 Nov 2024 11:24:32 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> Date: Thu, 14 Nov 2024 10:51:34 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.252 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Alan Mackenzie , Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I'm personally skeptical that loading a package (or invoking a mode) > indicates a strong user preference, but ok, let's call it that. Indeed, I think loading a package does not show a strong user preference. As we've seen, it can happen "by accident" in various circumstances that are only loosely related to using the code in that file. Invoking a mode is a significantly stronger signal. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 11:20:50 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 16:20:50 +0000 Received: from localhost ([127.0.0.1]:46891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBcaP-0007ED-8T for submit@debbugs.gnu.org; Thu, 14 Nov 2024 11:20:49 -0500 Received: from mail.muc.de ([193.149.48.3]:35503) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBcaM-0007Dx-14 for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 11:20:47 -0500 Received: (qmail 24518 invoked by uid 3782); 14 Nov 2024 17:20:39 +0100 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 17:20:39 +0100 Received: (qmail 11614 invoked by uid 1000); 14 Nov 2024 16:20:37 -0000 Date: Thu, 14 Nov 2024 16:20:37 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86h68al2qz.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Thu, Nov 14, 2024 at 08:59:32 +0200, Eli Zaretskii wrote: > > Date: Wed, 13 Nov 2024 22:34:19 +0000 > > Cc: 74339@debbugs.gnu.org, Stefan Monnier , > > acm@muc.de > > From: Alan Mackenzie [ .... ] > > 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? > Of course! That's what happens by default if the user didn't load > c-ts-mode, and (under my suggested idea of a change) will happen if > the user loads cc-mode after loading c-ts-mode. IOW, the last mode > loaded will "win". This is also not ideal, in that M-x c-ts-mode will mostly not change the preferred mode, but will do if it causes an autoload. I've been trying to think up something better, but all that springs to mind would be two commands `cc-mode-prefer' and `c-ts-mode-prefer'. > > > 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. > No, it won't. This could happen only if the user loads c-ts-mode > in-between, which means the user prefers c-ts-mode. Without that, > normal-mode will always revert to c-mode in the default Emacs > configuration. > > > 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. > Reverting the buffer activates whatever major mode corresponds to the > file name and other relevant settings at the moment of the reverting. > If you modify those settings in-between, it is quite possible (and > expected!) that normal-mode will activate a different mode. This is > how Emacs always behaved (and should keep behaving). Anything else is > against user expectations. OK, let's agree to disagree on this one. As a user, when I was comparing the two modes, I got annoyed at Emacs continually changing my major modes. I may not be the only one. Maybe (for Emacs 31?) there could be a user option to control this. > > > 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. > 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. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 11:30:12 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 16:30:12 +0000 Received: from localhost ([127.0.0.1]:46916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBcjT-0007ib-Tz for submit@debbugs.gnu.org; Thu, 14 Nov 2024 11:30:12 -0500 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]:46807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBcjR-0007cU-Uh for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 11:30:11 -0500 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 9DA9611401B5; Thu, 14 Nov 2024 11:30:04 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Thu, 14 Nov 2024 11:30:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1731601804; x=1731688204; bh=0bKWp/R9acWI+DLy0fWV45+BLpsdLwdJKbOZjqEU0j4=; b= WYyTjxRUIafEDy8bUoY5zqNNlY89C3EVdg3CqXzdeisHOq602eAdX92FteU3QROm wMWR+T2kdq/2qmuwReViQgZ7aVtmnoPB0jHZu/kV4bfn9JZlI9k4jzUgq3/Dacn7 8zpB4M7WdPxB54rruY2vt6ej+u1RpHFM/9CAaQGDVQaRXOj8vb7DuqQPVU3JIfG5 ymGM2nJ9GHt3VXZBmj7p1ViVS3NfkLspu4YXaZb9b4DvZ3TYldQacR4b36dXUlRH oEGBJ+8ruv4/mpmUy3J2ZyawAa64tp+SnA6jLiYDbzZCsJAhLSPEgeI+pBicGtxn hVyBCPcV23hKIBOMfjSTVw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1731601804; x= 1731688204; bh=0bKWp/R9acWI+DLy0fWV45+BLpsdLwdJKbOZjqEU0j4=; b=c HzdbOp73AKm0g1t00eeez2J+KIBp51vyNFSYLOAbOdmOa6ySV6D5GgYlM/MBbkBK xLZ7v5Ynftv0CanhHX17Krqfk+PmVZ4kh4+XyJ8OuqUCERLvoOu1q70IqoooxE9w M5h5CvalMk6AFchDalXx81TgWDqlNq9as7eVemzda7BmkFABd6RVtaZ4sOxq+xlc qFUfSJ3xQpnM73y2BEn0d1fMzMglmNaSYtY+IDDouLusjO3bRPhXEVHNnPOA+iOM xPBEq2oIxwauZ4ckd9D9CmKsAP7CsKqQN5RC43l6/unDLwoZmtjaKAz5MSd0beb1 ANNFVPecJPQ3RoTfiwtDQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrvddvgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfhuffvvehfjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpedtgfegtdehvedvjeejffetgfdtgfefheevjeekieej tefgffdtheefvdfgtdevueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhhonhhnihgvrhesihhrohdruh hmohhnthhrvggrlhdrtggrpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghp thhtoheprggtmhesmhhutgdruggvpdhrtghpthhtohepjeegfeefleesuggvsggsuhhgsh drghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Nov 2024 11:30:01 -0500 (EST) Message-ID: <9da676f4-a04e-4a09-90ab-fb2e7eba90fc@gutov.dev> Date: Thu, 14 Nov 2024 18:29:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Dmitry Gutov Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Stefan Monnier References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74339 Cc: Alan Mackenzie , Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 14/11/2024 17:51, Stefan Monnier wrote: >> I'm personally skeptical that loading a package (or invoking a mode) >> indicates a strong user preference, but ok, let's call it that. > Indeed, I think loading a package does not show a strong user > preference. As we've seen, it can happen "by accident" in various > circumstances that are only loosely related to using the code in > that file. > > Invoking a mode is a significantly stronger signal. Stronger yes, but is it strong? One might as well be testing the mode, without intention to set it up as the default. And how much does it help anyway? The result can only last until the end of the current session, after which the user would need to use one of the other approaches. Anyway, this is not a new argument. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 11:49:28 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 16:49:28 +0000 Received: from localhost ([127.0.0.1]:46941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBd28-000050-7O for submit@debbugs.gnu.org; Thu, 14 Nov 2024 11:49:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBd25-0008WP-IF for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 11:49:26 -0500 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 1tBd1y-00087J-Rx; Thu, 14 Nov 2024 11:49:18 -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=zRPNmC0ijbK3nArxZbeCOIeYvOWUrehz55TLNk0P2xU=; b=D/Tqwm1KKLbq 4HgnNovgqcqTiuP7TrdllHmeYD8T3qqbtvC9Ur2C4ref64aolI/WIm5tV6rzmrLnZqs52K4JGnxND UObtQBW3MNwHDuWV0VTjXx+ZuB9JP9qfwGvsfGfoZprsVwajDMBI3ZbIclqqn0qYCcAUpmOPdPkGp 2pWzhu5WFUsddmxjVpKalHpxviFFzYjDDsb4uJs5lB6p+dPqYDmQnfAAwQtK7UovIpSwRa+46GvHr JSbH2EwB71cYX7Qx1gRFoCRa9JR49uAg/8QnQtQpu1CdpvRewda8mHpf+SCTnGj8dVGNgTmGpDU7I efib9heChaSXf9TmIlU2xA==; Date: Thu, 14 Nov 2024 18:49:14 +0200 Message-Id: <86a5e1kbg5.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 10:51:34 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , Alan Mackenzie , > 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 10:51:34 -0500 > > > I'm personally skeptical that loading a package (or invoking a mode) > > indicates a strong user preference, but ok, let's call it that. > > Indeed, I think loading a package does not show a strong user > preference. As we've seen, it can happen "by accident" in various > circumstances that are only loosely related to using the code in > that file. > > Invoking a mode is a significantly stronger signal. But AFAIU the code in both c-ts-mode and cc-mode is written such that just invoking the mode (after the mode's package was loaded once) doesn't modify major-mode-remap-defaults. So unless I'm missing something, the current code doesn't support what you think should be the way for users to express their preference. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 12:00:44 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 17:00:44 +0000 Received: from localhost ([127.0.0.1]:46969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdD2-0000iw-8T for submit@debbugs.gnu.org; Thu, 14 Nov 2024 12:00:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdD0-0000ig-5g for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 12:00:43 -0500 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 1tBdCr-00032k-JT; Thu, 14 Nov 2024 12:00:34 -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=9eAqgWfQpiQ0Dbl9dHYH1wFFyUM+963QASEn8oNWhhc=; b=HlXcuGVNBAtR 02r4mBh0hxQyKnnSmEedkNrnna9Csbu5lWXmJF0Yt6nqnwwO7ZE9gaSVZh06ekPbdxwea2CUVF5ZT zZ18mF4PZqqxmUBMPc+YD35mi1eT8SdA8iEajaSoJeoPd1j7CliG5+g/B/s/7pJr8xKSv4U3YRH8B 1AXlB5UW0L1OQgWRpe7LVA3yyeTLOsDBjkQ9Rs2dSkwwdlAEV/z8GY+QIve4Ng1Bdpss1z5COYNbD +DOgg4l34sb5S333zFd0W/TanIhmnVa/1ByHhX87XJmXwvyHha/RHRX4EWUH2O/2lwDOQzuzsH4XD IJFesk4sEYbZaSGxG0V6jw==; Date: Thu, 14 Nov 2024 18:59:53 +0200 Message-Id: <867c95kaye.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Thu, 14 Nov 2024 16:20:37 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 12:16:49 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 17:16:49 +0000 Received: from localhost ([127.0.0.1]:47022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdSa-0001Wr-KJ for submit@debbugs.gnu.org; Thu, 14 Nov 2024 12:16:48 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdSY-0001WY-Mq for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 12:16:47 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 47D4A442A37; Thu, 14 Nov 2024 12:16:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731604599; bh=Eh8xxuh47rUdajW3eu+pEY3K1YjYjiBVZ9wyXghzcNg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jhOLM4TCuR4lJxks0HVjivMerEplyck1Hl3Xwe3dCmy4ChaPHNIbcI/xlgUdrfZ/S tiScfNmj8kLguo2WrpSEPfTiYrs/VyBuNqXOTEyKb56ixr2cs+AWItWDf0S+HiKLjR 2x72gj0o4ign1wSy8GexXD6Ri4G2VoZyLQsR2GQUHWtpmrMgD2yW8ScUUHVsY9aSbc Ln5Dxf7860hSJwiyT/HRHDh+4ieGbWj/k6a7lDfIgZPSXdQf11xibHHCpU4VrHxxUN dH5hiFA/wBMuuvjog+Y9tCCSJgLfmxidu7Wi5K4Wbj/rtzYD0urfJo5lkQzkD3VLhU Z6HMnj7uRAmng== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8334344261C; Thu, 14 Nov 2024 12:16:39 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 58A141204D5; Thu, 14 Nov 2024 12:16:39 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86a5e1kbg5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2024 18:49:14 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> <86a5e1kbg5.fsf@gnu.org> Date: Thu, 14 Nov 2024 12:16:38 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.066 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Indeed, I think loading a package does not show a strong user >> preference. As we've seen, it can happen "by accident" in various >> circumstances that are only loosely related to using the code in >> that file. >> Invoking a mode is a significantly stronger signal. Dmitry wrote: > Stronger yes, but is it strong? One might as well be testing the mode, > without intention to set it up as the default. And how much does it > help anyway? The result can only last until the end of the current > session, after which the user would need to use one of the > other approaches. I can't disagree. Eli wrote: > But AFAIU the code in both c-ts-mode and cc-mode is written such that > just invoking the mode (after the mode's package was loaded once) > doesn't modify major-mode-remap-defaults. Indeed. I had proposed a patch which sets `major-mode-remap-*` when we enable the mode rather than when we load it, but it was rejected because supposedly it did not correspond to the "least bad" compromise that resulted from a long discussion. > So unless I'm missing something, the current code doesn't support what > you think should be the way for users to express their preference. AFAIC, "the way for users to express their preference" is by customizing `major-mode-remap-alist` and is a different issue than the setting of `major-mode-remap-default` we're discussing, which is about trying to *guess* the user's preference. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 12:30:00 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 17:30:01 +0000 Received: from localhost ([127.0.0.1]:47038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdfM-00023s-DV for submit@debbugs.gnu.org; Thu, 14 Nov 2024 12:30:00 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBdfJ-00023S-UB for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 12:29:58 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0560C442B65; Thu, 14 Nov 2024 12:29:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731605390; bh=IFp6tKn8N4smSeIukKPXqVSch16vMJwIhSZ5oS//n6A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=L3omcXzn2TvSZzQ/nZIo7DYie9HLFBrJtXO4SfiuYpYww25BnLpdkYnx6jdDjfbuN XcWwNgfO/trkrGj/iBljrB2ivam5x7MFR5ToFVnxS8gBfvIT7R6rV02QZCwr/qoewn fM2Yr0nZNuTQq0cjn88CttPef7/kAn/e84sEVdVu8F0qqt38+JgiOIVFe68PmQICfR MOLs9p7OSUOnwu+BpRWLAd6W7E0q0NVmNv/7zHnfLA8eq9h+cQnUj4Ol3TZy/6vDcQ CC+85LOiEYOKFIIpPU1jOwY5CvKrVc5wZ95HGsiQTvdBEmPtAkNzMU0GgOxhqIwrj9 7R1ctaM2WjhdA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7CD46442B14; Thu, 14 Nov 2024 12:29:50 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5303412030F; Thu, 14 Nov 2024 12:29:50 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "Thu, 14 Nov 2024 16:20:37 +0000") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> Date: Thu, 14 Nov 2024 12:29:49 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.061 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Of course! That's what happens by default if the user didn't load >> c-ts-mode, and (under my suggested idea of a change) will happen if >> the user loads cc-mode after loading c-ts-mode. IOW, the last mode >> loaded will "win". > > This is also not ideal, in that M-x c-ts-mode will mostly not change the > preferred mode, but will do if it causes an autoload. I've been trying > to think up something better, but all that springs to mind would be two > commands `cc-mode-prefer' and `c-ts-mode-prefer'. There are two issues: setting `major-mode-remap-defaults` which is about guessing what the user's preference should be, and setting `major-mode-remap-alist` which reflects an explicit user act to state their preference. New commands `cc-mode-prefer' and `c-ts-mode-prefer' would customize `major-mode-remap-alist` whereas the code we're discussing is the one that sets `major-mode-remap-defaults`. Maybe we shouldn't set `major-mode-remap-defaults` at all, and instead when the user calls `c-(ts-)mode` but the `major-mode-remap-alist` selects the other mode, we should just emit a message telling the users to customize `major-mode-remap-alist` (or to call `c*-mode-prefer`) if they want to use that mode by default. >> > > 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. Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`. The choice between `c-mode` and `c-ts-mode` should be made via `major-mode-remap-*`. That's what those vars are for. So loading either mode should not change `auto-mode-alist`. IIUC the proposal to use the "last loaded" mode would be obtained, by making the two files set `major-mode-remap-defaults` accordingly. `c-ts-mode.el` already does that, so all we need is to change `cc-mode.el` so it puts itself first but doesn't prevent `c-ts-mode.el` from putting itself first in the future (contrary to what it currently does). The patch I sent earlier should do just that (by removing the entries added by `c-ts-mode.el` rather than by adding entries, so as to avoid growing `major-mode-remap-defaults` unnecessarily). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 12:45:38 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 17:45:38 +0000 Received: from localhost ([127.0.0.1]:47073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBduU-0002t2-44 for submit@debbugs.gnu.org; Thu, 14 Nov 2024 12:45:38 -0500 Received: from mail.muc.de ([193.149.48.3]:27204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBduS-0002so-4s for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 12:45:37 -0500 Received: (qmail 20720 invoked by uid 3782); 14 Nov 2024 18:45:29 +0100 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 18:45:28 +0100 Received: (qmail 12995 invoked by uid 1000); 14 Nov 2024 17:45:28 -0000 Date: Thu, 14 Nov 2024 17:45:28 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867c95kaye.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Thu, Nov 14, 2024 at 18:59:53 +0200, Eli Zaretskii wrote: > > Date: Thu, 14 Nov 2024 16:20:37 +0000 > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > From: Alan Mackenzie [ .... ] > > 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? OK, I can manage that. I'll just outline a quick outline of what I see is to be done, so as to fix any misunderstandings before starting to hack the code: (i) CC Mode and c-ts-mode will both keep their autoload directives. (ii) On loading either library, all their auto-mode-alist entries will be refreshed. By "refresh" is meant they will be removed from auto-mode-alist (if present) and put back again at the top of that alist. (iii) Evaluating a mode command does not change auto-mode-alist (except when it causes an autoload). (iv) The manipulations of major-mode-remap-defaults by both libraries will be removed, since they are redundant. Any comments? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 12:52:25 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 17:52:25 +0000 Received: from localhost ([127.0.0.1]:47082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBe13-0003Ai-2Q for submit@debbugs.gnu.org; Thu, 14 Nov 2024 12:52:25 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBe10-0003AT-Bg for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 12:52:23 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 615DA100180; Thu, 14 Nov 2024 12:52:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731606735; bh=hWJFHm+rP0DTUd8N3OqIrZYhvTQXSE6gGU80yyzeb50=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cP9vY90vcram71c4ZH8JDGMOdLbEnKwYxRTEQTbGVH/aEfBhtPMvSBfnL8ZWbFedc 0VWj7v/EzDIOyvtxMWpd+BO6DNYkYfgpsn9ax+7QY9nEcsx+E8mVqbSpI7TeK/9E4L PF6Ew1WQW7EvTPNmfYWw5wouqWKh3Mi26d+ytalrtWX7SfIP36Oz2eSNhin/bQvvcV aljt8v+ojh/dp1Jb4OKIya6IRMw1JUFV4powTAsH+rCBKrPB3V/dMB+819u3D9Ztne tFY7rtl51dMkeViG+l3u6OjwBArzFDveMlq7+hcixdiRoEITGTT04t/Ki/IL8ZfBny zVzZRH2HvVzNw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BBBE2100043; Thu, 14 Nov 2024 12:52:15 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 95F0C1202FD; Thu, 14 Nov 2024 12:52:15 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "Thu, 14 Nov 2024 17:45:28 +0000") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> Date: Thu, 14 Nov 2024 12:52:14 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.208 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > (ii) On loading either library, all their auto-mode-alist entries will be > refreshed. By "refresh" is meant they will be removed from > auto-mode-alist (if present) and put back again at the top of that > alist. Please don't touch `auto-mode-alist`. Only touch `major-mode-remap-defaults`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 14:10:16 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 19:10:16 +0000 Received: from localhost ([127.0.0.1]:47198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfEO-0006qs-C2 for submit@debbugs.gnu.org; Thu, 14 Nov 2024 14:10:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfEL-0006nJ-R1 for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 14:10:15 -0500 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 1tBfEE-0005uz-Cb; Thu, 14 Nov 2024 14:10:06 -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=kXxBOBA/u5KM+NxM7qvxgXU6ToZv5E0ZsFWUpwUKk28=; b=VytcnJunNBtC 7EzyQfiovodpYRBCNbTnR90uOmmnAd/UIj4n0q+nLBlYdJkTHdMt8jhHmgCs6QkS3qswHXKgJzf3D vQ4sMykFLLpS4IWvLXQ3AwKANfh3D7wMHsiGRozRxRiHYD9nFk25e2FpJg5IgyR9ktGJdjE/7cRYR VWDPN6CCRLyC6hD10yoPQlslMQEOKuHJnkBq0d7DD9hfa6O/hk80ZMYJZUoH6iMlaW3fpiGs8TKX4 vl50gYpZA1QI29GOfQzH/PkFTZkbO2tKFcm6Gke9ZLao9Xut5M/7MpNwU6v3HMbjXiu4CLh5zbe6S 2/Ce3qB8sESpDUR92QEMXQ==; Date: Thu, 14 Nov 2024 21:10:03 +0200 Message-Id: <864j49k4xg.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 12:16:38 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> <86a5e1kbg5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: dmitry@gutov.dev, acm@muc.de, 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 12:16:38 -0500 > > AFAIC, "the way for users to express their preference" is by customizing > `major-mode-remap-alist` This is not a user-friendly method, IMNSHO. Customizing major-mode-remap-alist requires too much knowledge of Lisp. How hard is it to imagine someone who puts wrongly-formatted elements into the alist, like sub-lists instead of cons cells? If the user just wants to tell Emacs: I want to use foo-ts-mode instead of foo-mode for language foo, there must be an easier way, like flipping some simple switch. So customizing major-mode-remap-alist is _a_ way to express this kind of preferences, but IMO we should be able to do better. In another discussion, I proposed to have simpler user option(s) that would allow users to express this preference, such that, say, auto-mode-alist would activate this or that mode given such a variable. I hope something like that will be possible in some future release. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 14:20:30 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 19:20:30 +0000 Received: from localhost ([127.0.0.1]:47211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfOH-0007Lw-IM for submit@debbugs.gnu.org; Thu, 14 Nov 2024 14:20:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfOE-0007Lg-Ai for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 14:20:27 -0500 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 1tBfO7-0000XO-H3; Thu, 14 Nov 2024 14:20:19 -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=e6h5XLQ1+4Lk1/M0iI4VwD3PbIcNkeb/rcsjxxpKvlg=; b=JFN4Dfgj2eFS Dn8WvLIyj2s+JxfLLzk7/vPOmkXACd/TB50VrmrhozOCjKex3I9jD1b2aXXKuNuXnlF7/LS3slMhr sdBKfzttbBclqF6m7DauqbU4kkVrKF8UvFG1J9vKC2/nwgDm8J5NRb/q264vNnj6AzyRb7Ng+K5/H /5MrBZdq6Zqh/Pu/vKvHpDRuy3YnKAZkxvIWTzRhfBGsN4uDV0xqwyuWy4XWouLIKqJmrrvIYXfi2 oWRweyBM0ueTp5VtfVEkBhKsMKq6TwHtNuYb/B6Mv+gEsB7drSbjC9K7cnqsJit+fICODKH6P1wBh dQ9e6FjFhi1Hvon4eI7nrw==; Date: Thu, 14 Nov 2024 21:20:12 +0200 Message-Id: <8634jtk4gj.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 12:29:49 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 12:29:49 -0500 > > Not quite: `auto-mode-alist` should always map `.c` files to `c-mode`. Why "always"? > The choice between `c-mode` and `c-ts-mode` should be made > via `major-mode-remap-*`. That's one implementation, but it isn't the only one, and I'm not sure it is the best one. > That's what those vars are for. major-mode-remap-alist is for remapping major modes in general, for whatever reasons. The non-TS vs TS modes is just one case where it can be used, but it is not the only one, and maybe not even the most important one. > So loading either mode should not change `auto-mode-alist`. It doesn't have to be due to loading the mode, it could be due to the user flipping some option. auto-mode-alist could stay the same, but the result of looking up the proper mode for a .c file will be different, depending on such a user option. > IIUC the proposal to use the "last loaded" mode would be obtained, by > making the two files set `major-mode-remap-defaults` accordingly. > `c-ts-mode.el` already does that, so all we need is to change > `cc-mode.el` so it puts itself first but doesn't prevent `c-ts-mode.el` > from putting itself first in the future (contrary to what it currently > does). I think both files should first remove the existing elements that remap c-mode and c++-mode. Otherwise add-to-list will do nothing. > The patch I sent earlier should do just that (by removing the entries > added by `c-ts-mode.el` rather than by adding entries, so as to avoid > growing `major-mode-remap-defaults` unnecessarily). This is not enough, I think. What will happen if, by some happenstance, major-mode-remap-defaults has both elements added by cc-mode and those added by c-ts-mode? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 14:23:52 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 19:23:52 +0000 Received: from localhost ([127.0.0.1]:47219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfRY-0007SI-BI for submit@debbugs.gnu.org; Thu, 14 Nov 2024 14:23:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfRV-0007S3-Lw for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 14:23:50 -0500 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 1tBfRQ-00011N-Ci; Thu, 14 Nov 2024 14:23:44 -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=aLowMLnVNXDaJZ5y9HR2YUKAwT7ZA7Jpe1mxrWC3QRY=; b=hkmpXzuLAY5s usN7U26LJ+2miHOnD5URMFnP4KTV+Du/jx16iEcZSqFs6+UrV6mnoKFtj1yUrrmixLYwcdtH1rc9f OH/ui3G72fHqlY1gvU0yClRFesRJVgcKJ3Oyo0GVv4YrrN1nbePm0q91iGQjeFaIzu5hCk63YIFir JItM4XJmsF2sUXDU7cSZmNKXH8amlXxiRH9D5703S5Vwx8uGR7z/4HVSuyLGFnzjt2R6IFURgdPK4 bfaFkI+XK98zGuo3r+34vgsnPx2JTP7lUDaK2p7y+rqr+EfN/nMiO/g2HqFdF7Od07ANrN0DQ0jYd nugcu2CL1WmHACIcvhqfog==; Date: Thu, 14 Nov 2024 21:23:41 +0200 Message-Id: <861pzdk4aq.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Thu, 14 Nov 2024 17:45:28 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 14 Nov 2024 17:45:28 +0000 > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > From: Alan Mackenzie > > Hello, Eli. > > On Thu, Nov 14, 2024 at 18:59:53 +0200, Eli Zaretskii wrote: > > > Date: Thu, 14 Nov 2024 16:20:37 +0000 > > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > > From: Alan Mackenzie > > [ .... ] > > > > 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? > > OK, I can manage that. > > I'll just outline a quick outline of what I see is to be done, so as to > fix any misunderstandings before starting to hack the code: > > (i) CC Mode and c-ts-mode will both keep their autoload directives. > (ii) On loading either library, all their auto-mode-alist entries will be > refreshed. By "refresh" is meant they will be removed from > auto-mode-alist (if present) and put back again at the top of that > alist. > (iii) Evaluating a mode command does not change auto-mode-alist (except > when it causes an autoload). > (iv) The manipulations of major-mode-remap-defaults by both libraries > will be removed, since they are redundant. > > Any comments? 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 14:39:09 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 19:39:09 +0000 Received: from localhost ([127.0.0.1]:47249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfgL-0008AM-JG for submit@debbugs.gnu.org; Thu, 14 Nov 2024 14:39:09 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfgK-0008A9-6r for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 14:39:08 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BE6DB100180; Thu, 14 Nov 2024 14:39:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731613141; bh=DF1wc8uo3T0VScZRYT4KS87wWubzr4ku6iCGn0VwU3w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EN/im53RzXn4OoNz7V2a6bdZuvFH2ZmsOfpZoYDVRfEDMqN3B/+AAZosPdZnVkLhm c2DzCDijdeLgHw1fxt7qncOoxKHqq3p6/NveXZUQpWrUCDR0gycrhZlFc7W/3VSnJV DfkqS2POg8Cr3+I8t3ItBWkBbCk7sPDIGjHbA59949JBfDZJrlN6FE4jW8Px/HOpe8 T3PCwmLMbL7GJXP6sJus64EUWKKjT4Nfxy7rbeTrYQ9t5Z3LukK+eJqPq1pZk0nq4t YskOngYvjSAdjjvvMwi9jUnQseIB9Ac8TdDnJUdfeTE0++fKwB4mPvtB6Due7Ge2e6 CBMU11YHg071A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2775E100043; Thu, 14 Nov 2024 14:39:01 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0912312062E; Thu, 14 Nov 2024 14:39:01 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <8634jtk4gj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2024 21:20:12 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> Date: Thu, 14 Nov 2024 14:38:59 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.017 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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 ... Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 14:45:31 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 19:45:31 +0000 Received: from localhost ([127.0.0.1]:47264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfmV-00005K-DH for submit@debbugs.gnu.org; Thu, 14 Nov 2024 14:45:31 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4356) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfmT-000052-OO for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 14:45:30 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 500A8444BA1; Thu, 14 Nov 2024 14:45:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731613523; bh=xiPvpT7W8DAA8YvoiyEDRQ3UbNUEW1scLwj7W5ebklk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WAX0jxmEL6eqMDyYS9ChAtUPfR8SPnd91ZcX0H5suNpC4d6Fx+d4GkEHWcMXrqQiy Sz2SFmALJUDc3FLeuE6a5xruKYZVd2o4Fi54JDpTm2++7djzAj1BitVPJUXjllGvpK WFc5hnXgNuaXAykSPdiav1+AyaOnqQRkyPuJvshqDf2Ax3XZWp0OJEFDN8jJPEgPaK AYdKTt78JwO2uYSDFmoQubyFd0WceWFzrb3cCjDB8mCwW59GCtz3Qmh3JHL96Rvuoq byVsyepg677Y3vvcjogX3x1CEIRZVt8cEgsKnDPMu9pSduIavlecira5sGL4MIhsNT N3Be5UdU2LTxA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5E373444BA2; Thu, 14 Nov 2024 14:45:23 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3BDB21206CB; Thu, 14 Nov 2024 14:45:23 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <864j49k4xg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2024 21:10:03 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> <86a5e1kbg5.fsf@gnu.org> <864j49k4xg.fsf@gnu.org> Date: Thu, 14 Nov 2024 14:45:21 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.086 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> AFAIC, "the way for users to express their preference" is by customizing >> `major-mode-remap-alist` > This is not a user-friendly method, IMNSHO. Customizing > major-mode-remap-alist requires too much knowledge of Lisp. How hard > is it to imagine someone who puts wrongly-formatted elements into the > alist, like sub-lists instead of cons cells? We can provide nicer UIs of course. > In another discussion, I proposed to have simpler user option(s) that > would allow users to express this preference, such that, say, > auto-mode-alist would activate this or that mode given such a > variable. As long as it applies to the other ways to specify modes, rather than being specifically for `auto-mode-alist`... Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 14:53:43 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 19:53:43 +0000 Received: from localhost ([127.0.0.1]:47272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfuR-0000PV-AC for submit@debbugs.gnu.org; Thu, 14 Nov 2024 14:53:43 -0500 Received: from mail.muc.de ([193.149.48.3]:15532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBfuO-0000PF-Oe for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 14:53:41 -0500 Received: (qmail 65772 invoked by uid 3782); 14 Nov 2024 20:53:34 +0100 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 20:53:33 +0100 Received: (qmail 25996 invoked by uid 1000); 14 Nov 2024 19:53:33 -0000 Date: Thu, 14 Nov 2024 19:53:33 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <861pzdk4aq.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Thu, Nov 14, 2024 at 21:23:41 +0200, Eli Zaretskii wrote: > > Date: Thu, 14 Nov 2024 17:45:28 +0000 > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > From: Alan Mackenzie > > On Thu, Nov 14, 2024 at 18:59:53 +0200, Eli Zaretskii wrote: > > > > Date: Thu, 14 Nov 2024 16:20:37 +0000 > > > > Cc: 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de > > > > From: Alan Mackenzie > > [ .... ] > > > > 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? > > OK, I can manage that. > > I'll just outline a quick outline of what I see is to be done, so as to > > fix any misunderstandings before starting to hack the code: > > (i) CC Mode and c-ts-mode will both keep their autoload directives. > > (ii) On loading either library, all their auto-mode-alist entries will be > > refreshed. By "refresh" is meant they will be removed from > > auto-mode-alist (if present) and put back again at the top of that > > alist. > > (iii) Evaluating a mode command does not change auto-mode-alist (except > > when it causes an autoload). > > (iv) The manipulations of major-mode-remap-defaults by both libraries > > will be removed, since they are redundant. > > Any comments? > 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. 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. > 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. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 15:21:28 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 20:21:28 +0000 Received: from localhost ([127.0.0.1]:47361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgLI-0001ql-0t for submit@debbugs.gnu.org; Thu, 14 Nov 2024 15:21:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgLF-0001qS-15 for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 15:21:26 -0500 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 1tBgL8-00063U-1K; Thu, 14 Nov 2024 15:21:18 -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=RxJ59VyXC/RMPgntlD8b0d7LsBxsbcxx6cZO1ulQP5I=; b=JKi3tjKSMz40 moUkFFPWOBBpvOd217JHKyJkSQJD3D5/U8TygTmKQFV4iZ6NKRkEp17JToVz/UcWKV+LrW+8kFn8z nqFZBNPPtwy4zthcfOFPCKc5HYG5I5zGDmDdJK5MiPUkQlQdDIa05A86lGeapvnUgQEg/WuVk/Z7X FJAbXv3ODMbYo8Oo2yszXR0GM+JJR1W3DR53bYNpjUhcggz1oQt65D8FTDZxgB1unDZHY47ZJyP9a uo3wGcan9Rc8NUIChSFpPtClnM3YZDs2lQhZSPaIZ/17Sm38LMRP//FS+m2gWrZ53YdggQtfAe0TM OUWrRr2KD34cUT5QdDqibQ==; Date: Thu, 14 Nov 2024 22:21:02 +0200 Message-Id: <86zfm1in2p.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Thu, 14 Nov 2024 19:53:33 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 15:38:50 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 20:38:50 +0000 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 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 Received: (qmail 17529 invoked by uid 3782); 14 Nov 2024 21:38:41 +0100 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 Received: (qmail 26880 invoked by uid 1000); 14 Nov 2024 20:38:40 -0000 Date: Thu, 14 Nov 2024 20:38:40 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode 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 Content-Disposition: inline In-Reply-To: <86zfm1in2p.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 15:39:48 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 20:39:48 +0000 Received: from localhost ([127.0.0.1]:47428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgd2-0002co-5P for submit@debbugs.gnu.org; Thu, 14 Nov 2024 15:39:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgcz-0002cX-Hf for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 15:39:46 -0500 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 1tBgam-0001nQ-FP; Thu, 14 Nov 2024 15:37:28 -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=R+YimbjinxglPzXYkflyPJShDxSkItyMJTyAHBwl28M=; b=Trf98DAvwZ/L Mv+DPfyPYbPtM4xESFkI/DIUlTyISSjoiRzZXLv9BkzynLPoxhMB9pVz3M6playRDQ2tM17E3OFfH Xe99awGG/8+z+fK47aYAFg6eqFix92iKEjquHVtmGYlXAyaG5E5CM0AjKwCdiVy3ZqSE3u1eaVUvG gFuGBH+ndsap/zLUP/EouLvx81VShIbX7BgDLbAFZUM4dSrAmvLT/GETL1cTHELxOmmi7GF1Ty2vx pcKt4+UHlq/01UlsJfsWLmSQgVa+kbDmrjF/vSNKuz3XkPX/pvi8UN5uWdnofgPAIREclDf7wINUV BkxX1ceXG2Xymwhnzgk7/Q==; Date: Thu, 14 Nov 2024 22:37:12 +0200 Message-Id: <86y11limbr.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 14:38:59 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: acm@muc.de, 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 14:38:59 -0500 > > >> 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 ... You assume that people will always want to remap all of those to the same mode? And that no one will ever want to have, say, files with the -*- c -*- cookie to use c-mode and nothing else? Some might, even if the majority won't. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 15:58:59 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 20:59:00 +0000 Received: from localhost ([127.0.0.1]:47458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgvb-0003Vs-Ix for submit@debbugs.gnu.org; Thu, 14 Nov 2024 15:58:59 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBgvZ-0003Vf-Tm for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 15:58:58 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7239F444BC3; Thu, 14 Nov 2024 15:58:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731617930; bh=ykpFybLbIe3qfx6W0na8Rj8nO8vax8EsejjB1XSKBeQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UNRhmrQFevK6k4BH1zC4hh/QpkAGnSMOqh7YFQPic8bPMh4b77b5GnRqBcHtm5MjZ /+/nhR733F/33P1Aoyqyud6Sn0ecIBx641rPNsBIO76n73OTmvStTTpjRBUQ84IfRz mEGCQSsfAwyvScNttJOGdGA3RA6O5KDXQtaVkoechOZKXx7c9/l514tQbOGOnWwKYP iolbyWO3JrzBEgJq1uCcRaWZyWXwV7nJE+R0kc/S/rmDL6Gyi0VDnEwcmv1xfDcQWU RZ7Ch/Y5rqTJVMAoIkwzqi1B+d52TjSCj3NI+Jr3Buv3DgHp3HCeanSp44l2bHCxYG VBBV1b24QbxPQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7065D444BBE; Thu, 14 Nov 2024 15:58:50 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4D5DA120494; Thu, 14 Nov 2024 15:58:50 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86y11limbr.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2024 22:37:12 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> <86y11limbr.fsf@gnu.org> Date: Thu, 14 Nov 2024 15:58:49 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.082 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> >> 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 ... > > You assume that people will always want to remap all of those to the > same mode? Not always but in the vast majority of cases, yes. > And that no one will ever want to have, say, files with the -*- c -*- > cookie to use c-mode and nothing else? Some might, even if the > majority won't. Those few who want that can still get it: just config `major-mode-remap-alist` to remap `c-mode` to `c-mode` (or to nil), and then things work as if `major-mode-remap-*` didn't exist: `-*- c -*-` will mean to use CC-mode's `c-mode` and `-*- c-ts -*-` will use `c-ts-mode`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 16:06:10 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 21:06:10 +0000 Received: from localhost ([127.0.0.1]:47484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBh2X-0003v3-OQ for submit@debbugs.gnu.org; Thu, 14 Nov 2024 16:06:10 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBh2W-0003ul-FH for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 16:06:08 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7D37A805DE; Thu, 14 Nov 2024 16:06:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731618361; bh=ygl9b3rQxh34nJkAEHX+vzhSJgx6HbtmRwi/XbAPpFc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XMvastWkfTqcI726o+VyfHvo94eQFqZTRIbBT9KPZbYKsyUDugNCsEnVDxxZKlvjs BTZdzkgY3X4MSk/L9wqex9EA2+IDh96nuNuFLjUUpJW7v0pXFT017rrcPX17oQUvOx yDIuRSIGjV3bp3KTGy0xdQfakIK15r7bStV2WgG1qw9ansSZY4jdq1C5IU3+Mvcokj 1pwIo+Boz/U/QCMFtmT5FjNbTxcICFeBEnTZFOlLCheWRjoxZxL55hhl5ppg02ORNK I4DJE1uZbaGbjHZiMJsgkOsnXC1ehuBqtHlE1RX2gZwD2ygZtIbiRgICPFiiTj8D4X D0dn7PTuoHRiQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A86948001E; Thu, 14 Nov 2024 16:06:01 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 89ED11203DA; Thu, 14 Nov 2024 16:06:01 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "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> Date: Thu, 14 Nov 2024 16:06:01 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.062 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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. For `major-mode-remap-defaults`, mapping `c-mode` to `c-mode` behaves the same as when there is simply no entry mapping `c-mode` to anything, which is why the code I suggested (which just removes any previous remapping of `c-mode`) should give the same result as what you describe. > 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? They'd be symmetric in the sense that the mode used by default is the one that was last loaded (with a "default default" of `c-mode`). The apparent asymmetry is compensated by the fact that the entries in `auto-mode-alist` always say `c-mode` and never `c-ts-mode`, so there's never a need to remap `c-ts-mode` to `c-mode`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 16:26:59 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 21:26:59 +0000 Received: from localhost ([127.0.0.1]:47517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBhMg-0004rN-Ju for submit@debbugs.gnu.org; Thu, 14 Nov 2024 16:26:59 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBhMW-0004r1-Mp for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 16:26:54 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BE6F4444BD6; Thu, 14 Nov 2024 16:26:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731619596; bh=0fBIlZ1GQDZXHF3azLQua4fkHFbN09AT9ZExG/MnQ0k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pxuSvCs5caYCJ2AbxDqIgT1UYIRaK1xTFM60CWfG49nEthH55EFsMxJBguXnwzB+B 97Z5lwfddhy2WboQ8DLGha8trwR1P1/0WvUm5VnkVAJoyJpGFrnPCCS04Gxe8azht9 nXdbxIhMFG3XlmuFncc9GB8kdCNL7lIM85go+1n+lMWBmXP9EaWB/g0akV8HbhSd3u tZSWZjbcQO1Yx0XdQkYfG2csqpq+AU/jJKMtmycRuR3lrVy+VO7pBq90hNr6Q+RCkI cSn5tu4EUth1eixSkmRnVh/eqa3X6zMkx/Houc5eLCQ9xy5LvS5gBlR2KPD9lrM1/A rBbAYfqw4huFQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E62B3444BD1; Thu, 14 Nov 2024 16:26:36 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C3C1C1201CF; Thu, 14 Nov 2024 16:26:36 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Stefan Monnier's message of "Thu, 14 Nov 2024 16:06:01 -0500") Message-ID: References: <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> Date: Thu, 14 Nov 2024 16:26:35 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.078 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) For reference, here's the patch I'm suggesting. Stefan diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el index 8ce4da56ef7..2e985ef9a83 100644 --- a/lisp/progmodes/cc-mode.el +++ b/lisp/progmodes/cc-mode.el @@ -3331,16 +3331,11 @@ c-submit-bug-report ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's ;; modes rather than c-ts-mode etc.. (when (boundp 'major-mode-remap-defaults) - (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) - (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) - (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) (let (entry) (dolist (mode '(c-mode c++-mode c-or-c++-mode)) - (if (and (setq entry (assq mode major-mode-remap-defaults)) - (null (cdr entry))) - (setq major-mode-remap-defaults - (delq entry major-mode-remap-defaults))) - (push (cons mode nil) major-mode-remap-defaults)))) + (while (setq entry (assq mode major-mode-remap-defaults)) + (setq major-mode-remap-defaults + (delq entry major-mode-remap-defaults)))))) (cc-provide 'cc-mode) From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 17:06:24 2024 Received: (at 74339) by debbugs.gnu.org; 14 Nov 2024 22:06:24 +0000 Received: from localhost ([127.0.0.1]:47597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBhyp-0006kv-MB for submit@debbugs.gnu.org; Thu, 14 Nov 2024 17:06:23 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBhyo-0006kf-70 for 74339@debbugs.gnu.org; Thu, 14 Nov 2024 17:06:22 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 231BE100180; Thu, 14 Nov 2024 17:06:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731621974; bh=uJ6ruzPbTPmqgw3Vnu91w4dtQfPACEPAy7XukvTTJ2E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pmHPRuOiDHXD91FdSjgkQzGI+EtFcvGKIBnyAzTU7A8wbufV3m0mtoKpvO8YlBjr0 RfB5VSJHIs/Gq8GHXHQjHMN4Euo0sYIxYdpkSYveFZBVLmfJEq9GXvRrMYFtRsCnvP DAdvRQxNLzYeCO79Q8zcH7shOCO2HxczEMgO536WDlO093PyRZv9s0xBa+nHTlOg4z lsVmKk4TziS/EwB9Mtc8aUY3Avwzfaj13FFOXiZfki9m28Jy4lf38DjyejAE3+NiFO /gTi2W+Zyq7XApV9DWmVHcV6MS77XgTTuj4FO89Evw2RXddJpmI6p+3Ivq0RLkiO0y nK36TBc3qdNKA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2DE14100043; Thu, 14 Nov 2024 17:06:14 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0B942120370; Thu, 14 Nov 2024 17:06:14 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Stefan Monnier's message of "Thu, 14 Nov 2024 15:58:49 -0500") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> <86y11limbr.fsf@gnu.org> Date: Thu, 14 Nov 2024 17:06:13 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.016 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) BTW, we should also install a patch like the one below. Any objection? Stefan diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index 3823c553fda..8d6e05f8008 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -33,31 +33,15 @@ ;; C/C++ header files. ;; ;; To use these modes by default, assuming you have the respective -;; tree-sitter grammars available, do one of the following: -;; -;; - If you have both C and C++ grammars installed, add -;; -;; (require 'c-ts-mode) -;; -;; to your init file. -;; -;; - Add one or mode of the following to your init file: +;; tree-sitter grammars available, +;; add one or more of the following to your init file: ;; ;; (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode)) ;; (add-to-list 'major-mode-remap-alist '(c++-mode . c++-ts-mode)) ;; (add-to-list 'major-mode-remap-alist '(c-or-c++-mode . c-or-c++-ts-mode)) ;; -;; If you have only C grammar available, use only the first one; if -;; you have only the C++ grammar, use only the second one. -;; -;; - Customize 'auto-mode-alist' to turn one or more of the modes -;; automatically. For example: -;; -;; (add-to-list 'auto-mode-alist -;; '("\\(\\.ii\\|\\.\\(CC?\\|HH?\\)\\|\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\|\\.\\(cc\\|hh\\)\\)\\'" -;; . c++-ts-mode)) -;; -;; will turn on the c++-ts-mode for C++ source files. +;; If you have only C grammar available, use only the first one; if +;; you have only the C++ grammar, use only the second one. ;; ;; You can also turn on these modes manually in a buffer. Doing so ;; will set up Emacs to use the C/C++ modes defined here for other From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 02:36:07 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 07:36:07 +0000 Received: from localhost ([127.0.0.1]:48366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBqsB-0006UF-Bl for submit@debbugs.gnu.org; Fri, 15 Nov 2024 02:36:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBqs8-0006Tg-Fn for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 02:36:06 -0500 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 1tBqpu-0007td-E9; Fri, 15 Nov 2024 02:33:47 -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=Y/enR24DDXteTUfsKWd+9OT6/UOSXogJxutOxji17Tw=; b=OXnjbKKvscTX enHzZp6C0CAP2KgJYwr6iwuAvjDu3UzIiujT81hVrLhNOOPMBtgH8Eo3dBheI3K8/vQ/LRl2LeidA /rMiYvaS2WHRUNTBgHpTMtQ62AX8O6VJoE5Z6JPwNubFqoXyvrFxt9Km9lhWGwzg6PwiYF2x3PLAt 9R6vpZxc+ha0EaXWPQXKY3uvLiNmWGoG/lb11viHJ1DVMvpAn3/EQ7m5osNtqMtditCuNqjnvl57d N4qycbP3fZxzpNtKyvr+cC4r37CDJSkN5wmJ4D9VUskax0DEv4edU1h+bgUsG26afjT6BKcIFm5IU d6bjQ0P8Yd6qTEJhewinlA==; Date: Fri, 15 Nov 2024 09:33:17 +0200 Message-Id: <86wmh5hrya.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Thu, 14 Nov 2024 20:38:40 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. This is the issue at hand: to allow users to express their preferences about c-mode in a way that is reversible. 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. 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. 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. 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.) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 02:59:05 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 07:59:05 +0000 Received: from localhost ([127.0.0.1]:48423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBrEO-0007Qs-MT for submit@debbugs.gnu.org; Fri, 15 Nov 2024 02:59:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBrEM-0007QP-RZ for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 02:59:03 -0500 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 1tBrEF-0004zb-Vd; Fri, 15 Nov 2024 02:58:55 -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=1jxt4bIkh1o0qFQPzbsDHk7UvLacW4vRJFM3mturUL4=; b=Tei3eUKm09r7 zqy6Mon2zIXKYva4xItxXiAV/oUj+sKnONOr1qsft1NdUyXzvvkSaN2u5molWHeL6sUkRZiB6kDoy 2GWRa2iTBIYbgnxqOCxEkL+wUXsVYvej4Ui2z8o7Kqp489s+/r+e9cmNLLdUUQa0+OLz+vwO3Fw+a jQspmpzgzEsvMV5jMQhxsWw0Cu9wE2OFfUGAvbtRzMIw48XXbcWrO0H8Nn2393Uq88narWAcFhfSK FmY3fccUPVrOBKGbUYhADqMkp2l0VVNIWsef3U0SPEuQY07yuNWM48VjTGi0Jme25EtO58z6Wzg96 W+048WayrIlRQ1QO8BQt8Q==; Date: Fri, 15 Nov 2024 09:58:52 +0200 Message-Id: <86serthqrn.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 15:58:49 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> <86y11limbr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: acm@muc.de, 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 15:58:49 -0500 > > >> >> 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 ... > > > > You assume that people will always want to remap all of those to the > > same mode? > > Not always but in the vast majority of cases, yes. > > > And that no one will ever want to have, say, files with the -*- c -*- > > cookie to use c-mode and nothing else? Some might, even if the > > majority won't. > > Those few who want that can still get it: just config > `major-mode-remap-alist` to remap `c-mode` to `c-mode` (or to nil), and > then things work as if `major-mode-remap-*` didn't exist: `-*- c -*-` > will mean to use CC-mode's `c-mode` and `-*- c-ts -*-` will use > `c-ts-mode`. This will cause Emacs to visit C files without the cookie in c-mode. What I meant was an (admittedly somewhat strange) preference to visit C files without a cookie in c-ts-mode, but files that have a cookie in the mode called out by the cookie. AFAIU, major-mode-remap-* variables cannot handle this distinction, at least not currently. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 03:13:53 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 08:13:54 +0000 Received: from localhost ([127.0.0.1]:48451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBrSj-00084u-I6 for submit@debbugs.gnu.org; Fri, 15 Nov 2024 03:13:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBrSh-00084g-5n for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 03:13:51 -0500 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 1tBrSb-0007SK-1v; Fri, 15 Nov 2024 03:13:45 -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=TSxDhW8Oi8rHxQx+PjUy9Tj4gUZR7qwe84PghLCH6Go=; b=Wxx9ytAGSBon lQRAivlt4VmE8v4BoJKjQzakaYWubXHLlIDCQFdgZ4ksR2lHxs2WMBMBnH+PEvtXE6WD3td1UbiZG lX4vw66Du7FUpI/LN/i/n/cPgiRw13/smr23LSjNofotz8f8X7UbfvUzxLQqT7YwFEwZGX4Xc/oSp JmhZ4txJcqfvkCXx9HSHo+5xuWuKVbHCjLSIlo2+BbNYrL/kwTBVWJD5V1wxRZHGcu5UKw9kHlp7/ jYnSyBbQD7unNNHa/VwzGzdIE++DbEZTcy3ST3cT66N5Jgd3ID+ljoFKcdSOwZIdlQTuSdaS8tvB0 V3o6UQypgZmI6XrTxo1Jkw==; Date: Fri, 15 Nov 2024 10:13:25 +0200 Message-Id: <86plmwj4nu.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 16:06:01 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 16:06:01 -0500 > > >> 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. > > For `major-mode-remap-defaults`, mapping `c-mode` to `c-mode` behaves > the same as when there is simply no entry mapping `c-mode` to anything, > which is why the code I suggested (which just removes any previous > remapping of `c-mode`) should give the same result as what you describe. That's true, but only if the other elements whose car is c-mode were first removed with 110% reliability. If we want to be absolutely sure that c-mode spec invokes c-mode and nothing else, adding '(c-mode) is more reliable. > The apparent asymmetry is compensated by the fact that the entries in > `auto-mode-alist` always say `c-mode` and never `c-ts-mode`, so there's > never a need to remap `c-ts-mode` to `c-mode`. Right. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 03:17:46 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 08:17:46 +0000 Received: from localhost ([127.0.0.1]:48460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBrWU-0008H7-7X for submit@debbugs.gnu.org; Fri, 15 Nov 2024 03:17:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBrWR-0008Gr-9D for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 03:17:44 -0500 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 1tBrWK-0000IO-HW; Fri, 15 Nov 2024 03:17:37 -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=uzy/Bs3GBPpZ6CPFyAZ7s2py2oEJn757PKLEumaKFb4=; b=prERGNGGIKrN UruveBaUJQ84ukDtuDXpxLmIeDrVJpzCw5gftnl7ur6LE9OXUcN739ep87xpzS+gQERxITLekGu9u 742SMuU2soH+XfhBENMuoyYrGIjUAfOsplLPRDMTTfMPC4WBXTP0rszjR6n4zqxmaj+gdC7MT7uQe pTdJEviFhDTpTINoJ34oh5UZZzLGCF5w0I9vd1/VDrr0dbfRNZfR3xMN4LoiQSwvaPEJBwiuKLj2I IyrXvYMjGtYo5zwQfETvZrJPyi631WovQQpqRB69mVVS+0mDEL8KPyIpvLxjmdFLjN31SOgNCx9nV mmGh+A4MbDSL++qBOFy7Bg==; Date: Fri, 15 Nov 2024 10:17:32 +0200 Message-Id: <86o72gj4gz.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 16:26:35 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 16:26:35 -0500 > > For reference, here's the patch I'm suggesting. > > > Stefan > > > diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el > index 8ce4da56ef7..2e985ef9a83 100644 > --- a/lisp/progmodes/cc-mode.el > +++ b/lisp/progmodes/cc-mode.el > @@ -3331,16 +3331,11 @@ c-submit-bug-report > ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's > ;; modes rather than c-ts-mode etc.. > (when (boundp 'major-mode-remap-defaults) > - (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) > - (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) > - (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) > (let (entry) > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > - (if (and (setq entry (assq mode major-mode-remap-defaults)) > - (null (cdr entry))) > - (setq major-mode-remap-defaults > - (delq entry major-mode-remap-defaults))) > - (push (cons mode nil) major-mode-remap-defaults)))) > + (while (setq entry (assq mode major-mode-remap-defaults)) > + (setq major-mode-remap-defaults > + (delq entry major-mode-remap-defaults)))))) Thanks, but wouldn't it be better to use assq-delete-all? Your proposed code deletes only the first entry found in the alist. But what if the alist has both '(c-mode . c-ts-mode) and '(c-mode) ? Then the second one will not be removed from the alist, AFAIU. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 07:03:15 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 12:03:15 +0000 Received: from localhost ([127.0.0.1]:48861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBv2h-0001EN-4b for submit@debbugs.gnu.org; Fri, 15 Nov 2024 07:03:15 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBv2e-0001EA-83 for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 07:03:13 -0500 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 1tBv2Y-0006Mf-Cv; Fri, 15 Nov 2024 07:03:06 -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=Bjzp1Y/CmPk3OXV7SwJorvO0fvRB2nrptljotd4NyPA=; b=DE1mYeyHfAdm WZbFzWxoarUqbjEawpDPYpto0LW+q1Qjn2b1QzrZHKvxPtEKfDJ9sLnsLMmnMxuOAkayz0elrLV1U 94nK2frdbqYxJYsIgpALrxlFi+xY5hwByNN17Kws+TPnUYSAZm8Ql8lZ7Vg0yJ32FKwZ0OesYyfci DDblsYxrl+6OXPmXypfJYg6PS3zHNzoq45sLM1Cdj7879lPy2cXk2u1y1rSluY0RFiCJ+w0WIRKxK +LFqMjt6hHf6MZu3s8uItVMD0wiDsLSBx1/JIoW6h/yEccsbxDoySkXSw7+RUtmZOHkzehw4zKGnt kDY+Zk1rOXSkZaGnKnt8sg==; Date: Fri, 15 Nov 2024 14:02:57 +0200 Message-Id: <86msi0iu1a.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 17:06:13 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> <86y11limbr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: acm@muc.de, 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 17:06:13 -0500 > > BTW, we should also install a patch like the one below. > Any objection? I don't think we should install this, no, definitely not on the emacs-30 branch. It was never my intention that Emacs 30 will affect the advice in those comments. We could (and probably should) consider some kind of changes for Emacs 31. But since we don't yet have a clear idea of how we want this to be resolved from the users' POV, it is too early to consider changes to this text even on master. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 08:04:37 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 13:04:37 +0000 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 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 Received: (qmail 5887 invoked by uid 3782); 15 Nov 2024 14:04:26 +0100 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 Received: (qmail 9693 invoked by uid 1000); 15 Nov 2024 13:04:25 -0000 Date: Fri, 15 Nov 2024 13:04:25 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode 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 Content-Disposition: inline In-Reply-To: <86wmh5hrya.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 09:43:43 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 14:43:43 +0000 Received: from localhost ([127.0.0.1]:49115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBxXy-00089y-KA for submit@debbugs.gnu.org; Fri, 15 Nov 2024 09:43:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBxXw-00089i-1V for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 09:43:41 -0500 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 1tBxXp-0004E0-Eb; Fri, 15 Nov 2024 09:43:33 -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=m4e6ajHmg8P3b3bQWvI1d5VmAzpTouicZKksIYV93t8=; b=fGgAMbCmUMvg GONA+h2Jb/WDhV7b9P3JMJo0QCHdS+9MT5XAbruGDapeEdRfL+KulgPzMitpPbxHtumgUvBNmEUwW i3GNq7UiYLtAQ7lW39pT4O1ITaEArGcA0JxADimE5VfOh6DGgjIuXBrDkyV+UsbaIELWbgzKmUYO3 XE1JOC24ezB0vmTByylMZ3D3bLv7p0X4VlNaQDjuGeOB4N/D8O+F+O28XGp00a/Ceng8YFi3xnody gyWiXoQ0XIHo10eeBY7u9A2/cANu2xEhWBikcRg7A4kMDONmQ3Gn1JGk4hU9yI/FdnHV+J2m6p73/ RosoQz81gTgBfRiYGWE/ZQ==; Date: Fri, 15 Nov 2024 16:43:28 +0200 Message-Id: <86cyiwimlr.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 15 Nov 2024 13:04:25 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. > > 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. > 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. 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 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? 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.) > 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. > 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. > > 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 : > >> 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. 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. > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 11:12:56 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 16:12:56 +0000 Received: from localhost ([127.0.0.1]:50622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBywJ-00042N-Qt for submit@debbugs.gnu.org; Fri, 15 Nov 2024 11:12:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBywI-000428-Kh for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 11:12:54 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 42753444CD8; Fri, 15 Nov 2024 11:12:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731687167; bh=VPFswOZIGoJb2CWs9aHQMgOQzLSfMRuxTiqfSpOIN6o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R5M/PTRJ5zZUCcwY6Y6gZMf0N9KABDZN7zUWHnhs4cSif5Fa/Z1OXmdU8WhFDt9kL mO1hKkUSZ5B3xGoF/I8oarJanakn3yFN/MDYAauxk2P4M/AOQCT5yO3NZCxaEPgChg xI8Nqut3CBgI10uXeV6MFKWqIw1SgPpYtjMmlODTbW89ZdIR0fhn2AiafTG0zybCdF N3UeSby5rRxDPLWIuPXPBSojK0OEwZcm0jnWnZ7qm2eb4a7pNQ8a5emWNVtf5v7LUP lA6FEm7u3ClSeaSKcdJD6JYkTSIbkcCjGMS7WgRcUu4yurzt8BC5Gt8stL8jWqfOJu R2NQf8X0EeI8A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5FF34444CD4; Fri, 15 Nov 2024 11:12:47 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3ED8A1202EF; Fri, 15 Nov 2024 11:12:47 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86serthqrn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Nov 2024 09:58:52 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <8634jtk4gj.fsf@gnu.org> <86y11limbr.fsf@gnu.org> <86serthqrn.fsf@gnu.org> Date: Fri, 15 Nov 2024 11:12:46 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.075 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > This will cause Emacs to visit C files without the cookie in c-mode. > What I meant was an (admittedly somewhat strange) preference to visit > C files without a cookie in c-ts-mode, but files that have a cookie in > the mode called out by the cookie. AFAIU, major-mode-remap-* > variables cannot handle this distinction, at least not currently. No, indeed, they don't help with that. They don't prevent it either, tho: Users can still get that kind of behavior with the "old methods" such as by changing `auto-mode-alist` to map `.c` files to `c-ts-mode`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 11:18:00 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 16:18:00 +0000 Received: from localhost ([127.0.0.1]:50635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBz1D-0004GF-QA for submit@debbugs.gnu.org; Fri, 15 Nov 2024 11:18:00 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBz1B-0004Fz-GL for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 11:17:57 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25E9C100055; Fri, 15 Nov 2024 11:17:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731687470; bh=Ig8rZ18UxeoJ9EaVdSVPxoRRFYDN7jq+UoeoRXnMe2s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Rq/bzRrSdM2e6kjBorgpiYVgTJWDl8x+5Lm9zhdVSuaD7MHdnMV64wLlwsEh5U5Pc gZT01l1/OJNSty5fxLVI3TIvpOm+HhM4YMuejtB2TXabDQhM2966ODMXjA+oVA5Cx5 ulBleOOid9Q4Bb7+99xvQ0pZymV8wMFzzapeMinHBIopMd5NS60SM8cGofcnYCReCm gYnOlddDvYjLCI+WfwzdfJOcArhD7E7YGozuJBZqzigHNsnNcb9hr2NR1HLj49Idx7 ls5UQxu6LpazqTtAbEDjAvqHi+CECxAlV3/VC6B7UzDNKZFEKYR784oIFkb/xV/9er AMAzHEp6WE23A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CFCD11001DE; Fri, 15 Nov 2024 11:17:50 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AB2621202BB; Fri, 15 Nov 2024 11:17:50 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86o72gj4gz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Nov 2024 10:17:32 +0200") Message-ID: References: <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86o72gj4gz.fsf@gnu.org> Date: Fri, 15 Nov 2024 11:17:49 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.015 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el >> index 8ce4da56ef7..2e985ef9a83 100644 >> --- a/lisp/progmodes/cc-mode.el >> +++ b/lisp/progmodes/cc-mode.el >> @@ -3331,16 +3331,11 @@ c-submit-bug-report >> ;; Mode has been loaded, the symbols `c-mode' etc., will call CC Mode's >> ;; modes rather than c-ts-mode etc.. >> (when (boundp 'major-mode-remap-defaults) >> - (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) >> - (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) >> - (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts= -mode)) >> (let (entry) >> (dolist (mode '(c-mode c++-mode c-or-c++-mode)) >> - (if (and (setq entry (assq mode major-mode-remap-defaults)) >> - (null (cdr entry))) >> - (setq major-mode-remap-defaults >> - (delq entry major-mode-remap-defaults))) >> - (push (cons mode nil) major-mode-remap-defaults)))) >> + (while (setq entry (assq mode major-mode-remap-defaults)) >> + (setq major-mode-remap-defaults >> + (delq entry major-mode-remap-defaults)))))) > > Thanks, but wouldn't it be better to use assq-delete-all? Oh, indeed, I forgot about that one; that makes it even simpler, thanks. > Your proposed code deletes only the first entry found in the alist. I don't think so: the code uses a `while` to remove them all. [ The code I had sent a few days ago did suffer from the problem you describe, tho, so I assume you just presumed it was the same code. =F0= =9F=99=82] Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 12:58:46 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 17:58:46 +0000 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 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 Received: (qmail 4137 invoked by uid 3782); 15 Nov 2024 18:58:36 +0100 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 Received: (qmail 17771 invoked by uid 1000); 15 Nov 2024 17:58:35 -0000 Date: Fri, 15 Nov 2024 17:58:35 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode 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 Content-Disposition: inline In-Reply-To: <86cyiwimlr.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 13:57:24 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 18:57:25 +0000 Received: from localhost ([127.0.0.1]:50857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC1VU-0002iO-I1 for submit@debbugs.gnu.org; Fri, 15 Nov 2024 13:57:24 -0500 Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:48177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC1VS-0002iB-K1 for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 13:57:23 -0500 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 54DC51380258; Fri, 15 Nov 2024 13:57:16 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Fri, 15 Nov 2024 13:57:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1731697036; x=1731783436; bh=WXQ1ouQMrB+/v2oN6myQOV/vJoWc49yZNZXWwj3uyi4=; b= KuPV0ev1P/aThXFsrRxd0OwSnvuEML5mi8upeQ65xoJ6h6uquWOsyoegszf6rIiI TGShxIIP8lWpsSpnoQRwUITCYYrjDC5rZ/7D4VHOSi+DRh0uQSHev7ykH4Byx+dj RaJyOBSM8zty8jnFb74wm2GkoecdReGc2G9LnLeLkWF/RsBB0i5rnCdDsP/d8f0G 9VkGRoxyNwsiKmZsVSmAxRc5vkiy/ARMh9har8mj1kZ9qYbde6R5aP9yNlABeTpV yw/kWreYpJos/EVlCPXcjn2QS0/Y/hbmtCne2VPpD6KlKCKofqjhpK8ckcmtLl0m 3f2dLP8VlyPmlEBlSqifTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1731697036; x= 1731783436; bh=WXQ1ouQMrB+/v2oN6myQOV/vJoWc49yZNZXWwj3uyi4=; b=f TEOQlgFLNnqV/0dqSxKd2qkcCto1wThHkhC1wmXuz5Py5GintjO0Kt23NLf3RUJN O5a2tzOOJC0O3612BUbxOrJY+rir5KDOeq0cS/NC2tk5fIrF+jkE08Gw2AenNXds 0dds1XCymIsVT5r4Shh+dwy2jJvDi8fuJ9VJJVFIKmE1/CSjbQVMHw8LdFhx8XLZ 9HCHVvQ+Lk1LvFnWnCpMDEkjyLjuc8qk/H+jTm46+XfkpsUSNOC/Wo4WAuWFXj01 X3MIMGu3Oqwku8tJJO4iTvGk1VFSpYdhQwiSaVy9mfD85HTPgxJ/Q0olj2oFmVIG 2g1vF/bd4fbAz3hCqzeSw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrvdeggdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrtghmsehmuhgtrdguvgdprh gtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehmohhnnhhivghrsehi rhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopeejgeeffeelseguvggssghugh hsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Nov 2024 13:57:14 -0500 (EST) Message-ID: Date: Fri, 15 Nov 2024 20:57:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Alan Mackenzie , Eli Zaretskii References: <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Alan, On 15/11/2024 15:04, Alan Mackenzie wrote: >> 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? Allow me to butt in this subthread a little. Your other points aside - several of them definitely valid - there already is an inherent asymmetry between c/c++ ts modes and cc-mode in that we give deference to the latter in our default file->mode mappings, which I wouldn't expect to change in any short or medium term. So if we give a little back to ts modes on another level (and assuming user opt-in), that seems fair enough. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 14:01:43 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 19:01:43 +0000 Received: from localhost ([127.0.0.1]:50868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC1Zf-0002w4-7W for submit@debbugs.gnu.org; Fri, 15 Nov 2024 14:01:43 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC1Zd-0002vr-HO for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 14:01:41 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 72F2D100126; Fri, 15 Nov 2024 14:01:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731697294; bh=DMaPqLAxiSjbYquYCrEcBdlsqXrCOJJO2Xd4Ox2ZsBQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WEUZaBWPcZVptvPOU5KlXzXavo1etGzMKR2My8AeTERVpXEYE9zIdrsBTengN+yDa VnzTP4snTiyhXtoBzjiucYpktXHa46hp8CF7H1cX4uGtRRqnUMlV5eFvYxJS1YlCyi amtAKTh+JXvJjhEkxv5ACTNyJuxEst2/xpMEZm3iiC3TfngpgvWtco887AqKNjqATs YT6W1ZLGPgFMAmIdjpvJJvtvlr+9bE5QXTH3kTTjd0LxLgan5gZ8BVLE+466doGN94 LZFeZy9KddSZrH/80z04/qQsxPm4ZCcPKopT3FRSRoWOcpIlWc9Y5BdEUiXudpTt1f 9+XTBXJSlPJoQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AB984100055; Fri, 15 Nov 2024 14:01:34 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7FEBE1201DA; Fri, 15 Nov 2024 14:01:34 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "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> Date: Fri, 15 Nov 2024 14:01:26 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.029 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > One can write, in the Local Variables: section > > mode: c-ts FWIW, unless this file is personal, this is very bad practice, and not only because `c-ts-mode` may not be available (in older Emacsen or if the user didn't build Emacs with tree-sitter support or doesn't have the appropriate grammar installed): the choice between `c-mode` and `c-ts-mode` is a personal preference, so it's not the file's business to tell the user which mode to use, just like it's not the file's business to tell the user which editor to use. There might be special situations where such a setting might be warranted, but they're sufficiently hypothetical or rare that they should not drive our decisions, as long as the users can still get the behavior they want in such cases (which they can, regardless of what we do with `major-mode-remap-defaults`). > .. This will cause the buffer to start in c-ts-mode regardless of any > other current settings. Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some other mode, such as `c-mode`. > .. 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. If you really insist, we can add (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode)) (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode)) to your `cc-mode.el` together with corresponding removals in `c-ts-mode.el`, even though in my book file-local settings of `mode: c-ts-mode` in non-personal files are just bugs. > ... there will be no way for a user to specify c-mode unambiguously ... Where/when? AFAICT the only case where this might be true are the cases where it does not do any damage. > 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. It is supposed to opt-in, indeed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 14:46:12 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 19:46:13 +0000 Received: from localhost ([127.0.0.1]:50932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC2Gi-0004qY-FL for submit@debbugs.gnu.org; Fri, 15 Nov 2024 14:46:12 -0500 Received: from mail.muc.de ([193.149.48.3]:42874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC2Gg-0004qL-HL for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 14:46:11 -0500 Received: (qmail 57842 invoked by uid 3782); 15 Nov 2024 20:46:04 +0100 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 20:46:03 +0100 Received: (qmail 19401 invoked by uid 1000); 15 Nov 2024 19:46:03 -0000 Date: Fri, 15 Nov 2024 19:46:03 +0000 To: Stefan Monnier Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <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 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Fri, Nov 15, 2024 at 14:01:26 -0500, Stefan Monnier wrote: > > One can write, in the Local Variables: section > > mode: c-ts > FWIW, unless this file is personal, this is very bad practice, and not > only because `c-ts-mode` may not be available (in older Emacsen or if > the user didn't build Emacs with tree-sitter support or doesn't have the > appropriate grammar installed): the choice between `c-mode` and > `c-ts-mode` is a personal preference, so it's not the file's business to > tell the user which mode to use, just like it's not the file's business > to tell the user which editor to use. > There might be special situations where such a setting might be > warranted, but they're sufficiently hypothetical or rare that they > should not drive our decisions, as long as the users can still get the > behavior they want in such cases (which they can, regardless of what we > do with `major-mode-remap-defaults`). Here is a section of a test file sent to bug-cc-mode some while ago: /* ** Local Variables: ** mode:c ** indent-tabs-mode:nil ** c-basic-offset:4 ** End: */ Here it is evident that by "mode:c" the OP means C Mode, not whatever random mode happens to have taken the symbol `c-mode'. > > .. This will cause the buffer to start in c-ts-mode regardless of any > > other current settings. > Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some > other mode, such as `c-mode`. Maybe I should have said "regardless of any non-crazy settings". > > .. 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. > If you really insist, we can add > (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode)) > (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode)) > to your `cc-mode.el` together with corresponding removals in > `c-ts-mode.el`, even though in my book file-local settings of > `mode: c-ts-mode` in non-personal files are just bugs. The problem is that entries in major-mode-remap-defaults (and the other one) do not accurately represent user preferences. As a value for mode: in C files, we need three distinct settings: for C Mode, for c-ts-mode, and for any mode which handles C. Currently we've only got two: c-mode and c-ts-mode. This can't work properly. > > ... there will be no way for a user to specify c-mode unambiguously ... > Where/when? AFAICT the only case where this might be true are the cases > where it does not do any damage. In an auto-mode-alist entry, for example. As already discussed, in a Local Variables: section, for another example. > > 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. > It is supposed to opt-in, indeed. So, for a user trying out Emacs 30, with a desktop file containing at least one file with major mode c-ts-mode; visiting a file with the above Local Variables section will indeed start the buffer with C Mode? I haven't looked just yet, but can I assume there's a recipe in the Emacs 30 NEWS file telling users how to switch between old behaviour (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean c-ts-mode depending on other settings)? Is the default to keep the old behaviour, as is customary with new features in Emacs? > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 15:45:57 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 20:45:57 +0000 Received: from localhost ([127.0.0.1]:51019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC3CW-0007Uo-SO for submit@debbugs.gnu.org; Fri, 15 Nov 2024 15:45:57 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC3CU-0007UY-Cp for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 15:45:54 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B276B444D13; Fri, 15 Nov 2024 15:45:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731703547; bh=C5xkR00sok1YQm/5JAZdSRg01yC6EbKdDrjm1XCXhRw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=i7gyLzWRcx4lnSHcHIFEqReC0xcJT67lv+zR2cqT9ed1Dzn2Uoc+bw/3xhBIrfcZy q1RRSNcVpR8Od3w/Tu12VLh5iVljGRNTJ+Cso27UCtsul2mbUPdNFV9d3iWJK1gjZI bGEtJM9aS2NMwfrxIn3HMbp7+DfarpvvhTHOZ2gLvJKBStXjXll/ooehvfZRUSbyDP fgA1WtV8cp7E6FNrBbH8EXlYqiQ0Gmd+WGQ8i+7H4T2y/alBCgqva9FbiArDN+lvDk ILa05z+MktANrjMQithYjhCHdzzj2q+R5Fa1p535HPMNlBkUyGCj/Zy1j0rDhhQAZS gCoeT3fYp79+w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6E9D2444D0F; Fri, 15 Nov 2024 15:45:47 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 43C261204A3; Fri, 15 Nov 2024 15:45:47 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "Fri, 15 Nov 2024 19:46:03 +0000") Message-ID: References: <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> Date: Fri, 15 Nov 2024 15:45:46 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.021 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Here is a section of a test file sent to bug-cc-mode some while ago: > > /* > ** Local Variables: > ** mode:c > ** indent-tabs-mode:nil > ** c-basic-offset:4 > ** End: > */ > > Here it is evident that by "mode:c" the OP means C Mode, not whatever > random mode happens to have taken the symbol `c-mode'. It is evident that the OP means CC-mode's C Mode because the bug report is sent to `bug-cc-mode`, indeed. But that doesn't mean these file-local settings intend to impose the use of CC-mode to those users who prefer `c-ts-mode`. >> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some >> other mode, such as `c-mode`. > Maybe I should have said "regardless of any non-crazy settings". If something is "crazy" here it would be using a `mode: c-ts` cookie. Adding such entries to `major-mode-remap-*` would just be the sane way to work around that "crazy" part. =F0=9F=99=82 >> If you really insist, we can add >> (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode)) >> (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode)) >> to your `cc-mode.el` together with corresponding removals in >> `c-ts-mode.el`, even though in my book file-local settings of >> `mode: c-ts-mode` in non-personal files are just bugs. > The problem is that entries in major-mode-remap-defaults (and the other > one) do not accurately represent user preferences. Entries in `major-mode-remap-defaults` indeed do not reflect a user preference, just a "circumstantial" preference. [ Ideally, they shouldn't be set just by loading a file (whether `cc-mode.el` or `c-ts-mode.el`). But after a long protracted discussion the Emacs maintainers decided that it was the least bad choice in Emacs-29. This may be revisited in the future, e.g. for Emacs-31, but AFAICT it's too late to make such a change in Emacs-30. ] But entries in `major-mode-remap-alist` very much reflect a user preference. > As a value for mode: in C files, we need three distinct settings: for > C Mode, for c-ts-mode, and for any mode which handles C. If someone sends me a file which says `mode: c-ts`, I will complain and so should anyone else. Whether you edit it with `c-mode` or with `c-ts-mode` is not the file's business. >> It is supposed to opt-in, indeed. > So, for a user trying out Emacs 30, with a desktop file containing at > least one file with major mode c-ts-mode; visiting a file with the above > Local Variables section will indeed start the buffer with C Mode? If you see a file that stipulates `c-ts-mode`, complain to the file's author, not to us. > I haven't looked just yet, but can I assume there's a recipe in the > Emacs 30 NEWS file telling users how to switch between old behaviour > (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean > c-ts-mode depending on other settings)? If anything, Emacs-30 makes it easier than Emacs-29: (add-to-list 'major-mode-remap-alist '(c-mode)) In Emacs-29, you had to go and undo the mess in `auto-mode-alist`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 15:59:11 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 20:59:11 +0000 Received: from localhost ([127.0.0.1]:51031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC3PL-00081w-EQ for submit@debbugs.gnu.org; Fri, 15 Nov 2024 15:59:11 -0500 Received: from mail-ed1-f42.google.com ([209.85.208.42]:60666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC3PJ-00081j-Rh for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 15:59:10 -0500 Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5ceb75f9631so2731387a12.0 for <74339@debbugs.gnu.org>; Fri, 15 Nov 2024 12:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731704284; x=1732309084; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=qgO19S0e3VY2v9vpZaG0vhECtkeBbTN/t1o8cngFaek=; b=Ado8akrYBmDZyNrgA429jQv1N3ob6Xja5ko2KK5j7Oq3YBXquQm6+1YuvrLmfUnGcq Xrg8GYsbWa7n42FskV9E6ZfuQCCJ3voP0cUqHRc81YwJOqIF2wweUYukTHWs+MiOKG5S hRnEkNsDx38fHLYtXqsJEmWWAKYtumdBAY1esSwdOFmiYBhI0Biqo44eWjZ79iMq7nLH JJlEkcRDf/mnh2mKHVCT+ND6iFNx3XdjzXug3AM8XQy4EI16sjOVTqmgHoeFBJDl3l+C RSIoHyf2c7gTYwhWNe4tMR/yofUMvwTP2GPsGprFb4zgcIyKXxURjmHVjwF1Pg9engmC HLQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731704284; x=1732309084; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qgO19S0e3VY2v9vpZaG0vhECtkeBbTN/t1o8cngFaek=; b=o1c67zJVz+M9vQ2H1N4bo+MBHm2qM42Bl50i1kMNtTrAk702slx78vLisko/dm31HY qzFtwABY052c5aktUBL+lXwP9cv42sitMlzJ46FY/tX9BdO7Yj++iTLVbnLqhFE2A2/y KFneIvmTGy8dpHnPnA+dlJ5HtkUtut0OzPpDDvT2dlBo+eazquxMS8Knym87ND+n90Kz 0vc//c6YTln4RRpsFnVWWQ+kYBHjkYbzxAu4tuL45UjocRQ8WzA4KliQ/nAo7l2572Sh dcdG4G1mcvtEVbSciXin8pOGf+HPZO9m77E9wj5w7wMnHt2qBtE9baPKddT8CoiEhhrp zxsw== X-Forwarded-Encrypted: i=1; AJvYcCU9NOO35wCIeKidt6/rRrF1vpv3WWBUN3zHDDoGtEije0u3gwQeacH0//1GGsmLHS9HLnQmTQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzL/IIMh2y367PPTbRFEVHSUrdI1FOlT/UQbKBfb076kuAcVjds bVFxVmabFJDvw1yWWFYvocz2qfKuS4rFeKiB9vBOyJALH1CtNiwrTWKvi9iCRuWYhgqQ7Z/2jhh 1E6d1UMMvHI3Ow3jjZsFxdSywOs0= X-Google-Smtp-Source: AGHT+IHGXhsOmjHoo1YQKQRdOleJZOyul4g45hS2Bg5ELkCiy5Yvf0M0C+Zj7oNU84J9lzP0oeH7iRb+eoE1Y8miNiM= X-Received: by 2002:a05:6402:2686:b0:5cf:5ff9:2a24 with SMTP id 4fb4d7f45d1cf-5cf8fd12803mr3247602a12.32.1731704283530; Fri, 15 Nov 2024 12:58:03 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 15 Nov 2024 12:58:02 -0800 From: Stefan Kangas In-Reply-To: References: <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> MIME-Version: 1.0 Date: Fri, 15 Nov 2024 12:58:02 -0800 Message-ID: Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Alan Mackenzie , Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Alan Mackenzie writes: > On Fri, Nov 15, 2024 at 14:01:26 -0500, Stefan Monnier wrote: >> > One can write, in the Local Variables: section > >> > mode: c-ts > >> FWIW, unless this file is personal, this is very bad practice, and not >> only because `c-ts-mode` may not be available (in older Emacsen or if >> the user didn't build Emacs with tree-sitter support or doesn't have the >> appropriate grammar installed): the choice between `c-mode` and >> `c-ts-mode` is a personal preference, so it's not the file's business to >> tell the user which mode to use, just like it's not the file's business >> to tell the user which editor to use. +1 > Here is a section of a test file sent to bug-cc-mode some while ago: > > /* > ** Local Variables: > ** mode:c > ** indent-tabs-mode:nil > ** c-basic-offset:4 > ** End: > */ > > Here it is evident that by "mode:c" the OP means C Mode, not whatever > random mode happens to have taken the symbol `c-mode'. Yes, that is how Emacs behaves by default. However, the point of the new feature, major-mode-remap, is exactly to allow users to override that. This new feature is optional, and AFAICT the user choice is explicit and not "random". Clearly, c-mode is still favored, as it is the default, and many of us continue being happy users of it even while running a treesitter build. So this new feature very clearly only affects users that have somehow explicitly indicated that they want to use c-ts-mode instead. >> > .. This will cause the buffer to start in c-ts-mode regardless of any >> > other current settings. > >> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some >> other mode, such as `c-mode`. > > Maybe I should have said "regardless of any non-crazy settings". What makes anything about that setting crazy? I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-" cookie. Similarly, I expect that c-ts-mode users will want to use c-ts-mode precisely when a file has a "-*- c -*-" cookie. Again, being able to do that is exactly the point of major-mode-remap. I struggle to understand why that flexibility is controversial. It puts more power into users' hands, that's all. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 16:56:12 2024 Received: (at 74339) by debbugs.gnu.org; 15 Nov 2024 21:56:12 +0000 Received: from localhost ([127.0.0.1]:51174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC4IV-0002Jt-UQ for submit@debbugs.gnu.org; Fri, 15 Nov 2024 16:56:12 -0500 Received: from mail.muc.de ([193.149.48.3]:27241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC4IT-0002Je-VS for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 16:56:10 -0500 Received: (qmail 50100 invoked by uid 3782); 15 Nov 2024 22:56:03 +0100 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 22:56:03 +0100 Received: (qmail 21465 invoked by uid 1000); 15 Nov 2024 21:56:03 -0000 Date: Fri, 15 Nov 2024 21:56:03 +0000 To: Stefan Kangas Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, Eli Zaretskii , Stefan Monnier , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Fri, Nov 15, 2024 at 12:58:02 -0800, Stefan Kangas wrote: > Alan Mackenzie writes: > > On Fri, Nov 15, 2024 at 14:01:26 -0500, Stefan Monnier wrote: [ .... ] > > Here is a section of a test file sent to bug-cc-mode some while ago: > > /* > > ** Local Variables: > > ** mode:c > > ** indent-tabs-mode:nil > > ** c-basic-offset:4 > > ** End: > > */ > > Here it is evident that by "mode:c" the OP means C Mode, not whatever > > random mode happens to have taken the symbol `c-mode'. > Yes, that is how Emacs behaves by default. Only sort of, now. > However, the point of the new feature, major-mode-remap, is exactly to > allow users to override that. No, it is only _approximately_ for that. major-mode-remap-alist is for that. Modes using major-mode-remap-defaults override that setting without the users have much of a say. > This new feature is optional, and AFAICT the user choice is explicit > and not "random". No, that is the problem. Have a look at major-mode-remap-defaults, and how c-ts-mode uses it to cause the symbol `c-mode' to start c-ts-mode in certain circumstances. This is what I'm unhappy about. > Clearly, c-mode is still favored, as it is the default, and many of us > continue being happy users of it even while running a treesitter build. > So this new feature very clearly only affects users that have somehow > explicitly indicated that they want to use c-ts-mode instead. That "somehow" is the loading of c-ts-mode. I think that even C-h f c-ts-mode counts as an "explicit indication" of a supposed preference for c-ts-mode, given that it loads c-ts-mode (if it actually does). I don't think the current mechanism is ready for the release of Emacs 30. It hasn't been thought through thoroughly. > >> > .. This will cause the buffer to start in c-ts-mode regardless of any > >> > other current settings. > >> Actually, no: `major-mode-remap-*` can also remap `c-ts-mode` to some > >> other mode, such as `c-mode`. > > Maybe I should have said "regardless of any non-crazy settings". > What makes anything about that setting crazy? I think making a setting for c-ts-mode in order to get a buffer into c-mode is crazy. It is not the first thing one thinks about, faced with the problem of a buffer going into the wrong mode. > I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-" > cookie. Similarly, I expect that c-ts-mode users will want to use > c-ts-mode precisely when a file has a "-*- c -*-" cookie. We don't have fine enough control. /* mode: c */ followed by /* c-basic-offset: 4 */ in the Local Variables: section is a sure sign that C Mode is intended, not a random C handling mode. What I think we're lacking is an explicit setting or command for the user to state what her preferred mode for C actually is. major-mode-remap-alist isn't that setting - it's too involved, too awkward, and it talks about "remappinig modes" (its internal mechanism) rather than the user's preferred Mode for C. What we need is a defcustom 3-valued radio-button defaulting to "no explicit preference", and having other values "c-mode" and "c-ts-mode". > Again, being able to do that is exactly the point of major-mode-remap. > I struggle to understand why that flexibility is controversial. It > puts more power into users' hands, that's all. It involves c-ts-mode purloining CC Mode's symbols for its own use. If a user wishes to use major-mode-remap-alist for that, that's one thing - having it done by default in major-mode-remap-defaults by Emacs is something quite different, which I think is unacceptable. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 22:23:57 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 03:23:57 +0000 Received: from localhost ([127.0.0.1]:51618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC9Ph-00007U-1k for submit@debbugs.gnu.org; Fri, 15 Nov 2024 22:23:57 -0500 Received: from mail-ej1-f51.google.com ([209.85.218.51]:56488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tC9Pe-00007D-1X for 74339@debbugs.gnu.org; Fri, 15 Nov 2024 22:23:55 -0500 Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a9a6acac4c3so415032166b.0 for <74339@debbugs.gnu.org>; Fri, 15 Nov 2024 19:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731727368; x=1732332168; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=T1uT4eHgckL65faOCCYf0WP6VwIsyPAAuUWJcDuXkJg=; b=AogJ1j7DFMZJFCJcAyCYKx2SBGVJGoc1y+V5PWRoB7rUKQqdsT1SVuB0vYvSAPGaUG oh00QjZRAlitwXVbxjncGxXhUM5T9VibZkRsSJz9UtPrOh7mMi0GIHdODzpT89tc4K1j ENwMRLTegsOqhgqUFfkqt1nXLx6KAXih9EZEU9TcYSdiP4GhH15WzSAG1ImlpjRlADlN Bmfc128VFu3WI5QSJa5bCXrx9t7G4gwnfwTnkVUHcw4YI3n9iRqnSEIv1cfrTepBoRMT 6bJYs7R97nL4hfFS+eUYzuKv6ucJ+eebCoBnWy6zkR2ElvEyeI97I16mXPafKS1NBGj/ kiJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731727368; x=1732332168; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T1uT4eHgckL65faOCCYf0WP6VwIsyPAAuUWJcDuXkJg=; b=R03J4rPmMr2EcQ07CLu0Z3374kuFINm6UMkEoxYL16NxToGal23Mvm4nVa7ofNRmqT rd6AMwFvZuOrQPBe8wB5DBKqKukEosdTnTyW7gxZ8Yvn47uiwgQUw05xjIcVhbRCx4+B 8Dr/L/VRP8fRas6SnbrP9sFAB2TEpP25QpoU9Mb1kmvxJTynEZW43WCH1XJOh64jE7U2 5NEh0DC5UVFE5rbAbSGtfNfV+VuHk+KnwoxR4KjQcaoKEnFNYhNc7zj5YYQleziFSMjR K6WECwCVHQPnmqvdT2fJWJihtUSUBgdtms5cXTGg6Q5tJZfBQL+RtKnpQGc7m6elj2vM N7vw== X-Forwarded-Encrypted: i=1; AJvYcCWdm3FCD+/7VDOsVauwLKvrx6Zrl61FyfLcE7Qjk7mWbknBdEqx3FtozIQLQ9pVGkMDi3uXBw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw45Z5t/I4a8Uve2/+09oYhxcCH9LXno7XZwEGKeFgi/pxW1fuP eO+2sTsAugUuLtxa7xT1UxEGwGbU5w0uuW4VP5iWwkkuUdB7n/mYpsx3pVdrOcv3/At301l7hJH K2T5e8A+lvNgqYdjaT/OSkX4/vvc= X-Google-Smtp-Source: AGHT+IHLbYiey6c/6Onc/ITrDy9BENlEgeqtpxbyiqAEyvgEQprviIf2/Wez95o1deNB//zRMJC7ffJ+X5lB9qOCqwQ= X-Received: by 2002:a05:6402:350f:b0:5cf:3d22:6dd9 with SMTP id 4fb4d7f45d1cf-5cf8f949b0dmr3037826a12.0.1731727368038; Fri, 15 Nov 2024 19:22:48 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 15 Nov 2024 19:22:47 -0800 From: Stefan Kangas In-Reply-To: References: <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> MIME-Version: 1.0 Date: Fri, 15 Nov 2024 19:22:47 -0800 Message-ID: Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Alan Mackenzie Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , Stefan Monnier , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > That "somehow" is the loading of c-ts-mode. I think that even C-h f > c-ts-mode counts as an "explicit indication" of a supposed preference for > c-ts-mode, given that it loads c-ts-mode (if it actually does). It seems like you're right about that, in emacs -Q. FWIW, I consider that less than ideal, and would prefer that we did that only when enabling the mode. Loading files shouldn't change behaviour, exactly for this reason. So I'd be in favor of making such a change (on master). But that's me. > I don't think the current mechanism is ready for the release of Emacs 30. > It hasn't been thought through thoroughly. I see no release blocker at this late stage, myself. >> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-" >> cookie. Similarly, I expect that c-ts-mode users will want to use >> c-ts-mode precisely when a file has a "-*- c -*-" cookie. > > We don't have fine enough control. /* mode: c */ followed by /* > c-basic-offset: 4 */ in the Local Variables: section is a sure sign that > C Mode is intended, not a random C handling mode. > > What I think we're lacking is an explicit setting or command for the user > to state what her preferred mode for C actually is. > major-mode-remap-alist isn't that setting - it's too involved, too > awkward, and it talks about "remappinig modes" (its internal mechanism) > rather than the user's preferred Mode for C. I think `major-mode-remap-alist` is the explicit setting that we have. That said, I wouldn't personally close the door to a proposal that is significantly better. I'm just not sure what it would look like. > What we need is a defcustom 3-valued radio-button defaulting to "no > explicit preference", and having other values "c-mode" and > "c-ts-mode". The benefit of `major-mode-remap` is that it's sufficiently general not just for c-mode/c-ts-mode, but for all other cases where we have two or more modes, such as yaml-mode/yaml-ts-mode, etc. And it will handle whatever new modes we can dream up in the future. It also fits in nicely with the equally general `auto-mode-alist`, `interpreter-mode-alist`, etc., that we already have. For these reasons, I think I prefer `major-mode-remap` to a specific option just for c-mode/c-ts-mode. >> Again, being able to do that is exactly the point of major-mode-remap. >> I struggle to understand why that flexibility is controversial. It >> puts more power into users' hands, that's all. > > It involves c-ts-mode purloining CC Mode's symbols for its own use. If a > user wishes to use major-mode-remap-alist for that, that's one thing - > having it done by default in major-mode-remap-defaults by Emacs is > something quite different, which I think is unacceptable. So you don't like the specific detail that it overloads the use of the symbol `c-mode` as a proxy for saying C files? FWIW, and AFAIR, I think we discussed this overloading of the mode name on the list, and the other option was to introduce a new concept of "languages" into Emacs Lisp, where we would have had alist entries like `(c . c-mode)` instead. The conclusion was that doing that would be more complex and it was hard to justify this complication. I can't remember that any other ways to avoid this overloading were suggested. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 01:17:54 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 06:17:54 +0000 Received: from localhost ([127.0.0.1]:51816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCC82-000829-1z for submit@debbugs.gnu.org; Sat, 16 Nov 2024 01:17:54 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCC80-00081s-5a for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 01:17:52 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 78FB84405DE; Sat, 16 Nov 2024 01:17:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731737863; bh=73XlPf4l1ipz9q0Xk5KRc5+yzaIZKwYgwsn2Qf3+kG4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ohKbDypllZRm8G1c4jfSYwF9XyDXN3a71IWVosgYx68X0Pjfn5v4gW9Psjipj04kL BcoZCfvGr++0Them4BDHeD9IJRffcZTYMeDEMzn6hrgmUMxmy/hfIIUlfYhIM/hO6k Z7DFKs5oA6fDSU89MJn//Qt4/2trdWvoY4rtCe1yxcHaijPaniJKbygdB4BAOAMscv wv8quDq3l0wpv/sSIqNbwmsevTQFaXrKcpIz+TK0isI+RnB9sdPGbC/pHP9TzimHCo RwFIl6NPPe+gCtX1WnPyFfRcZ5UFyZ008ANINLQRFHgn9diBh8r27CnN0WU5MjJoJM +6+QwuD6Cme1A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D2AA64404BD; Sat, 16 Nov 2024 01:17:43 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8FA7D1201A2; Sat, 16 Nov 2024 01:17:43 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "Fri, 15 Nov 2024 21:56:03 +0000") Message-ID: References: <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> Date: Sat, 16 Nov 2024 01:17:41 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.021 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , Stefan Kangas , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > No, that is the problem. Have a look at major-mode-remap-defaults, and > how c-ts-mode uses it to cause the symbol `c-mode' to start c-ts-mode in > certain circumstances. This is what I'm unhappy about. In which way is this worse than what we have in Emacs-29 where loading `c-ts-mode` does things like: (add-to-list 'auto-mode-alist '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\)\\'" . c-ts-mode)) (add-to-list 'auto-mode-alist '("\\.x[pb]m\\'" . c-ts-mode)) ? > That "somehow" is the loading of c-ts-mode. I think that even C-h f > c-ts-mode counts as an "explicit indication" of a supposed preference for > c-ts-mode, given that it loads c-ts-mode (if it actually does). Yup, and the same happens in Emacs-29. > I don't think the current mechanism is ready for the release of Emacs 30. I don't see a regression here. > We don't have fine enough control. /* mode: c */ followed by /* > c-basic-offset: 4 */ in the Local Variables: section is a sure sign that > C Mode is intended, not a random C handling mode. In your head, maybe. I think for most users of other C modes (e.g. `c-ts-mode` or `sm-c-mode`), the /* mode: c */ thingy just means that this file should use their favorite major mode for C. > What I think we're lacking is an explicit setting or command for the > user to state what her preferred mode for C actually is. You still haven't explained why the user's personal preference about the major mode should be stated in the file. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:18:38 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 08:18:38 +0000 Received: from localhost ([127.0.0.1]:52004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCE0s-00054K-9T for submit@debbugs.gnu.org; Sat, 16 Nov 2024 03:18:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCE0q-000548-86 for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 03:18:36 -0500 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 1tCE0h-00044K-IP; Sat, 16 Nov 2024 03:18:28 -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=ZK/6BFfsoOO4Ij9YlloSnjFt4qoLOyYVc6s+0ky1BEM=; b=X3gkninmrk1Z i2Y1fP6OqsfV/vf31DDYsg8Z/UK8WiLnPkSair9cG231RuwZ3/9bZ6x6cE5iUJsqXghIwxX9z7zQP aETPbnK4a6kyRtWhkzxmUJWT/BDyY2GyKG7jlsY0FRrrMtODIKBlA4bqtulXS9k/oDR9yA9Jmq8oK IQdYENhgOOjLTGsjrInz0NSkNOA7Ewk0uAEC8ydYTHC2yqp0EPZI7TD8B63/Jq9IEKUfghJZscwY4 U+bA1GxFnt0bTOZVehF/uT1AjrhWTowvHm+HQVrEXnUYglB6upFrqHx8RfpTvaj50Pxh78OJ5Ls4F fK9TcFrE4x1VYBsmxvws4A==; Date: Sat, 16 Nov 2024 10:18:24 +0200 Message-Id: <864j47iobz.fsf@gnu.org> From: Eli Zaretskii To: acm@muc.de, Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 16 Nov 2024 01:17:41 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: stefankangas@gmail.com, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Stefan Kangas , Eli Zaretskii , > 74339@debbugs.gnu.org > Date: Sat, 16 Nov 2024 01:17:41 -0500 > > > No, that is the problem. Have a look at major-mode-remap-defaults, and > > how c-ts-mode uses it to cause the symbol `c-mode' to start c-ts-mode in > > certain circumstances. This is what I'm unhappy about. > > In which way is this worse than what we have in Emacs-29 where loading > `c-ts-mode` does things like: > > (add-to-list 'auto-mode-alist > '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\)\\'" . c-ts-mode)) > (add-to-list 'auto-mode-alist '("\\.x[pb]m\\'" . c-ts-mode)) > > ? > > > That "somehow" is the loading of c-ts-mode. I think that even C-h f > > c-ts-mode counts as an "explicit indication" of a supposed preference for > > c-ts-mode, given that it loads c-ts-mode (if it actually does). > > Yup, and the same happens in Emacs-29. Right. Moreover, in Emacs 29 the modification of auto-mode-alist only took care of visiting C files without a mode cookie. In addition, with Emacs 29, once the user loaded c-ts-mode, there was no way for the user to go back to using C Mode; with the changes we propose to make in cc-mode.el and c-ts-mode.el, this will be possible. So Emacs 30 will not regress from Emacs 29, and will make the situation at least a tad better. > > I don't think the current mechanism is ready for the release of Emacs 30. > > I don't see a regression here. Right, and so no obstacles for releasing Emacs 30, once we make the proposed changes in cc-mode.el and in c-ts-mode.el, which rectify the tweaking of major-mode-remap-defaults. > > What I think we're lacking is an explicit setting or command for the > > user to state what her preferred mode for C actually is. Yes, and we should work on adding that. But this will not happen in Emacs 30, especially since we don't yet have a clear idea how to do this. Alan, please help us release Emacs 30 sooner rather than later by agreeing to the proposed changes in cc-mode.el and in c-ts-mode.el. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 04:53:06 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 09:53:06 +0000 Received: from localhost ([127.0.0.1]:52146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCFUH-0001A1-Sc for submit@debbugs.gnu.org; Sat, 16 Nov 2024 04:53:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCFUF-00019U-Jt for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 04:53:04 -0500 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 1tCFU9-0007ty-3o; Sat, 16 Nov 2024 04:52:57 -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=BB4EepOWzvQvuENzBgNaoCdV9itaUlzUYZbPMSNsm24=; b=mPQzNUbZV487 uodtgT79UdHoskD6OSLgiZlYZDRD+UUVQaNO77wPvPfLr/hRBZ4tv+VeijN5tPMQLVIGulAqak9vY LCYt3Ny24azpzW7GBL7ga8v712oHxs0WRVdjuj6estPpq0z9FSgw4lVyHjx+c3qBIPzXxDnlu/Wro zvP4XlYtYPAy6+UT+Yf0keFi2ZDb1Axp7zblBVEx4hb6cVZvGQ5oA9Nd9ufpDIJBGbjHktgapUFGo uev8CJ3xpRRZgm9hjqcu2TT43tO3Oibzt5fKmv1heoSXDVSS/1H4ZqugeOGas/tWl3np/BN/0ZCgc 8J5UsEM/JKY5YBLWiJFVJA==; Date: Sat, 16 Nov 2024 11:52:53 +0200 Message-Id: <86zflzh5e2.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 15 Nov 2024 19:46:03 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 15 Nov 2024 19:46:03 +0000 > Cc: Eli Zaretskii , 74339@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > So, for a user trying out Emacs 30, with a desktop file containing at > least one file with major mode c-ts-mode; visiting a file with the above > Local Variables section will indeed start the buffer with C Mode? No, it will turn on the mode specified in the desktop file. And it is not necessarily wrong: desktop.el restores the session as it was before Emacs was shut down, so using the same major mode might be exactly what the user expect. (It could also be against user expectations, which is why I think we need a user option to let users control what desktop.el does in this case.) > I haven't looked just yet, but can I assume there's a recipe in the > Emacs 30 NEWS file telling users how to switch between old behaviour > (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean > c-ts-mode depending on other settings)? There is now. > Is the default to keep the old behaviour, as is customary with new > features in Emacs? Yes, as long as c-ts-mode was not loaded. People who don't want to depend on remapping caused by loading features or packages should customize major-mode-remap-alist to express their preferences. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 05:26:12 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 10:26:12 +0000 Received: from localhost ([127.0.0.1]:52186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCG0K-0002lf-Bs for submit@debbugs.gnu.org; Sat, 16 Nov 2024 05:26:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCG0I-0002lN-3C for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 05:26:10 -0500 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 1tCG0A-0002Bv-5F; Sat, 16 Nov 2024 05:26:02 -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=9wCA4RPTrYNvn0e/Dyb2qCJ9lHOATPCRSeXC6Pr6sM0=; b=lbstoAeGGElI brM2dMY2Rtii5YIRMOo338k9r782bbloatutTL17XzF5grKMxdyzsqm9yt+4JCJyCsJ7pLyaYqJev mx2U/whWBrpGWC77WPHvA9F2CN2MsY6B+H37WZAO9PlQZwdC4eVuVJz25hk/C5pou612tsxB/XOfc CNQJPgp7YR5Hm53HTRwjRC6ea+u/kDmmO4kiWcV2yr/n535+yLOvXf6X82Ncrq/g8x7T0/svt0KcH uJqNL21QhoC5eYHUmRL7thetxjDS3pcbLKnxdER1JqvMyQ6cUPVPZdzwnIjWPo3EBo0K1r+69TVPG yelBPgmksvMugV6gD3rWvA==; Date: Sat, 16 Nov 2024 12:25:57 +0200 Message-Id: <86wmh3h3uy.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 15 Nov 2024 15:45:46 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , 74339@debbugs.gnu.org > Date: Fri, 15 Nov 2024 15:45:46 -0500 > > > Here is a section of a test file sent to bug-cc-mode some while ago: > > > > /* > > ** Local Variables: > > ** mode:c > > ** indent-tabs-mode:nil > > ** c-basic-offset:4 > > ** End: > > */ > > > > Here it is evident that by "mode:c" the OP means C Mode, not whatever > > random mode happens to have taken the symbol `c-mode'. > > It is evident that the OP means CC-mode's C Mode because the bug report > is sent to `bug-cc-mode`, indeed. Perhaps we should introduce (on master) a boolean variable to disable mode remapping? Then files which want to force a mode could specify that. > >> If you really insist, we can add > >> (add-to-list 'major-mode-remap-defaults '(c-ts-mode . c-mode)) > >> (add-to-list 'major-mode-remap-defaults '(c++-ts-mode . c++-mode)) > >> to your `cc-mode.el` together with corresponding removals in > >> `c-ts-mode.el`, even though in my book file-local settings of > >> `mode: c-ts-mode` in non-personal files are just bugs. > > The problem is that entries in major-mode-remap-defaults (and the other > > one) do not accurately represent user preferences. > > Entries in `major-mode-remap-defaults` indeed do not reflect > a user preference, just a "circumstantial" preference. > > [ Ideally, they shouldn't be set just by loading a file (whether > `cc-mode.el` or `c-ts-mode.el`). But after a long protracted > discussion the Emacs maintainers decided that it was the least bad > choice in Emacs-29. This may be revisited in the future, e.g. for > Emacs-31, but AFAICT it's too late to make such a change in > Emacs-30. ] yes, it's too late to change this for Emacs 30. So Emacs 30 will make only a half-step in this direction. > But entries in `major-mode-remap-alist` very much reflect a user preference. Yes. I have now added to the Emacs user manual explicit advice to customize that to express user's firm preferences that override any "internally-motivated" mode remapping. > > I haven't looked just yet, but can I assume there's a recipe in the > > Emacs 30 NEWS file telling users how to switch between old behaviour > > (-*- c -*- always means C mode) and new behaviour (-*- c -*- can mean > > c-ts-mode depending on other settings)? > > If anything, Emacs-30 makes it easier than Emacs-29: > > (add-to-list 'major-mode-remap-alist '(c-mode)) This is now in NEWS and in the manual. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 06:45:59 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 11:45:59 +0000 Received: from localhost ([127.0.0.1]:52323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCHFX-0006VS-68 for submit@debbugs.gnu.org; Sat, 16 Nov 2024 06:45:59 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCHFU-0006VG-T9 for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 06:45:57 -0500 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 1tCHFN-0000QM-Op; Sat, 16 Nov 2024 06:45:49 -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=7wZyTrhILSnd9sUuHU/O3+a6QWQqEHoFnvXvCZcUm48=; b=PbrcJXCVYto9 8beBNAWWSzuZuCC0xJC8LyYBTY/gCn0QZoGmu21wK37xOyy0AL+kWmxRWYt8FgTrH/iZV6IGNk1F8 bccuO/m/zFEL7yhdSaeDZfSPBxCYg4UVCpZjcXmONshdRx0f4YhsR55HIbg4XNuNoX1p8+q+qvcci SSxn/hhvGTaSrCVRHRLS7DLlkZs48cvSPewOxlhmLF29TnURJ7tB9DbJgC7eXYMiRbgqfNwHqig7I SkC9z8swl541CIYJwn/N1pIrnTygZFr0ixNyzmH2Nn98E0OuldZ94pQIFmLR/NSX09zm1kIr+f54c vezsprDvj1YXFVFJk7mngw==; Date: Sat, 16 Nov 2024 13:45:45 +0200 Message-Id: <86o72fh05y.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Fri, 15 Nov 2024 19:22:47 -0800) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Fri, 15 Nov 2024 19:22:47 -0800 > Cc: Stefan Monnier , Eli Zaretskii , 74339@debbugs.gnu.org > > Alan Mackenzie writes: > > > That "somehow" is the loading of c-ts-mode. I think that even C-h f > > c-ts-mode counts as an "explicit indication" of a supposed preference for > > c-ts-mode, given that it loads c-ts-mode (if it actually does). > > It seems like you're right about that, in emacs -Q. > > FWIW, I consider that less than ideal, and would prefer that we did that > only when enabling the mode. Loading files shouldn't change behaviour, > exactly for this reason. So I'd be in favor of making such a change (on > master). But that's me. If we are discussing changes on master (which is not the subject of this bug report), then turning on a mode is not necessarily a reliable sign of the user preferences. The simplest example is when a user turns on the mode in a single buffer, for whatever reasons. I think we need special-purpose commands to express global user preferences regarding which mode to use for a certain file type. However, this is for |Emacs 31, and should be discussed separately. > >> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-" > >> cookie. Similarly, I expect that c-ts-mode users will want to use > >> c-ts-mode precisely when a file has a "-*- c -*-" cookie. > > > > We don't have fine enough control. /* mode: c */ followed by /* > > c-basic-offset: 4 */ in the Local Variables: section is a sure sign that > > C Mode is intended, not a random C handling mode. > > > > What I think we're lacking is an explicit setting or command for the user > > to state what her preferred mode for C actually is. > > major-mode-remap-alist isn't that setting - it's too involved, too > > awkward, and it talks about "remappinig modes" (its internal mechanism) > > rather than the user's preferred Mode for C. > > I think `major-mode-remap-alist` is the explicit setting that we have. > That said, I wouldn't personally close the door to a proposal that is > significantly better. I'm just not sure what it would look like. > > > What we need is a defcustom 3-valued radio-button defaulting to "no > > explicit preference", and having other values "c-mode" and > > "c-ts-mode". > > The benefit of `major-mode-remap` is that it's sufficiently general not > just for c-mode/c-ts-mode, but for all other cases where we have two or > more modes, such as yaml-mode/yaml-ts-mode, etc. And it will handle > whatever new modes we can dream up in the future. > > It also fits in nicely with the equally general `auto-mode-alist`, > `interpreter-mode-alist`, etc., that we already have. > > For these reasons, I think I prefer `major-mode-remap` to a specific > option just for c-mode/c-ts-mode. Having an option that is specific to C mode is definitely not the best idea. We should have a more general mechanism for users to express their preferences, which are at the same time more convenient and easy-to-use than customizing major-mode-remap-alist, and perhaps also allow more selective remapping, like only when a file has no mode cookie. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 09:04:19 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 14:04:19 +0000 Received: from localhost ([127.0.0.1]:52592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJPO-0004FU-PG for submit@debbugs.gnu.org; Sat, 16 Nov 2024 09:04:19 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:55379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJPL-0004FI-J5 for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 09:04:17 -0500 Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5cb15b84544so575888a12.2 for <74339@debbugs.gnu.org>; Sat, 16 Nov 2024 06:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731765795; x=1732370595; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=+KvEr0B4hge+w+G2LQTFOp4gGT0L03N29LSx/2czXdQ=; b=OMRfive85PS6WelqqYzl2juRh07wQ5vLHPFEbYPccwO2gAHqCc9gSNDiyv9sBk8p+G 4kWb1iLkEq6NG828DoyfuVeVebfBjX244p3Ej2BT6rgKzXh0hd37b8+08/biU9HhZI31 6cn3n+y/Z1X/gzsPuUOVAjX3G/L7jqzQBkb0QuaWLSslWk9unV02hd9wjuyw/XlEDIVk As0NIVQneS1TXcblybaneNofG7P+JW1W2eBsXR6XsP6q1tpzb42ncUC6TGw906WOIQyp 2TbERhpiwPQpqFMGvQOL9AqQHDuk7JYjytibfEqh1pycFPMvIbX6yO2QpTX5wLqJtbY9 x4Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731765795; x=1732370595; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+KvEr0B4hge+w+G2LQTFOp4gGT0L03N29LSx/2czXdQ=; b=m3DWEYTiyJm8cME74xGk39+uIdkvay5Tql8Bl2Kdi+rd1z7k0YCo/zhhOYDMRxBP5B npfdGVWyqC3wJBdgVwD70msf7ZMoBOvGfKQk1EJBkedn+qzKpG6pXb8q5MOP2/ANoiCN 9OD3vAW+w6TIwds3rwpKDmln7UbF0HAnAT9h9dxnNFjdjkgj39XOZBR50epgBtLY6Y7U QEZjulmhKDcRJHqJt7Jqbuw5tf22RROUh/spa5JYeOgvI9Jd1dC25tO5pA0u9CAmJ199 ug9pl7qAurQJJguSIUBBDMNsh3TxXNUut2IEHJd10v+5bR7Bd18wAbd5S6e4ep3+c2CR 9tTA== X-Forwarded-Encrypted: i=1; AJvYcCX7CerkL85QT9MnUd2zD4z8bsSqtPAz1rIrYi+vpeR3Zal8j29jKNA/PDdo8en2pKifPbL6Sg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyJJ/Qxmj2p316XjzqEOVQ5Pt4yJJHZaJ/979qvnDM3dUn74ksU K/DFdSR+Zbg64pSc5pm6mPJ3JuO731y2IPMd2s27gxk2IYbDL74FuhPd0Nuxw/n0D+ZG7cBQI4y CfxDFUSXka8wqOTyJyPan3z0bl0k= X-Google-Smtp-Source: AGHT+IHNJJHNuzuy458oA9xp/5vWLpP4kzlmxoiYZ+DhSY3y0zMTaLEtd4IXC3K7fKynigbwM9iUoJau/jilKU3so+o= X-Received: by 2002:a05:6402:4406:b0:5cf:754b:1734 with SMTP id 4fb4d7f45d1cf-5cf8fd336eamr4398477a12.21.1731765794455; Sat, 16 Nov 2024 06:03:14 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 16 Nov 2024 06:03:14 -0800 From: Stefan Kangas In-Reply-To: <86wmh3h3uy.fsf@gnu.org> References: <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> <86wmh3h3uy.fsf@gnu.org> MIME-Version: 1.0 Date: Sat, 16 Nov 2024 06:03:14 -0800 Message-ID: Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii , Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: Eli Zaretskii , 74339@debbugs.gnu.org >> Date: Fri, 15 Nov 2024 15:45:46 -0500 >> >> > Here it is evident that by "mode:c" the OP means C Mode, not whatever >> > random mode happens to have taken the symbol `c-mode'. >> >> It is evident that the OP means CC-mode's C Mode because the bug report >> is sent to `bug-cc-mode`, indeed. > > Perhaps we should introduce (on master) a boolean variable to disable > mode remapping? Then files which want to force a mode could specify > that. I'm not sure what is the use case for something like that. Do we want files to be able to override user preferences? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 09:35:47 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 14:35:48 +0000 Received: from localhost ([127.0.0.1]:52662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJtr-00062J-Fz for submit@debbugs.gnu.org; Sat, 16 Nov 2024 09:35:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJtp-000627-9H for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 09:35:46 -0500 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 1tCJtj-0007K0-GH; Sat, 16 Nov 2024 09:35:39 -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=vkoFyVhHF13C5nTb2vs9eAZFXgMpOBCqXvf2qORgdNw=; b=QBRAbvIpwilc jdNgdyk+FVECCz49MBTA7f2svBidA47LGtMpM7cvOH6n8euSRcmlHmwyVzb4GQBRZz7VQfGpgJize f+qxcOWMOYZKnsah2MnKxjZ9JLkQplJvJz4UL7nAnHsfP/TqDO/1H3OKbwDSAKFJE68hJLplD9Ca8 piTZWZoyEKHdAaeTOZXtK0EgyO8a/JqJeoOOPYoTYiHJ8e0wJZKzdR2ED84JaT7Pdckcz3PSIoU5j BHOritNM3LqBFcqiLnwnyO8gIYrEzltYfW/4nBXsDvgOsab8aFVBrL2+MiYTMeAK+Y5t0sg/rF4AG z+QOxrReUrd/wbNgeUlZ4w==; Date: Sat, 16 Nov 2024 16:35:36 +0200 Message-Id: <86zflzfdqf.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Sat, 16 Nov 2024 06:03:14 -0800) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <861pzdk4aq.fsf@gnu.org> <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> <86wmh3h3uy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Sat, 16 Nov 2024 06:03:14 -0800 > Cc: acm@muc.de, 74339@debbugs.gnu.org > > Eli Zaretskii writes: > > >> From: Stefan Monnier > >> Cc: Eli Zaretskii , 74339@debbugs.gnu.org > >> Date: Fri, 15 Nov 2024 15:45:46 -0500 > >> > >> > Here it is evident that by "mode:c" the OP means C Mode, not whatever > >> > random mode happens to have taken the symbol `c-mode'. > >> > >> It is evident that the OP means CC-mode's C Mode because the bug report > >> is sent to `bug-cc-mode`, indeed. > > > > Perhaps we should introduce (on master) a boolean variable to disable > > mode remapping? Then files which want to force a mode could specify > > that. > > I'm not sure what is the use case for something like that. > Do we want files to be able to override user preferences? The case of CC Mode bug report above might be one such example. A (hypothetical) tutorial for using CC Mode (e.g., teaching about its interactive indentation customization feature) might be another. It isn't supposed to be a frequent situation, but when it happens, why not allow it to be supported? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 13:17:18 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 18:17:18 +0000 Received: from localhost ([127.0.0.1]:54744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNME-0008Dj-8t for submit@debbugs.gnu.org; Sat, 16 Nov 2024 13:17:18 -0500 Received: from mail.muc.de ([193.149.48.3]:14295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNMB-0008DM-Uu for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 13:17:16 -0500 Received: (qmail 47415 invoked by uid 3782); 16 Nov 2024 19:17:09 +0100 Received: from muc.de (p4fe151f0.dip0.t-ipconnect.de [79.225.81.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 16 Nov 2024 19:17:08 +0100 Received: (qmail 11369 invoked by uid 1000); 16 Nov 2024 18:17:08 -0000 Date: Sat, 16 Nov 2024 18:17:08 +0000 To: Stefan Kangas Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , Stefan Monnier , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Fri, Nov 15, 2024 at 19:22:47 -0800, Stefan Kangas wrote: > Alan Mackenzie writes: > > That "somehow" is the loading of c-ts-mode. I think that even C-h f > > c-ts-mode counts as an "explicit indication" of a supposed preference for > > c-ts-mode, given that it loads c-ts-mode (if it actually does). > It seems like you're right about that, in emacs -Q. > FWIW, I consider that less than ideal, and would prefer that we did that > only when enabling the mode. Loading files shouldn't change behaviour, > exactly for this reason. So I'd be in favor of making such a change (on > master). But that's me. We could perhaps talk about this again after the release of Emacs 30. > > I don't think the current mechanism is ready for the release of Emacs 30. > > It hasn't been thought through thoroughly. > I see no release blocker at this late stage, myself. > >> I'd use that setting, if I ever ran into any files with a "-*- c-ts -*-" > >> cookie. Similarly, I expect that c-ts-mode users will want to use > >> c-ts-mode precisely when a file has a "-*- c -*-" cookie. > > We don't have fine enough control. /* mode: c */ followed by /* > > c-basic-offset: 4 */ in the Local Variables: section is a sure sign that > > C Mode is intended, not a random C handling mode. > > What I think we're lacking is an explicit setting or command for the user > > to state what her preferred mode for C actually is. > > major-mode-remap-alist isn't that setting - it's too involved, too > > awkward, and it talks about "remappinig modes" (its internal mechanism) > > rather than the user's preferred Mode for C. > I think `major-mode-remap-alist` is the explicit setting that we have. > That said, I wouldn't personally close the door to a proposal that is > significantly better. I'm just not sure what it would look like. > > What we need is a defcustom 3-valued radio-button defaulting to "no > > explicit preference", and having other values "c-mode" and > > "c-ts-mode". > The benefit of `major-mode-remap` is that it's sufficiently general not > just for c-mode/c-ts-mode, but for all other cases where we have two or > more modes, such as yaml-mode/yaml-ts-mode, etc. And it will handle > whatever new modes we can dream up in the future. > It also fits in nicely with the equally general `auto-mode-alist`, > `interpreter-mode-alist`, etc., that we already have. > For these reasons, I think I prefer `major-mode-remap` to a specific > option just for c-mode/c-ts-mode. I was thinking more of a macro which would create the option mechanism for any such mode, and which wouldn't have to make a user consider "remapping". > >> Again, being able to do that is exactly the point of major-mode-remap. > >> I struggle to understand why that flexibility is controversial. It > >> puts more power into users' hands, that's all. > > It involves c-ts-mode purloining CC Mode's symbols for its own use. If a > > user wishes to use major-mode-remap-alist for that, that's one thing - > > having it done by default in major-mode-remap-defaults by Emacs is > > something quite different, which I think is unacceptable. > So you don't like the specific detail that it overloads the use of the > symbol `c-mode` as a proxy for saying C files? Indeed not. It weakens the prime purpose of those names, which is to identify and call those modes in CC Mode. Should `c-mode' get the meaning "any old mode which handles C", then there will be no unambiguous way for an elisp programmer to refer to c-mode. c-mode has no other name, and nobody has suggested giving it one. Names are important, and have power. If somebody used "Stefan Kangas" to refer to some other person, you would not like it either. > FWIW, and AFAIR, I think we discussed this overloading of the mode name > on the list, and the other option .... _One_ other option. There were presumably several. > .... was to introduce a new concept of "languages" into Emacs Lisp, > where we would have had alist entries like `(c . c-mode)` instead. The > conclusion was that doing that would be more complex and it was hard to > justify this complication. I can't remember that any other ways to > avoid this overloading were suggested. Had I been invited to this discussion, I would certainly have suggested some other way(s), as I have done recently in this thread. The current discussion would then not need to have taken place. Could you give me some coordinates for the discussion, please? Back in May, when I committed the patch that has proven so unpopular, I searched for such a discussion, but couldn't find it. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 15:51:24 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 20:51:24 +0000 Received: from localhost ([127.0.0.1]:54956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCPlL-0006n5-BB for submit@debbugs.gnu.org; Sat, 16 Nov 2024 15:51:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCPlI-0006mm-JB for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 15:51:21 -0500 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 1tCPlA-0004ai-Fp; Sat, 16 Nov 2024 15:51:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=1IC9PKBmMVNwOvNfwM4LY3eZBIkQtVB6biPlCs27FXc=; b=bYarxNErWYc9U2PI/bvq Rp4ripAZj/aqSAmH+RBwBGagZ7GPeRpuXT9IAvV5+IHKRMFwvqbYwNeexA9bzS9xQUe1a5uqJS7/V gmZJg6fayraWRz3J4m37x0ShHid8uUu6XZXWtRlaN8v4noMyTG7uTPfZzxwH9pn7+vJycVkdtdl39 NSqykT9g1JNib5c6OEUNeHWY0o5tjKsdGiP1hW+uBv5myr0FyLepf4K1z+yNjeLNgdpvlPAJJe07W 9O7RgHKAposeUI7dyKbdf1/tch20qXIPa0GLUo8dLkYPN5gTA2+xGx3fvJNEqICGeJBwILoHSbkER Ry7C8beAcy+ROw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tCPlA-0008Tg-40; Sat, 16 Nov 2024 15:51:12 -0500 From: Andrea Corallo To: Alan Mackenzie Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: (Alan Mackenzie's message of "Wed, 13 Nov 2024 22:34:19 +0000") References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> Date: Sat, 16 Nov 2024 15:51:12 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Eli Zaretskii , Stefan Monnier , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Alan Mackenzie writes: > 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. Hello Alan, pushing controversial commits in our repository to spark discussion is not the right use of emacs.git, also this is not the behaviour what we expect from developers with write access to our repo. Please take this in account for the future. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 15:54:21 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 20:54:21 +0000 Received: from localhost ([127.0.0.1]:54965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCPoD-0006tO-Gg for submit@debbugs.gnu.org; Sat, 16 Nov 2024 15:54:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCPo9-0006sj-8y for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 15:54:18 -0500 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 1tCPo3-000620-EN; Sat, 16 Nov 2024 15:54:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=66nDcLjTUgi645U1zsiRBP+3RQj5mHJeo+99Vbmt104=; b=fngODiYvxLMdHFjKVSGe ssidlkjN9IMKk5na6+DisVMFxDSzG5Z3wNqYXvPvjuZ7/GRTVLsBbA2w7VeL1nKUWSW4zf13HsWMv J9FdSIFc7euFbN/KmCSDGEGuD8MiVMXKzEQ7ComomOI8fbcbSJ6w0lMNIJXzZjMb+SK4Zc8A7UM52 XmLDgnm/Js4tyI0+HOZllvYkAXP10Vt9A0l23hJcYHCNaM9oplWchlXuy7DkFeNWsA6AQe7wWGdBA 4iRHZ0OUw3/22U4fM0h7nnZ5/UYjFNs0us83N1FeS96oVPYOtKKQP7wUKhcNkcnPSV3isnZpiqVB+ 5Or9cyzPlMduQg==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tCPo2-00008B-I5; Sat, 16 Nov 2024 15:54:10 -0500 From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86msi2jfl8.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2024 12:05:07 +0200") References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <697529d6-0591-4a80-b640-7ddce7dc246b@gutov.dev> <86msi2jfl8.fsf@gnu.org> Date: Sat, 16 Nov 2024 15:54:10 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: Dmitry Gutov , 74339@debbugs.gnu.org, monnier@iro.umontreal.ca, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Date: Thu, 14 Nov 2024 11:24:32 +0200 >> Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org >> From: Dmitry Gutov >> [...] >> I'm personally skeptical that loading a package (or invoking a mode) >> indicates a strong user preference, but ok, let's call it that. > > We can change this in Emacs 31, but it's too late for Emacs 30. +1 From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 16:56:15 2024 Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 21:56:15 +0000 Received: from localhost ([127.0.0.1]:55055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCQm6-0001MI-Ge for submit@debbugs.gnu.org; Sat, 16 Nov 2024 16:56:14 -0500 Received: from mail.muc.de ([193.149.48.3]:22139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCQm2-0001M3-Fy for 74339@debbugs.gnu.org; Sat, 16 Nov 2024 16:56:13 -0500 Received: (qmail 16405 invoked by uid 3782); 16 Nov 2024 22:56:04 +0100 Received: from muc.de (p4fe151f0.dip0.t-ipconnect.de [79.225.81.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 16 Nov 2024 22:56:03 +0100 Received: (qmail 17004 invoked by uid 1000); 16 Nov 2024 21:56:03 -0000 Date: Sat, 16 Nov 2024 21:56:03 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <86cyiwimlr.fsf@gnu.org> <864j47iobz.fsf@gnu.org> <86ttc7f7jo.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86ttc7f7jo.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: acm@muc.de, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, Nov 16, 2024 at 18:49:15 +0200, Eli Zaretskii wrote: > > Date: Sat, 16 Nov 2024 15:40:24 +0000 > > Cc: acm@muc.de > > From: Alan Mackenzie > > > Alan, please help us release Emacs 30 sooner rather than later by > > > agreeing to the proposed changes in cc-mode.el and in c-ts-mode.el. > > I don't and can't agree to these changes as they're currently proposed. > > My concerns expressed over the last few days haven't been addressed; > > they've merely been dismissed. In effect, you're proposing just > > reverting my patch from May, without addressing the reasons for that > > patch. > No, not to revert: to amend it in relatively minor ways. No. Nullifying it's main purpose and leaving only a toothless hulk is not relatively minor. The purpose of the patch was to protect CC Mode's symbols. It had unfortunate side effects, hence this bug. > Specifically, I'm asking not to add these entries to > major-mode-remap-defaults: > (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) > (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) > (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) > Instead, _remove_ them from the list (if they are in the list). The > rest, i.e. adding the elements that "remap" c-mode to itself, viz.: > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > (if (and (setq entry (assq mode major-mode-remap-defaults)) > (null (cdr entry))) > (setq major-mode-remap-defaults > (delq entry major-mode-remap-defaults))) > (push (cons mode nil) major-mode-remap-defaults)))) > Can and should stay. (Btw, it is better to use assq-delete-all, > because the above removes only the instances of the first element for > each mode that it finds in the list. Btw, doing so will also avoid > the need to add the 3 entries above, AFAIU.) Can you perhaps suggest another way of protecting CC Mode's symbols in place of the patch which is to be amended/removed? > > I have proposed two ways of fixing the immediate problem, both of them > > simple, easy to review, and easy to test. You have rejected them both. > > It seems it is more important to release Emacs 30 soon that to get it > > right. > We cannot always set everything right when the release is close. What > is being proposed to fix this issue will make things a little bit > better than they were in Emacs 29, and certainly no worse. We will > need to try to find better solutions in Emacs 31. > By contrast the solutions you proposed are much more risky, as they > touch areas that are not directly related to the code which caused the > issue at hand, and because they will have a broader effect. They are > therefore inappropriate for a release branch that is in its 2nd > pretest. Why MUCH more risky? They're a little bit more risky, perhaps. In the time we've been discussing the matter, one of them could have been implemented and now be under review/test. For that matter, the amended patch you're proposing hasn't really been tested either. We know that nobody looked at it or tried it out in the 5½ months from the commit, up until when you looked at it and raised the bug. But we know this patch will have bad effects (see the rest of my posts in this thread). -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 01:31:36 2024 Received: (at 74339) by debbugs.gnu.org; 17 Nov 2024 06:31:36 +0000 Received: from localhost ([127.0.0.1]:55703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCYop-00089s-Me for submit@debbugs.gnu.org; Sun, 17 Nov 2024 01:31:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCYon-00089e-Np for 74339@debbugs.gnu.org; Sun, 17 Nov 2024 01:31:34 -0500 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 1tCYoh-0000zn-VO; Sun, 17 Nov 2024 01:31:27 -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=mGML0bVuJdBTR/AaqShmTAZ0y1fTl3dz2ELAUmSiSSg=; b=ke+SzG86SqD+ 74lO1H0dI6fRBQrIHFMlDOnRn2OKM4zWagwl15DpuvJZGenovNyljPOu5YywEZRwJn+Gm2tXR88X2 NL91wTxE4dBCGRGQ9x7N7+rOnYhzdQA6uuXMZHTCw5CTFbQR/QDdiQnPnEwxLR8CWK1FKpw6KZaCD TzOAOmLPu/Jc3nTqHWlNXOsygkH2DdMO0j2RrNIf1X3oXHD365e47iF21KSjokf4+T+3RBYeJG/7q V5Efq5keDwaLm1INsCY1ERDKbTeEKZQGlUiSrlG6jxd0Mwi1sxu3NOtOmknfasvrxE+iFDHqkJ6mn 4GZyE2FQscVc98q/71pSDA==; Date: Sun, 17 Nov 2024 08:31:25 +0200 Message-Id: <86ldxiwev6.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 16 Nov 2024 21:56:03 +0000) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <86cyiwimlr.fsf@gnu.org> <864j47iobz.fsf@gnu.org> <86ttc7f7jo.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 16 Nov 2024 21:56:03 +0000 > Cc: 74339@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > > I don't and can't agree to these changes as they're currently proposed. > > > My concerns expressed over the last few days haven't been addressed; > > > they've merely been dismissed. In effect, you're proposing just > > > reverting my patch from May, without addressing the reasons for that > > > patch. > > > No, not to revert: to amend it in relatively minor ways. > > No. Nullifying it's main purpose and leaving only a toothless hulk is > not relatively minor. The purpose of the patch was to protect CC Mode's > symbols. It had unfortunate side effects, hence this bug. What kind of protection did you have in mind, and how does the current code in cc-mode provide that protection? > > Specifically, I'm asking not to add these entries to > > major-mode-remap-defaults: > > > (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) > > (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) > > (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) > > > Instead, _remove_ them from the list (if they are in the list). The > > rest, i.e. adding the elements that "remap" c-mode to itself, viz.: > > > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > > (if (and (setq entry (assq mode major-mode-remap-defaults)) > > (null (cdr entry))) > > (setq major-mode-remap-defaults > > (delq entry major-mode-remap-defaults))) > > (push (cons mode nil) major-mode-remap-defaults)))) > > > Can and should stay. (Btw, it is better to use assq-delete-all, > > because the above removes only the instances of the first element for > > each mode that it finds in the list. Btw, doing so will also avoid > > the need to add the 3 entries above, AFAIU.) > > Can you perhaps suggest another way of protecting CC Mode's symbols in > place of the patch which is to be amended/removed? I need to understand what you mean by "protection of symbols" before I can suggest anything. > > > I have proposed two ways of fixing the immediate problem, both of them > > > simple, easy to review, and easy to test. You have rejected them both. > > > It seems it is more important to release Emacs 30 soon that to get it > > > right. > > > We cannot always set everything right when the release is close. What > > is being proposed to fix this issue will make things a little bit > > better than they were in Emacs 29, and certainly no worse. We will > > need to try to find better solutions in Emacs 31. > > > By contrast the solutions you proposed are much more risky, as they > > touch areas that are not directly related to the code which caused the > > issue at hand, and because they will have a broader effect. They are > > therefore inappropriate for a release branch that is in its 2nd > > pretest. > > Why MUCH more risky? They're a little bit more risky, perhaps. Let's agree that they are "more risky". > In the time we've been discussing the matter, one of them could have > been implemented and now be under review/test. The problem is not with the time it takes to implement a solution, the problem is with the time it will take to verify it doesn't have any unintended consequences and doesn't cause regressions elsewhere. With the changes I proposed, the probability of such adverse effects is very low, because the changes are local to the code whose effect we now understand well enough, having discussed it here so extensively. By contrast, the other proposals modify other parts of Emacs, and thus their effect is less certain. Which means they will delay the release. > For that matter, the amended patch you're proposing hasn't really been > tested either. It's a minor change in code whose effect is now understood very well. And I did test something very similar in my sessions, once I discovered the issue and understood what causes it. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 21 02:57:12 2024 Received: (at 74339-done) by debbugs.gnu.org; 21 Nov 2024 07:57:12 +0000 Received: from localhost ([127.0.0.1]:48982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tE23s-0004Ez-DT for submit@debbugs.gnu.org; Thu, 21 Nov 2024 02:57:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tE23q-0004El-PN for 74339-done@debbugs.gnu.org; Thu, 21 Nov 2024 02:57:11 -0500 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 1tE23k-0003vt-Ce; Thu, 21 Nov 2024 02:57:04 -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=6jzPYQ3+ak7LH0F5l/aq9VdEF/pIYR7HuKYTdNgbNzA=; b=U7eLDov9XjIc XD9g9GBb/lP1kSEqIre0k2ZSyg2AlVmgI/8DUsiCcdNN7qmtlZOh3nESTosL35hFEI5n8FVD8rsM6 ZGJMlix/DBiKrm6YPKdc/oIGDJRPCcFY9UiPCwH3LIoxIjpBrDqu1+ZGSBWP4+TEUhvFyI2IAomax ul81nuSRlFs372SUwZfZy3SXPtIZrAlE+CWyezVBX4FaouUslWfdMjWVlwgTMB/FnF6CmnKxHwpeH xzKsHvhwxz0JIr2rKNXzp7oIfcemnKPSPTllV1OEDhRMrtgrmpLjAYezGtyFl3MYMNywB9rGu/KRj iNBRiijPauysxav3su7FbA==; Date: Thu, 21 Nov 2024 09:57:00 +0200 Message-Id: <86r075qasz.fsf@gnu.org> From: Eli Zaretskii To: acm@muc.de, monnier@iro.umontreal.ca, Dmitry Gutov In-Reply-To: <861pzdk4aq.fsf@gnu.org> (message from Eli Zaretskii on Thu, 14 Nov 2024 21:23:41 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339-done Cc: 74339-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > Date: Thu, 14 Nov 2024 21:23:41 +0200 > From: Eli Zaretskii > > 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. 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. I've now made changes in c-ts-mode.el on the emacs-30 branch that allow to remap CC Mode's C/C++ modes to the corresponding tree-sitter based modes as result of loading c-ts-mode, which resolves this bug. (cc-mode.el remains unchanged, so loading cc-mode will revert to using CC Mode, as it did before this change. IOW, the changes I installed make it possible for users to prefer c-ts-mode if they want, and leave intact the ability of users to prefer cc-mode if that is what they want.) With that, I'm closing this bug. Dmitry, please consider a similar change in ruby-mode.el and ruby-ts-mode.el, since what we have there now is that once ruby-ts-mode is loaded, there's no way for users to go back to using ruby-mode unless they customize major-mode-remap-alist. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 21 08:58:04 2024 Received: (at 74339) by debbugs.gnu.org; 21 Nov 2024 13:58:04 +0000 Received: from localhost ([127.0.0.1]:49585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tE7h6-0003ni-HK for submit@debbugs.gnu.org; Thu, 21 Nov 2024 08:58:04 -0500 Received: from mail.muc.de ([193.149.48.3]:37548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tE7h3-0003nA-BS for 74339@debbugs.gnu.org; Thu, 21 Nov 2024 08:58:02 -0500 Received: (qmail 76799 invoked by uid 3782); 21 Nov 2024 14:57:54 +0100 Received: from muc.de (p4fe1590e.dip0.t-ipconnect.de [79.225.89.14]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 21 Nov 2024 14:57:53 +0100 Received: (qmail 19655 invoked by uid 1000); 21 Nov 2024 13:57:53 -0000 Date: Thu, 21 Nov 2024 13:57:53 +0000 To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86r075qasz.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: Dmitry Gutov , acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Thu, Nov 21, 2024 at 09:57:00 +0200, Eli Zaretskii wrote: > > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > > Date: Thu, 14 Nov 2024 21:23:41 +0200 > > From: Eli Zaretskii [ .... ] > I've now made changes in c-ts-mode.el on the emacs-30 branch that > allow to remap CC Mode's C/C++ modes to the corresponding tree-sitter > based modes as result of loading c-ts-mode, which resolves this bug. > (cc-mode.el remains unchanged, so loading cc-mode will revert to using > CC Mode, as it did before this change. IOW, the changes I installed > make it possible for users to prefer c-ts-mode if they want, and leave > intact the ability of users to prefer cc-mode if that is what they > want.) > With that, I'm closing this bug. Thanks for the info! I'm glad the bug is finally closed. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 21 14:03:08 2024 Received: (at 74339-done) by debbugs.gnu.org; 21 Nov 2024 19:03:08 +0000 Received: from localhost ([127.0.0.1]:51727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tECSJ-0001Zs-M7 for submit@debbugs.gnu.org; Thu, 21 Nov 2024 14:03:07 -0500 Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:44253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tECSH-0001ZK-B8 for 74339-done@debbugs.gnu.org; Thu, 21 Nov 2024 14:03:06 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id 3779D114016F; Thu, 21 Nov 2024 14:03:00 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Thu, 21 Nov 2024 14:03:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732215780; x=1732302180; bh=5LI9GvuFxj2RjrwtTk+pXLMCT5KHNqsdI3kwwbrAbF0=; b= brwWyWePt877qfBZUpL2iRhtlIub/xRs+faxeNd979XoGLgBnw7NeK2YndgcrdrU tkfNhx0qt5idbMrve97z85F8MjO9LaR46qFmYFb2H+OTJRuTGQ1jn8l+vwuUNpXJ nnXnPKrKT5DnS79lfP1R0WQvJRZR0Fn5hR2cEXPoejLlXQ51dlAeIhl8AxIagWUY h3vk6QZgovWy/KhiBVGP2wqxSHTmz8nXJJxq6rIzk7wAoqB0lM94/zJAG0DUa4Y2 lCEqybuzEpRViZ3SsQtWZU3Opqn0sOSrz26k3sGgTNf5v7YmF+uIcntCxTVa6EcL yRWWg8m4EFEAqBcXLjSQ4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732215780; x= 1732302180; bh=5LI9GvuFxj2RjrwtTk+pXLMCT5KHNqsdI3kwwbrAbF0=; b=F wAutLfsQ411ckzfb9YG7rFCPK+1fDfHsbEi9q8rJ6sxvwApfbq/n7mGsMXjjLw7I iyuraEHKZYSzBLh0BszFvOIOtmliFpEfZWDWZr+gZ1+xHTQl+6BwaVHOmKFSdX91 B0s7lwe8KY3/F/wUsSFVHdwFLm2Ee7f+f3kI+HLaGKzfj7DN9YgVKuITMXKIAA6a bS9u/DSTtB71ohZo2546cJnWyZ3LR3cl5hqOxbSYQRIHeX1Q8yH8l9sgPVB9pSpk FpHKw1J4JqJHnTYecwNrnvg5YKP6pR9nyf0ScAApRshRuO4n6AEuQLN12LmoTl4E fNbiA+BuYR/FdUchVBIfA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrfeeigdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh dprhgtphhtthhopegrtghmsehmuhgtrdguvgdprhgtphhtthhopehmohhnnhhivghrsehi rhhordhumhhonhhtrhgvrghlrdgtrgdprhgtphhtthhopeejgeeffeelqdguohhnvgesug gvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Nov 2024 14:02:57 -0500 (EST) Message-ID: <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> Date: Thu, 21 Nov 2024 21:02:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii , acm@muc.de, monnier@iro.umontreal.ca References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86r075qasz.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339-done Cc: 74339-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 21/11/2024 09:57, Eli Zaretskii wrote: > Dmitry, please consider a similar change in ruby-mode.el and > ruby-ts-mode.el, since what we have there now is that once > ruby-ts-mode is loaded, there's no way for users to go back to using > ruby-mode unless they customize major-mode-remap-alist. Could you please go ahead with whatever changes you think appropriate? I didn't do (or review) either of the previous changes in that area. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 21 14:51:16 2024 Received: (at 74339-done) by debbugs.gnu.org; 21 Nov 2024 19:51:16 +0000 Received: from localhost ([127.0.0.1]:51819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEDCu-0003oz-9A for submit@debbugs.gnu.org; Thu, 21 Nov 2024 14:51:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEDCq-0003oY-DY for 74339-done@debbugs.gnu.org; Thu, 21 Nov 2024 14:51:13 -0500 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 1tEDAf-0007mV-H1; Thu, 21 Nov 2024 14:48:57 -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=exhiXMBbyPWKI40GFs+jrjdGXQytpdwHd3X9Mke+JaY=; b=Hx1XtGqqlMXp ZS0EM8luvU46C3wJJtQr/GDm72pPC1o9l8KCxPXWGjB0udUPviBfv2vOKvNlEYY8lKcpJzetaXhK7 zGWx6TADmCe3tIs7eHHUZApTXpRk9VDJRWFLEZatdQWKlbzcKMmg2fwNXikRu3b6iZjwjHnaUbtVk e+nMBHivN3LJJVX85wsqjpozgorcXayB4f+dY4aDYn6fGp1fuF8BF4Nz0S+FqpblFhrEIaQT4ndtA vpdX5XhnVFY2nMqSWRKxAFzGLjO+tDsZJvdybbCQfSKh1trZmfawVmjeIEyccYGots/rwTo93DeGN iLvBk5lymFFYPQREITo3bg==; Date: Thu, 21 Nov 2024 21:48:55 +0200 Message-Id: <86zflsnza0.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> (message from Dmitry Gutov on Thu, 21 Nov 2024 21:02:55 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339-done Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Thu, 21 Nov 2024 21:02:55 +0200 > Cc: 74339-done@debbugs.gnu.org > From: Dmitry Gutov > > On 21/11/2024 09:57, Eli Zaretskii wrote: > > Dmitry, please consider a similar change in ruby-mode.el and > > ruby-ts-mode.el, since what we have there now is that once > > ruby-ts-mode is loaded, there's no way for users to go back to using > > ruby-mode unless they customize major-mode-remap-alist. > > Could you please go ahead with whatever changes you think appropriate? > > I didn't do (or review) either of the previous changes in that area. I could suggest a patch, but as I don't use Ruby modes, I'd hesitate to install it without an okay from someone who does. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 23 14:40:29 2024 Received: (at 74339) by debbugs.gnu.org; 23 Nov 2024 19:40:30 +0000 Received: from localhost ([127.0.0.1]:59210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEvzZ-0001rX-H9 for submit@debbugs.gnu.org; Sat, 23 Nov 2024 14:40:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEvzW-0001r3-RB for 74339@debbugs.gnu.org; Sat, 23 Nov 2024 14:40:27 -0500 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 1tEvzQ-00080d-MM; Sat, 23 Nov 2024 14:40:20 -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=VCTH/fc7t4mTD0bb3D+tqzfKujQ0jjEXuDNbIc8+jLo=; b=htd3SdjG8Ig9 A59DgY+ncCyCiOqcSkMhE981EqrSzxkp5nP12+XJUgPEbAAk/ylOcZLSJBEHRAJ9eEEnlWo4e3lCM c2rJ7yS26sOYSTQ15nBFS2JDnyZeR66N3amu3RiXxy4k5nkEIgYAaXFX1nWE3fzbbqDju8Tzr3vXt E2EUtmmuuBL2PbL8E1cXgEU6VSrx+Qcnvg28TINeakk3QQZZ9f77lx1bxAGlUNOm0Jg+Cva4pTwhZ bD5Hx/pHqjQy9WRnZFE/LqViqcDwG9k4SgirtzYfa3pXOscZyB+jb8J2ZgTeucToBkP7JAAbRLqgz xrGNz67MDSdeGAoY1cYhaA==; Date: Sat, 23 Nov 2024 21:40:19 +0200 Message-Id: <861pz1lows.fsf@gnu.org> From: Eli Zaretskii To: dmitry@gutov.dev, monnier@iro.umontreal.ca In-Reply-To: <86zflsnza0.fsf@gnu.org> (message from Eli Zaretskii on Thu, 21 Nov 2024 21:48:55 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339-done@debbugs.gnu.org > Date: Thu, 21 Nov 2024 21:48:55 +0200 > From: Eli Zaretskii > > > Date: Thu, 21 Nov 2024 21:02:55 +0200 > > Cc: 74339-done@debbugs.gnu.org > > From: Dmitry Gutov > > > > On 21/11/2024 09:57, Eli Zaretskii wrote: > > > Dmitry, please consider a similar change in ruby-mode.el and > > > ruby-ts-mode.el, since what we have there now is that once > > > ruby-ts-mode is loaded, there's no way for users to go back to using > > > ruby-mode unless they customize major-mode-remap-alist. > > > > Could you please go ahead with whatever changes you think appropriate? > > > > I didn't do (or review) either of the previous changes in that area. > > I could suggest a patch, but as I don't use Ruby modes, I'd hesitate > to install it without an okay from someone who does. Like the patch below. Is it okay? diff --git a/lisp/progmodes/ruby-mode.el b/lisp/progmodes/ruby-mode.el index d953ec8..903a1c5 100644 --- a/lisp/progmodes/ruby-mode.el +++ b/lisp/progmodes/ruby-mode.el @@ -2748,6 +2748,9 @@ ruby-mode (dolist (name (list "ruby" "rbx" "jruby" "j?ruby\\(?:[0-9.]+\\)")) (add-to-list 'interpreter-mode-alist (cons (purecopy name) 'ruby-mode))) +(setq major-mode-remap-defaults + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) + (provide 'ruby-mode) ;;; ruby-mode.el ends here diff --git a/lisp/progmodes/ruby-ts-mode.el b/lisp/progmodes/ruby-ts-mode.el index adcdf15..39a0d47 100644 --- a/lisp/progmodes/ruby-ts-mode.el +++ b/lisp/progmodes/ruby-ts-mode.el @@ -1237,8 +1237,10 @@ ruby-ts-mode (derived-mode-add-parents 'ruby-ts-mode '(ruby-mode)) -(if (treesit-ready-p 'ruby) - (add-to-list 'major-mode-remap-defaults +(when (treesit-ready-p 'ruby) + (setq major-mode-remap-defaults + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) + (add-to-list 'major-mode-remap-defaults '(ruby-mode . ruby-ts-mode))) (provide 'ruby-ts-mode) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 23 21:56:36 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 02:56:36 +0000 Received: from localhost ([127.0.0.1]:60173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF2nc-0006OY-8L for submit@debbugs.gnu.org; Sat, 23 Nov 2024 21:56:36 -0500 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:48271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF2nY-0006OH-Vn for 74339@debbugs.gnu.org; Sat, 23 Nov 2024 21:56:33 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id D48E313801AC; Sat, 23 Nov 2024 21:56:27 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Sat, 23 Nov 2024 21:56:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732416987; x=1732503387; bh=TNQod742/+xxh+Nrzb+ycvNR06jr9r00Fa/YSIxewRA=; b= sU7SsYNsxjQGgp2voXgCah1b75/SOygIHzbyddkR6u4Tf8MYPPjtFN5PSAm7OL2X 2kYgLe6d9GwTrrIR0k7jErQyhFmgmjj23HU2ZrhXbNNANaVtFuZ+R/Mvh93MlngO JTX/UKcN/T2JN7swP7/16pnZqOfpF3zjS0OvYtpte5Bkndrzv+sBNyN1M8HcO+ln mvAWR0q/dUHVDNlmfCipjCFRgn+zrXF8pE1o6MU6ZJqX7vs6Y/DSESN67vQr1ER9 15kBVnU4SF6v6MOLlaGYH6QFfeQ5Z21ZKvtUof+1s/bVDIUhNJIRfXuwZW/rAllm aIEQ7BmO8/LZSNzPmS6iqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732416987; x= 1732503387; bh=TNQod742/+xxh+Nrzb+ycvNR06jr9r00Fa/YSIxewRA=; b=K uR7qzG60I6WwSC8SYTG0WIRjiZsOpPB32XsMU+O2oSznin1SwKdvmqwuUHzTe4Cf rIDHwMetOod0+093g6Tn37rW02ueDsuKQDf5zLzDoc4arga+i5GNNPLulVDeYTCi /CCoss2d3hghvklLujlCs6ouA/nIxN7oAJIfHAOGSRRXXCOEKIQWkMMsRjlkGRCm FloCK+oMWtR450QuFtlI0afcdvKeRSwJT5/7L9MWHmQg28BNAaYQJPTe/d6DN0/q bscxlx6+3av8dIDILrbztXjtJCKF23UtggCk6AaVi1+XmF/Qe1omtmKkCZf/TKqZ ZsRPiamchAU3whu0z8xGQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgedvgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpd hrtghpthhtohepmhhonhhnihgvrhesihhrohdruhhmohhnthhrvggrlhdrtggrpdhrtghp thhtohepjeegfeefleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 23 Nov 2024 21:56:26 -0500 (EST) Message-ID: Date: Sun, 24 Nov 2024 04:56:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii , monnier@iro.umontreal.ca References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <861pz1lows.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 23/11/2024 21:40, Eli Zaretskii wrote: > Like the patch below. Is it okay? I think it will do what you want it to do, so okay in that sense. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 23 23:37:28 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 04:37:29 +0000 Received: from localhost ([127.0.0.1]:60293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF4NE-0002ps-DG for submit@debbugs.gnu.org; Sat, 23 Nov 2024 23:37:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF4NC-0002pe-DU for 74339@debbugs.gnu.org; Sat, 23 Nov 2024 23:37:27 -0500 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 1tF4L1-0005tk-Ju for 74339@debbugs.gnu.org; Sat, 23 Nov 2024 23:35:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=9H+IEoqHianLXZQ3Ntk7pXwM76aABjXI4KR7GDqK+gM=; b=ZBTzR5KOHCxF ScPnpdFZbGzyoN7M48uCbFDoGJXcd7ueq4GtlnVo+RHa8eme55v4DikQ48arp21nTPabMM3QonAZB E8gUPFZBiPsHNRv0dX3HP8Ntn5kHkovaHu0TRO7FFQF56CvjoL8fM7/gjaeHc7eNTuFIDrCgDutJf vZdxdESrD9xeDvpby1I4D8KI9SI1QEJQXlIFXyNfkU2QvUu9UbgFLNzgzkGAFazq68gMcRVfoxe4k t0ruhD68NTJf99MUkP8/FQGkTM9O5oeLRzgFiF8bvTvElzlhJdq9Cv8oJfEBTqJE4wxMyqiuVOfB4 sDyMGSKUswu3IBlFtxcfxA==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tF4L0-0003d0-Fd; Sat, 23 Nov 2024 23:35:11 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <86r075qasz.fsf@gnu.org> (message from Eli Zaretskii on Thu, 21 Nov 2024 09:57:00 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> Message-Id: Date: Sat, 23 Nov 2024 23:35:10 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > I've now made changes in c-ts-mode.el on the emacs-30 branch that > allow to remap CC Mode's C/C++ modes to the corresponding tree-sitter > based modes as result of loading c-ts-mode, which resolves this bug. > (cc-mode.el remains unchanged, so loading cc-mode will revert to using > CC Mode, as it did before this change. IOW, the changes I installed > make it possible for users to prefer c-ts-mode if they want, and leave > intact the ability of users to prefer cc-mode if that is what they > want.) This does help a user insist on c-mode rather than c-ts-mode. However, setting that switch by loading file A or file B is not natural. In Emacs we try to have a user option to control such a choice. How about making a user option that will be tested on every occasion whet it is time to put a buffer in one of those modes? The simplest way is to call the option `c-mode-use-tree-sitter'. I think a similar option will be needed for each major mode that has a TS counterpart. We could have an option like that for each of those major modes. Other user interfaces involving a single option to specify which modes should get tree-sitter handling can be considered. I think the goals are (1) the Customize interface should handle these options cleanly. (2) a user should be able to set this just once, and the setting will stick in future Emacs versions (unless the user explicitly changes it) as long as this aspect of Emacs doesn't fundamentally change. There could also be a command M-x major-mode-use-tree-sitter which would toggle that switch for the current major mode. So if you use that command while in a C mode buffer, it would change the value of `c-mode-use-tree-sitter'. Perhaps it would also change the major mode in each buffer that uses `c-mode' or `c-ts-mode'. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 00:28:02 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 05:28:02 +0000 Received: from localhost ([127.0.0.1]:60351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF5AA-0005Iw-9m for submit@debbugs.gnu.org; Sun, 24 Nov 2024 00:28:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF5A7-0005IC-Nf for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 00:28:00 -0500 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 1tF59z-0003Td-PT; Sun, 24 Nov 2024 00:27:51 -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=dtVMHAmyriWyGDmC6hSpkSTHCM++WFB2rPHNcwf88mc=; b=XCyizSz0DedB 349+ukPIwiRh8EqV2k3aorDUoVkKDncdbwRnOn0M5MgU0aSe6DzUSZa/6jZCKsiJTjU9yGHYr0E5F XANjklPnjDYRZEOAQiuvm7yMg2e5gC4J73Q2/QzY3tq6IEYE/k070iHcty0hAYPTy2WHplSsz/LH0 HX7UlhTnOJAiGBcf2rs2jXILJNUEHXhkCSSJUjac/orE1hR76uS277L4PBNUBUeFlseL6jj0f5KDn GxgoGvgW85lGdVBqmd9aBIj1cYoSLovZKqbg1TFqs6q1ZfFgZCGajLjdMWIvy8lDtHhVrHxO+ZCan 3RjbjG6jss/XnMTsPGyyPw==; Date: Sun, 24 Nov 2024 07:27:49 +0200 Message-Id: <86wmgtjj56.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 24 Nov 2024 04:56:24 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Sun, 24 Nov 2024 04:56:24 +0200 > Cc: 74339@debbugs.gnu.org > From: Dmitry Gutov > > On 23/11/2024 21:40, Eli Zaretskii wrote: > > Like the patch below. Is it okay? > > I think it will do what you want it to do, so okay in that sense. If you disagree with "what I want it to do", please tell. I think we should install this because it does the same as c-ts-mode does. For Emacs 30, this is what we can do. So if you are not happy with that for ruby-mode, for some reason other than the basic fact that loading packages changes things, I'd like to know that before I decide whether to install this. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 02:42:06 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 07:42:06 +0000 Received: from localhost ([127.0.0.1]:60585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF7Ft-0003o5-Kn for submit@debbugs.gnu.org; Sun, 24 Nov 2024 02:42:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF7Fr-0003nX-FQ for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 02:42:04 -0500 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 1tF7Fm-0008BX-0l for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 02:41:58 -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=24fUjqtXdBoadlfCROb7aDlmXushMp/TlDvMjrBH/4k=; b=jkMnvEOSgI5G RTnzVa1SY6U6exiuNXJ9F0rhEgXZudUDOeqDlOKFzKECRMsHuIWFz68on0rMZFuSKB5Cta9h3VcWu 8X5PMgaLP+8qkh7mx9NEumA6AI2mq1Nl6faimPyLofb3mPXF85vAodenbC3+h6COWx1mlrz8eVUZJ yByz1dk2W5sDR0i7rae9ASwyxW91Rx+XbWCknCh7qSHgzBDeTiDdKOf5LMp821CyxZP4jIoLB46KM bszdMcGjg30a8isZYfaxoSZDCuU/0aoj+QgfgNorb8mcRmUayeNGbf8M+Xo78MyeCetfnxl5C8VOS xm9fp+V4Us/1sfGIOUJXFg==; Date: Sun, 24 Nov 2024 09:41:29 +0200 Message-Id: <86ttbxjcye.fsf@gnu.org> From: Eli Zaretskii To: rms@gnu.org In-Reply-To: (message from Richard Stallman on Sat, 23 Nov 2024 23:35:10 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Cc: 74339@debbugs.gnu.org > Date: Sat, 23 Nov 2024 23:35:10 -0500 > > > I've now made changes in c-ts-mode.el on the emacs-30 branch that > > allow to remap CC Mode's C/C++ modes to the corresponding tree-sitter > > based modes as result of loading c-ts-mode, which resolves this bug. > > (cc-mode.el remains unchanged, so loading cc-mode will revert to using > > CC Mode, as it did before this change. IOW, the changes I installed > > make it possible for users to prefer c-ts-mode if they want, and leave > > intact the ability of users to prefer cc-mode if that is what they > > want.) > > This does help a user insist on c-mode rather than c-ts-mode. > However, setting that switch by loading file A or file B is not > natural. In Emacs we try to have a user option to control such a > choice. > > How about making a user option that will be tested on every occasion > whet it is time to put a buffer in one of those modes? It's more complicated than that. The situation where more than one major mode is appropriate for certain contents of a buffer is new in Emacs, we first encountered it in Emacs 29, quite close to its release. The solution took a couple of iterations, but eventually I decided that loading a mode will be the best alternative in the short term, although it has known issues. We are currently discussing the possible improvements, which include user option and more, in this thread: https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00636.html > The simplest way is to call the option `c-mode-use-tree-sitter'. I > think a similar option will be needed for each major mode that has a > TS counterpart. We could have an option like that for each of those > major modes. That is one possibility, but I'm not sure it's the best one. For example, if the user wants to prefer several such modes, calling a command for each one of them would be a nuisance. Also, having a separate command for each mode makes this harder to remember. There are also some issues regarding the implementation that we need to figure out. > Other user interfaces involving a single option to specify which > modes should get tree-sitter handling can be considered. > I think the goals are > > (1) the Customize interface should handle these options cleanly. > > (2) a user should be able to set this just once, and the setting will > stick in future Emacs versions (unless the user explicitly changes it) > as long as this aspect of Emacs doesn't fundamentally change. > > There could also be a command M-x major-mode-use-tree-sitter which > would toggle that switch for the current major mode. So if you use > that command while in a C mode buffer, it would change the value of > `c-mode-use-tree-sitter'. Perhaps it would also change the major mode > in each buffer that uses `c-mode' or `c-ts-mode'. All of this (and more) is in scope of the above discussion. I hope we will have a much better solution for this in Emacs 31. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 10:37:33 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 15:37:33 +0000 Received: from localhost ([127.0.0.1]:35691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFEg0-0004OX-S9 for submit@debbugs.gnu.org; Sun, 24 Nov 2024 10:37:33 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFEfz-0004OB-EB for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 10:37:32 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3E4F080788; Sun, 24 Nov 2024 10:37:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1732462644; bh=uBmvTtjvbTQTk6tUZ+zydUxQaHQX00620pvLsmb8XRg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aW/lV/QHYCh1HVqDId9DgJn4B7+yndok8soHaK1P+888K0htREFiqMXCMOj3qK2jF mNM1eUkXUL7e1lSrPgH3PastH7AyAUq/W5xBMWD6sU44jeqIJHl1XcpQ/kB8YrcSjw oFN8rsE3ywEnIb7AvAGqCuBixUE96VBJ2DPptnQ9bpmKGdfpYj2B7F5glOBTghU19Z sRD3RO9dLKUcRXd0Ymx9y1riHFW7qDu3gmfezudZSeYcuklfr+uU3KvFN/BHLm8OOx CGprM8+uksdk3KZ9l6ZY7yjk4UsYhUOegRAx4JEtUCXytJGZlYL1urbV+iK+Jy9HUB RF31SckmiXpTA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5EA24803A3; Sun, 24 Nov 2024 10:37:24 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2C2E31206F0; Sun, 24 Nov 2024 10:37:24 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <861pz1lows.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 Nov 2024 21:40:19 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> Date: Sun, 24 Nov 2024 10:37:23 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.020 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Like the patch below. Is it okay? [...] > +(setq major-mode-remap-defaults > + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) > + So, this adds `ruby-mode.el` and `ruby-ts-mode.el` to the list of files which break our coding convention that loading a file should not affect Emacs's behavior. I understand we decided back in Emacs-29 that it was the least bad solution to make it easy for users to use the new TS major modes, but this was back in Emacs-29. We should look for ways to remove this kind of hack rather than spreading it to more files. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 11:01:42 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 16:01:42 +0000 Received: from localhost ([127.0.0.1]:35806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFF3N-0005f0-RH for submit@debbugs.gnu.org; Sun, 24 Nov 2024 11:01:42 -0500 Received: from mout.gmx.net ([212.227.15.15]:34255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFF3J-0005ek-JK for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 11:01:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.com; s=s31663417; t=1732464085; x=1733068885; i=dimech@gmx.com; bh=AMljDza1N+ydR51+zS9PxdAipD7CDhhLsNvq5FTqEkg=; h=X-UI-Sender-Class:MIME-Version:Message-ID:From:To:Cc:Subject: Content-Type:Date:In-Reply-To:References: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=Td9g3plu3AZeMt0AMFJGkdymJNnoCfQU6V9vfljFj4Vi3Jy3OnBaP9uLs6tLEDhT ckE8+/qFMX6wVTrE1ECXDyWvyVFFWAnusTb61jxFpO6tpLhFTK7cuTcKd0o7/nPql 1bb5H5h/8GPf2ki8hjJs8y7dtkYlXQfRpfJnJ+q9ye9NddAdqN2kI9E6ySaqMTrHZ 3PoCCqWIXscUJL4ISSmNvty9qAN9rcClm3528W9I6a2jRXBMbVGP6JR3o2p9j1hrO kQVHam7dzft21hvRaLoGRkwdJSPWUCSylOXmS7Nji0Dq1ZChYK/ZSa+6taQhuExl5 DoA5njIJI+p26582CQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [77.71.252.27] ([77.71.252.27]) by web-mail.gmx.net (3c-app-mailcom-bs16.server.lan [172.19.170.184]) (via HTTP); Sun, 24 Nov 2024 17:01:25 +0100 MIME-Version: 1.0 Message-ID: From: Christopher Dimech To: monnier@iro.umontreal.ca Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode Content-Type: text/plain; charset=UTF-8 Date: Sun, 24 Nov 2024 17:01:25 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:L1fv6oysrvZ9TpP11a3eQItK4onauSZ2mHlhDtUFZaSSB80ads/QOunS24ycktlLl49zV dpgaM7B6zCr41oLFRnUWrP1JLPUd12ljJnwB4n4NcN+Gnd5RP9rLjExTMEyBVKAyAOxBTGkpYCn/ 4uy585q8IlWaokbgerueghKK7XBtguNTSN1SJcDZX2EiB+DhGDvDMN4OISHGcNbDVHTGu0IDPTpe WsvCPuHf8gDTLDPmbfe3cGZLO0L3wzMWkeAjqHwqhXXUtT1RxIrZKuLkHJrDCvGp2NbQYM9RhmEE 4c= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:DfUClKeeXMk=;EaviqDKctjuA2YrjEcbdRHVZ8/R 4DgeBOmN85VfSmQCWDxDVQu00cmTaX09HUmf5LpuelhJ22U8+B7kNV3plh2eDr2egRPhCvz2U YlDdsUWw5H5Y1pFJJ+KqiE3Rpl9FU9edSlbSRkwp/Fl98wyLGYwWRhMG1MmDZrd88Dc3RzqFX zPFlb1+68YnisXSztRdhT4XFEM5yBeSZX+VYMQKDF6Zl3H4oKZ96NX+6ezm3lpxoFvOqxOOQU 85iIaHl70R78SLUBxOHTXkAO5sQ65FEW8FfJ2AO5ZhqHHgMfd5/fVVzxZg3/VqpIXMkaiirmH Eg3y4X285EVPraUdVHWOdvXUDdao1cx9hHpt3sO7wV84CWGEbwsw7fN8I4d2/bRn+JeafJsm8 2LoQegZQVtK7x+hor4LrIPscPqEvJMCxieVhMDDFQcvKR8Nb66wgxLNMYgiiQPgmsOcTzeyoZ cKYkcDcNzUJIKQpTQzc8thyV9ii/5mJY3HZEo1Hb28jhWliniAfUqovhwjU5cMZFLgu2bO99G YwD7QIb44BPjeOUjsiqp/lfpcarPH5+Nr3SPwE518qBspXW8gCkZqqbHpcgLiImXvBCYcRTWl YUyemq7HTGgEokBOLNjYp1GckwK257I8y//KfTADaZ8A+HSQ6OzwsWrObYBbN1nl3JYuLFbJq rW3/5ZViUx+RVkXC+gtjhdg39DdW9D76DyqcaVxDuw== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, Eli Zaretskii , 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Sent: Monday, November 25, 2024 at 3:37 AM > From: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knif= e of text editors" > To: "Eli Zaretskii" > Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org > Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode > > > Like the patch below. Is it okay? > [...] > > +(setq major-mode-remap-defaults > > + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) > > + > > So, this adds `ruby-mode.el` and `ruby-ts-mode.el` to the list of files > which break our coding convention that loading a file should not affect > Emacs's behavior. > > I understand we decided back in Emacs-29 that it was the least bad > solution to make it easy for users to use the new TS major modes, but > this was back in Emacs-29. We should look for ways to remove this kind > of hack rather than spreading it to more files. > - Stefan Temporary solutions, such as hacks, must be explicitly marked as such and accompanied by plans for their eventual removal. Failure to do so perpetuates confusion among Elisp developers regarding the appropriate structures to use. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 11:28:06 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 16:28:06 +0000 Received: from localhost ([127.0.0.1]:35842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFFSv-0006uW-T1 for submit@debbugs.gnu.org; Sun, 24 Nov 2024 11:28:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFFSr-0006tw-Pk for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 11:28:04 -0500 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 1tFFSm-00019F-Fa; Sun, 24 Nov 2024 11:27:56 -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=LMCSDBD7go3mbL1Ol+sfqoWkVy3hW6LvxjgQ5ppd/iY=; b=Quo2VkPqBk2F A4/R4Wftfm5Z3OiKIOIiWs/lAiLM9wVbu/ARITjtOnpMlQaQG1DDFwucNmRoWT3BWNKja9mDpajEo iDpiU03cd4B5XXcxE43Z4PtZmLDATPFjQganjquGiUZ6WFx2FyfuOYZmXQjmwf2h/zkPcMgnna4LN j0hhLk3D4GLEik1FIEpvPB3OfDuTDNU6U+kPHDD1L7Bf3Etd+XLFJmP7SLpC+15Q7ixSoDUwzDtjV xlC5RsTU8YJT6YgMho51wt89Tcw/H+G8X2OdZhkq4lm8uQGfQXiF851rzFW8sqzyWE+2Hua2O7vox qwNCnneYBBTiKfp6HYOLLA==; Date: Sun, 24 Nov 2024 18:27:47 +0200 Message-Id: <86zfloiol8.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 24 Nov 2024 10:37:23 -0500) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > From: Stefan Monnier > Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org > Date: Sun, 24 Nov 2024 10:37:23 -0500 > > > Like the patch below. Is it okay? > [...] > > +(setq major-mode-remap-defaults > > + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) > > + > > So, this adds `ruby-mode.el` and `ruby-ts-mode.el` to the list of files > which break our coding convention that loading a file should not affect > Emacs's behavior. No, it doesn't: ruby-ts-mode already did that, due to this change: commit 2b5d43081a30f816dd38a16c7b5bfbad712a779b Author: Stefan Monnier AuthorDate: Sun Mar 3 23:08:16 2024 -0500 Commit: Stefan Monnier CommitDate: Sun Mar 3 23:58:18 2024 -0500 > I understand we decided back in Emacs-29 that it was the least bad > solution to make it easy for users to use the new TS major modes, but > this was back in Emacs-29. We should look for ways to remove this kind > of hack rather than spreading it to more files. We will do that in Emacs 31, but the change I posted was for Emacs 30, where we decided to live with that. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 11:31:04 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 16:31:05 +0000 Received: from localhost ([127.0.0.1]:35855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFFVo-000779-Jg for submit@debbugs.gnu.org; Sun, 24 Nov 2024 11:31:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFFVn-00076c-3X for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 11:31:03 -0500 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 1tFFVg-0001UH-CV; Sun, 24 Nov 2024 11:30:57 -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=GQGwOh+ZUj/7APMDU2ZUOwfw5jfr/grGiXCr4m4XB0k=; b=kgO/BSbWfvfb SuOEAjtJmhXrqJiEyFeQJ05EF74HPNmAtGir82O+jVasIQZ1Rr7XOTLCiEAO+dYId7AViXS7BVjGj 6vcB4J+W4o6b+A9gTudnrVBGc1FJzPkZIwE+MZrqxC77fgM/VAz0NJSU52Ea0UEXSYYnROKAj5doC INbjY38JSTcn7uarl/FuUHO0VZ/jHJntKn3K/OHWHtj09bTiLYc1gRExTTpKcHx+fuc/cxW0xLWIK ylj6qhghiVQ7ZDLHCrYz9YFI9BiDD9NP1fgS2j9jkB0RjHf3oxqJPlxG3Hz+/L8VrRQqcYs/7Ep7d vXtyghkUtW4EBQfFSuUSSQ==; Date: Sun, 24 Nov 2024 18:30:49 +0200 Message-Id: <86y118iog6.fsf@gnu.org> From: Eli Zaretskii To: Christopher Dimech In-Reply-To: (message from Christopher Dimech on Sun, 24 Nov 2024 17:01:25 +0100) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > From: Christopher Dimech > Cc: Eli Zaretskii , dmitry@gutov.dev, 74339@debbugs.gnu.org > Date: Sun, 24 Nov 2024 17:01:25 +0100 > Temporary solutions, such as hacks, must be explicitly marked as such > and accompanied by plans for their eventual removal. Failure to do so > perpetuates confusion among Elisp developers regarding the appropriate > structures to use. You are welcome to install any procedures and policies in the projects you are responsible for. Here, you don't get to say what must and must not be done, and I very much doubt that you have a clear idea of what confuses us. You are welcome to make suggestions, if you think we need them, but please word them as such. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 11:47:41 2024 Received: (at 74339) by debbugs.gnu.org; 24 Nov 2024 16:47:41 +0000 Received: from localhost ([127.0.0.1]:35871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFFlt-0007q9-BW for submit@debbugs.gnu.org; Sun, 24 Nov 2024 11:47:41 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFFlq-0007ps-IW for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 11:47:39 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 13DA8442BAE; Sun, 24 Nov 2024 11:47:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1732466850; bh=XlXphNw+8Msh4WZnrkQDQ/wO+BsRDFx/9EavIEEU978=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Bxg2hjJXgX5fUG2Tr+1nrxoq08vuhCQ1es9b1Qwqd05ht4ubBzrbKvHnW5iCjZEAP zswCNcwhM/ilW9e4AsGYNKLz0E4/fdiRIxAQ9VWa1JQIpEoXw2XkoslUCUwutKL7Z6 2c/1/Jbb0ap2ZHaGuQiD4CDremMpl1rGmifWCBn9suB+UVg3+Ddhv+rUN9ztVojA7I AvYKnERa7+5ia9Qn6G53NZ590ymx7V7KNcjICKZAQ4AbBwKpU1pMuq5hgDN8Ucz78k RvUl7sko+POmcKAFormJYLwniBarBue0vi/GqK//NyP+8b3c8SBqU5D1PsXLCKz9we XBlUY7m3UzKxw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 19CD1442BA2; Sun, 24 Nov 2024 11:47:30 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DDB441206CB; Sun, 24 Nov 2024 11:47:29 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode In-Reply-To: <86zfloiol8.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 24 Nov 2024 18:27:47 +0200") Message-ID: References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86zfloiol8.fsf@gnu.org> Date: Sun, 24 Nov 2024 11:47:23 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.018 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74339 Cc: dmitry@gutov.dev, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> > Like the patch below. Is it okay? >> [...] >> > +(setq major-mode-remap-defaults >> > + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) >> > + >> >> So, this adds `ruby-mode.el` and `ruby-ts-mode.el` to the list of files >> which break our coding convention that loading a file should not affect >> Emacs's behavior. > > No, it doesn't: ruby-ts-mode already did that, due to this change: Duh! Sorry 'bout the noise, Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 19:57:16 2024 Received: (at 74339) by debbugs.gnu.org; 25 Nov 2024 00:57:16 +0000 Received: from localhost ([127.0.0.1]:36570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFNPf-0005ku-MS for submit@debbugs.gnu.org; Sun, 24 Nov 2024 19:57:15 -0500 Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]:35211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFNPc-0005kb-Jm for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 19:57:14 -0500 Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id 0928111400FD; Sun, 24 Nov 2024 19:57:07 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Sun, 24 Nov 2024 19:57:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732496226; x=1732582626; bh=LfGvyhJ21uRO+d5/i93CJ3agI/l+d23PR8c9Tro29s4=; b= YCibws3z0fm2sbNUoH8Ue1V1H+kmO4vzEPbeyctC+xQALnUz68/41MY3Sc2T0L5s PM9uJJDuJe5089I2dJI7RS6lfiWksDCMegiLn1yHnr6QO011NYQ70mmaLQyh+Td+ Vdo59dboyWhJIDzmLk0D6kvNgYqO4vUBZtr5dLhMPsLZAbt410t0n0dh/9dCStuD 1d+HTnw1hMmnSkENWp4+xTKuUubBF1R+8jEMNI29KJWEoHQji3gqn4h0eCjCz+Nw T2e9YDbsp5aQYJGJGCHEcJ1Ua16wCFTzP1THfiJQid6Jh8BkbXJa0FZHHRaSEpf2 ej4b3RW2Z1ZOcXGClp/Rpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732496226; x= 1732582626; bh=LfGvyhJ21uRO+d5/i93CJ3agI/l+d23PR8c9Tro29s4=; b=1 ShU3v2z/d3RLSMTW9awqcSv7l3qcYotwJSEpvots/J7GZ35LGY6ZDFvIgREtB1YR JsBikaOwL/d5cDuyKDQzDx+8Ws87ZVDuXpDl53ehd5YthKSB8lYR8P8GJZ0axa0I WCAiBFfUuWr66Q1t4SDH1eef3EUIyH5qbIMsGM6hGV5GvrCjvgPfAjkFEH3+g67C 7HxXe1TkXzj6Mku8bCzmere1TA9dvlaQLA939B6qIjVG/+fQTYbRMDzIZ97iCUDA ddRbouZkwKRCn2yeP3ZTR5zeXSqgFJ7r1GvCL9BA/ZAdmrNiQEFUhjwx0su2Qd1z 07DowHaETdCzxJr33A/wQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgeeggddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhhonhhnihgvrhesihhrohdruh hmohhnthhrvggrlhdrtggrpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghp thhtohepjeegfeefleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 24 Nov 2024 19:57:05 -0500 (EST) Message-ID: Date: Mon, 25 Nov 2024 02:57:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Stefan Monnier , Eli Zaretskii References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86zfloiol8.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 24/11/2024 18:47, Stefan Monnier wrote: >>>> Like the patch below. Is it okay? >>> [...] >>>> +(setq major-mode-remap-defaults >>>> + (assq-delete-all 'ruby-mode major-mode-remap-defaults)) >>>> + >>> So, this adds `ruby-mode.el` and `ruby-ts-mode.el` to the list of files >>> which break our coding convention that loading a file should not affect >>> Emacs's behavior. >> No, it doesn't: ruby-ts-mode already did that, due to this change: > Duh! Sorry 'bout the noise, As far as Ruby is concerned, I believe we did that in 6b2f85caa6cae1178b8a. The later changes just altered the method with which the effects are applied. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 24 20:16:19 2024 Received: (at 74339) by debbugs.gnu.org; 25 Nov 2024 01:16:19 +0000 Received: from localhost ([127.0.0.1]:36601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFNi7-0006eK-Dr for submit@debbugs.gnu.org; Sun, 24 Nov 2024 20:16:19 -0500 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:34831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFNi5-0006e4-5N for 74339@debbugs.gnu.org; Sun, 24 Nov 2024 20:16:18 -0500 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id DAE162540144; Sun, 24 Nov 2024 20:16:11 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Sun, 24 Nov 2024 20:16:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732497371; x=1732583771; bh=+n+m/d/3CYeuy8X7ytgm27JwguwvORElQfDbr0b90WE=; b= XAAdVTFR01R41K7F3n/u0z1MKfx3BbpsU5U5S9SAwPJSKL19dCp7Zvom7rnb6W67 MjqTaCZo2ULCPS5yMwlqpig9Axyv1t19bsz9edcG/11SKOpk3BnLQ96xu57m5BEu Wx7uAUfCEj7W8iX9+mmwaWJmxxatODglkZmgowccTYQHA4zioc9MSzfvecyYZJOi epBuMSf/+kc57zvCanHPF7dFHQV8wcguxy/IiYcAUkQSrd6eG6S9oVA7K/hxEYKD 6G4tDgKXVZEdr5VaVl2ACQDJ3BlMhcq9jGj05dH6gemwkfbCVYrhcKPBTxSghmst xPyFgmhrnphEbNV5j5R76w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732497371; x= 1732583771; bh=+n+m/d/3CYeuy8X7ytgm27JwguwvORElQfDbr0b90WE=; b=S 5XclxxYc5ZpoUa1S39xme7/L0EMEmZXzflIGNQXVwY478K+Kpb7kp16LN7novdEA 6ZtZ8fUiA1z9ei0u+ufrL/eybsD3HjUKPpVsG/1zUoGMTxh/SzMEu8vStte2eHCR iDdZYmvWAxx5sFqfsqdi0ymLIce4PSthO1O3XHeNGAOiAtH2Eg6IaR7ghjEDEG2x ea+S77eyI22Xl9jalqb9SfYIugP68DkF1xZx2q5di5ono5RSO/r7oSQswGluSYi5 /8FMUs46HrMs0v3RBRC1gQwbcu75zqAo5+Bh3VmJi6RanK6NE3opbyunHqMxTdcn 0arga1rZACR5OguefUXlA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgeeggdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpd hrtghpthhtohepmhhonhhnihgvrhesihhrohdruhhmohhnthhrvggrlhdrtggrpdhrtghp thhtohepjeegfeefleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 24 Nov 2024 20:16:10 -0500 (EST) Message-ID: <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> Date: Mon, 25 Nov 2024 03:16:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86wmgtjj56.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 24/11/2024 07:27, Eli Zaretskii wrote: >> Date: Sun, 24 Nov 2024 04:56:24 +0200 >> Cc:74339@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 23/11/2024 21:40, Eli Zaretskii wrote: >>> Like the patch below. Is it okay? >> I think it will do what you want it to do, so okay in that sense. > If you disagree with "what I want it to do", please tell. I think we > should install this because it does the same as c-ts-mode does. For > Emacs 30, this is what we can do. So if you are not happy with that > for ruby-mode, for some reason other than the basic fact that loading > packages changes things, I'd like to know that before I decide whether > to install this. I'm not happy about it because it doesn't seem like an improvement overall (specifically - that we decided that the order of loading packages should affect things as well). But it doesn't seem worth arguing about right now, given the broader context. And I see where you're coming from: we didn't manage to agree on any other instrument for CC Mode to "undo" the runtime change by c-ts-mode, and since ruby-ts-mode uses the same variable, consistency asks it to follow. We're still going to land in a halfway zone, though, given that for example js-ts-mode alters auto-mode-alist, and js-mode doesn't switch it back. Same for python-ts-mode, html-ts-mode, json-ts-mode, css-ts-mode. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 25 07:11:36 2024 Received: (at 74339) by debbugs.gnu.org; 25 Nov 2024 12:11:37 +0000 Received: from localhost ([127.0.0.1]:38207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFXwG-0004JL-Fv for submit@debbugs.gnu.org; Mon, 25 Nov 2024 07:11:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFXwE-0004J7-NO for 74339@debbugs.gnu.org; Mon, 25 Nov 2024 07:11:35 -0500 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 1tFXw9-00016D-4Z; Mon, 25 Nov 2024 07:11:29 -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=WdBjZPx6VZz96ZfuH2gWhq+nbVgG1jyr+S7AYvwVLmE=; b=l7k/jETe1a5u GiKjpiXBqWftZE2FaFbGu8ZxQldOMvo+RyF2aUbbsk7OH0grIbqmTDnftJYZ6TYDFpFyo4jDsRs0x Qz3ziD9MLBQA87rJ7pvssIz4N7XKaWJl+nwtiTJJ+zDG23B7BHqyjLtBHqD08bUD8860J00wYIUhf oQku/6aSM0XnkIf5z510HvCLOGxhMCLwimjeDaZNfxm/cLHYqUxJ24bPi6IsHdmndmzOxZ8sle2il GWFoT+ZuTGPD7JTMebD6fDCOoza3xfr1wEm5dr37zGDabfr49aXHJso5XVWtpV1Gr80WJ2XzlZu52 njPiFtX4yIqFjZmMwiPzwQ==; Date: Mon, 25 Nov 2024 14:11:26 +0200 Message-Id: <86mshnikcx.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> (message from Dmitry Gutov on Mon, 25 Nov 2024 03:16:08 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Mon, 25 Nov 2024 03:16:08 +0200 > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > From: Dmitry Gutov > > On 24/11/2024 07:27, Eli Zaretskii wrote: > >> Date: Sun, 24 Nov 2024 04:56:24 +0200 > >> Cc:74339@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >> On 23/11/2024 21:40, Eli Zaretskii wrote: > >>> Like the patch below. Is it okay? > >> I think it will do what you want it to do, so okay in that sense. > > If you disagree with "what I want it to do", please tell. I think we > > should install this because it does the same as c-ts-mode does. For > > Emacs 30, this is what we can do. So if you are not happy with that > > for ruby-mode, for some reason other than the basic fact that loading > > packages changes things, I'd like to know that before I decide whether > > to install this. > > I'm not happy about it because it doesn't seem like an improvement > overall (specifically - that we decided that the order of loading > packages should affect things as well). But it doesn't seem worth > arguing about right now, given the broader context. > > And I see where you're coming from: we didn't manage to agree on any > other instrument for CC Mode to "undo" the runtime change by c-ts-mode, > and since ruby-ts-mode uses the same variable, consistency asks it to > follow. It's not consistency, it's the need to let users go from one preference to another multiple times during the same session, and in a documented way. > We're still going to land in a halfway zone, though, given that for > example js-ts-mode alters auto-mode-alist, and js-mode doesn't switch it > back. Same for python-ts-mode, html-ts-mode, json-ts-mode, css-ts-mode. Agreed. But there loading cannot solve the problem to begin with. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 25 18:40:34 2024 Received: (at 74339) by debbugs.gnu.org; 25 Nov 2024 23:40:34 +0000 Received: from localhost ([127.0.0.1]:43083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFih0-000401-6u for submit@debbugs.gnu.org; Mon, 25 Nov 2024 18:40:34 -0500 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]:38173) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFigy-0003zi-7S for 74339@debbugs.gnu.org; Mon, 25 Nov 2024 18:40:32 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id 1C8C4114019F; Mon, 25 Nov 2024 18:40:27 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Mon, 25 Nov 2024 18:40:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732578027; x=1732664427; bh=XzJ7d+n9K6qnq0OuXeiCchAPBsADsjp2KCp6ncp8toc=; b= Ir8MvcpG39SjTxVZRGtiuP0Ex0zwgiQGEkh4RAOpvzrMaOoN5TAAlJQ6uEiIo8vV VIOZExZt3U1dnvszlyns/sYjJxXukVjdVNhCTAaILEkOVXeVE9VOU8gCoAxXBCO/ FOg1AajWyL3e2V+tXx2l3BINlU7dl2Uk6FudX4xSrIm4ECaGX0kMzvTqAUwou78O UZwEHylHXftT96XIG+LgcfzJe2Ilb1z5walH27D3vcWsSPvsefnZOVhOlmGGpsmu WiOjixCG9hmJkZ0b7Ciw3BDUZka1qEKOPvELeuYlnnqQNSvKfUGEmwvLVZhUfr2x eKCCJhpUdbDq2fluhsSdCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732578027; x= 1732664427; bh=XzJ7d+n9K6qnq0OuXeiCchAPBsADsjp2KCp6ncp8toc=; b=x DLUOIGR3kBryiUvmeNFSwxd3Vw2rRYH368Pf0P980CVVfkBGLRNUrW8ympkT60dP iVU6MRX5kb6ESH+KsJti3BraqF1WLAjS4XdzZ5GD+rGVBnH/ipmPWipYkptGS4+p xQPLuzjNv9Fu4l6bS8HYnkgD3fImUPSbXiJXOWM33OBV2mzwH2bPIfP5SMhONKTU yFwpJKvk1+VkzV51Mx2LyPFcs3aXd3rHNgC10o42ZTxWEt4nrG1VhRXhfKeusD+g q8si39tR7urKdV2KLipkEPES2XT6sZYe9xto88aPPG9wVycWAkVj8NtXc0aQ7LUt xp109+XlrF86NPHiVu7cw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgeeigdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpd hrtghpthhtohepmhhonhhnihgvrhesihhrohdruhhmohhnthhrvggrlhdrtggrpdhrtghp thhtohepjeegfeefleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Nov 2024 18:40:25 -0500 (EST) Message-ID: <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> Date: Tue, 26 Nov 2024 01:40:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> <86mshnikcx.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86mshnikcx.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 25/11/2024 14:11, Eli Zaretskii wrote: > It's not consistency, it's the need to let users go from one > preference to another multiple times during the same session, and in a > documented way. Okay. If we're going to document this though, could we make an explicit note that it's a temporary solution? I.e. it's likely to stop working in the next Emacs release. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 26 09:26:52 2024 Received: (at 74339) by debbugs.gnu.org; 26 Nov 2024 14:26:52 +0000 Received: from localhost ([127.0.0.1]:48276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFwWh-0004yG-Sz for submit@debbugs.gnu.org; Tue, 26 Nov 2024 09:26:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFwWf-0004y4-Kg for 74339@debbugs.gnu.org; Tue, 26 Nov 2024 09:26:50 -0500 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 1tFwWZ-0001tw-La; Tue, 26 Nov 2024 09:26:43 -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=qYpKWipbFgpIoz++gYQUSUouS1myx1vgCkVOLRTPMAE=; b=SjUadz1kQpHD zChSOqd6qzwiq+P+tIiQHoW8n/S7qNjNxpxVUgmFqdcwxF+B8feouTWvSKutoJ6w8yOdSHtAU4Bom TbHPQIxJ3Bf9Srd/aD3NytGJrHFzPQuguffSiN9Ri/VuKHindukMtLC+5OYma5x0dkN8lh4dpDKDS NClKWWAA4YYCqZ6kODSBU6wLhlLCx9swovGRKYL0PoAbVpkY2Veau0zKpvbxUvkJyv1wVIkPzqq+1 RcZlBBwv1TClkQSp4tUMcTXL0Gx+oX+m+TJQm8s9YkB900PwDOucIeBJnPtUP9NsYt8wYDTXipbMT oU1geSReD8NtWtG5iSffWg==; Date: Tue, 26 Nov 2024 16:26:40 +0200 Message-Id: <86mshmgjfj.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> (message from Dmitry Gutov on Tue, 26 Nov 2024 01:40:22 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> <86mshnikcx.fsf@gnu.org> <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Tue, 26 Nov 2024 01:40:22 +0200 > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > From: Dmitry Gutov > > On 25/11/2024 14:11, Eli Zaretskii wrote: > > It's not consistency, it's the need to let users go from one > > preference to another multiple times during the same session, and in a > > documented way. > > Okay. If we're going to document this though, could we make an explicit > note that it's a temporary solution? I.e. it's likely to stop working in > the next Emacs release. This is somewhat problematic, since we have no good place for such "temporary" documentation. What we did instead is that Emacs 30 suggests to use major-mode-remap-alist as the first, and in most places the only, way of preferring the tree-sitter based modes. Both NEWS and the user manual mention only this method. So the support for changing the preference by loading a file is already not advertised except in the commentary to c-ts-mode.el etc. It is basically kept for users who remember doing that in Emacs 29. Is that good enough? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 26 17:06:56 2024 Received: (at 74339) by debbugs.gnu.org; 26 Nov 2024 22:06:56 +0000 Received: from localhost ([127.0.0.1]:54630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG3hv-0003kS-U8 for submit@debbugs.gnu.org; Tue, 26 Nov 2024 17:06:56 -0500 Received: from fhigh-b3-smtp.messagingengine.com ([202.12.124.154]:44225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG3hv-0003kF-5n for 74339@debbugs.gnu.org; Tue, 26 Nov 2024 17:06:55 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.stl.internal (Postfix) with ESMTP id F2EB12540144; Tue, 26 Nov 2024 17:06:48 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Tue, 26 Nov 2024 17:06:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732658808; x=1732745208; bh=zUqjxsAKizc/zpnXHTMuS0ATkpUzvHH+vLxbQmFnl3M=; b= IEhyUpiyUxhBaYrnzUJq4mbRXAGyKBx7n1MwkRaJusP/77qp3KK3g71paZiK67+D nVn5x+d+g2l0KKV6pP+o8TJ8nyllFUIgy3e6X+uKnlWHTWQwBuSPWJMAUsv2vcYQ IpTq7jvG7mYqiqdajSJcC/yA/oTv4fh6ptQeTU5rfBsooVy6CeuhK2/ruNseC/OA n8wJfZXN9l0aDekHZgvr6CP0IOLYNGsy2lrvOq+kiEd0R3df+KUZ6blm477zWMnY 3hAkAd6k4Q8LbsXxSH66RcQkOlU9b5V+bp3nwSTqMnNFACLjLGrq19BDPU8raIBn 0EL/vZNx8N9wJbrdfv3zXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732658808; x= 1732745208; bh=zUqjxsAKizc/zpnXHTMuS0ATkpUzvHH+vLxbQmFnl3M=; b=F uSZt0rNAFghLlh7/3kJ5xn0/6v1AlLhz6Ily7RYlgPLzfBb9mYsgY5t6gBxGZhRj DAQ4GMXXCQ6xn7xltSYMs5ZM4mom4siUL2nVloWvAur05BoZjhsE6UZEXAsfNLSa ZpMMK6qm7SOSco8DNCj1cRuiOlNCVqHETwtu4mK98aFbBGN/fgusBI9FyZIlcxKa 4ZmSLX424ze0+wqdSej7S/liXmo19CYFRCgqB5gwEolTQB1IIYC3Ei6Z4t6JAp5J x406O7wZvboVg/5djCvI55dt2WPF+2CEuSF2sEC+CEQB9fQamwHFteh5ZmRhsrJO Zo5YoJEgri7kfU7C+imkw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgeejgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh dprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrgdprhgt phhtthhopeejgeeffeelseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Nov 2024 17:06:46 -0500 (EST) Message-ID: <626c7114-9024-4272-903f-835342ad4844@gutov.dev> Date: Wed, 27 Nov 2024 00:06:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> <86mshnikcx.fsf@gnu.org> <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> <86mshmgjfj.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86mshmgjfj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 26/11/2024 16:26, Eli Zaretskii wrote: >> Okay. If we're going to document this though, could we make an explicit >> note that it's a temporary solution? I.e. it's likely to stop working in >> the next Emacs release. > This is somewhat problematic, since we have no good place for such > "temporary" documentation. What we did instead is that Emacs 30 > suggests to use major-mode-remap-alist as the first, and in most > places the only, way of preferring the tree-sitter based modes. Both > NEWS and the user manual mention only this method. > > So the support for changing the preference by loading a file is > already not advertised except in the commentary to c-ts-mode.el etc. > It is basically kept for users who remember doing that in Emacs 29. > > Is that good enough? Sure, that seems good to me. As long as we're not beholden to keep supporting is later. Not sure if this means that your proposed change to ruby-mode should likewise include some text for Commentary. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 26 22:30:38 2024 Received: (at 74339) by debbugs.gnu.org; 27 Nov 2024 03:30:38 +0000 Received: from localhost ([127.0.0.1]:56664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG8lB-0002Xv-MH for submit@debbugs.gnu.org; Tue, 26 Nov 2024 22:30:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tG8l9-0002Xc-92 for 74339@debbugs.gnu.org; Tue, 26 Nov 2024 22:30:36 -0500 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 1tG8iu-00056i-Bx; Tue, 26 Nov 2024 22:28:16 -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=8tYs2T4h8EafVnDFrOgZwallgE0x22uDhgXAzKTnMd4=; b=asohacaa5XdY 2lnqDJ0FhHCZHx26xB2n5W9RHyOwtL4ms/UV906N3R75MObNKyyra6HQ4gveHZlqdpDKZH4/W42ZL +cJhOaIZOKjtZ/90f3gwwRC/tmj+D6dThOGXtwPh4I/QPCiLWxUV+sHqCc2IZvjNoiqGmyOt/r647 bAQ9Hy27fYsTPapu8A3QutBX0avK6tDRADERlCFWxl3pDNybsJaZ9TMTSS99LAWSuFUWhksSUUgPH 0Y7zfdkGVtKkWC+zMT48qUnTJ5TtVMEBtBI25FuI77VXuAsY6/qi3PpwmBgna6R1rzIt4T+jtwSew zFG2kfVIol5vqr5LB7pT3g==; Date: Wed, 27 Nov 2024 05:28:12 +0200 Message-Id: <86wmgpfj8z.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <626c7114-9024-4272-903f-835342ad4844@gutov.dev> (message from Dmitry Gutov on Wed, 27 Nov 2024 00:06:44 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> <86mshnikcx.fsf@gnu.org> <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> <86mshmgjfj.fsf@gnu.org> <626c7114-9024-4272-903f-835342ad4844@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Wed, 27 Nov 2024 00:06:44 +0200 > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > From: Dmitry Gutov > > On 26/11/2024 16:26, Eli Zaretskii wrote: > >> Okay. If we're going to document this though, could we make an explicit > >> note that it's a temporary solution? I.e. it's likely to stop working in > >> the next Emacs release. > > This is somewhat problematic, since we have no good place for such > > "temporary" documentation. What we did instead is that Emacs 30 > > suggests to use major-mode-remap-alist as the first, and in most > > places the only, way of preferring the tree-sitter based modes. Both > > NEWS and the user manual mention only this method. > > > > So the support for changing the preference by loading a file is > > already not advertised except in the commentary to c-ts-mode.el etc. > > It is basically kept for users who remember doing that in Emacs 29. > > > > Is that good enough? > > Sure, that seems good to me. As long as we're not beholden to keep > supporting is later. > > Not sure if this means that your proposed change to ruby-mode should > likewise include some text for Commentary. I can add such text there. Is it okay to install those changes with that text added? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 27 07:34:42 2024 Received: (at 74339) by debbugs.gnu.org; 27 Nov 2024 12:34:42 +0000 Received: from localhost ([127.0.0.1]:60899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGHFi-0003VD-8y for submit@debbugs.gnu.org; Wed, 27 Nov 2024 07:34:42 -0500 Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]:53335) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGHFg-0003Uu-2I for 74339@debbugs.gnu.org; Wed, 27 Nov 2024 07:34:40 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.stl.internal (Postfix) with ESMTP id C5152254014E; Wed, 27 Nov 2024 07:34:34 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Wed, 27 Nov 2024 07:34:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732710874; x=1732797274; bh=eJq6/HuQMvDedy9ExwqRcP11XqaygzGaq1DPUN8Ek1Q=; b= oDC9oP0ULtbrX8cDg+29RTNiwPWTJpkmbfwyxT3e9Bub0ZDNRMwS1lwsDpKcBTA+ MrQ03ggTztG+IJL51kF1I6oD6UdRCY059/3bDoRJ2nvoyA3CpWoeh5Wv5SHgv0vZ wWW24RLyZUW5PzzD++Vi9dxM3m90jZE0Y0ORhxjvz1zFD4yiw1kZ9IJpydD2XV/r jXf3OlxF43intNkpDasF7RJ2PZi1Qvz9/FpHzueanthwCbyHPDAFAQ9ROGcnJAax sksHdhJ3z1X/P/kKbQFBp/G4KWjjFoQdQidOputur/rIlkrpDythD2lbKY3ooWJt KvlPw6LniCh2b3Oa81noNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732710874; x= 1732797274; bh=eJq6/HuQMvDedy9ExwqRcP11XqaygzGaq1DPUN8Ek1Q=; b=w +J7Qp3Kop12uk1xoYPFRJFtTpSo32oYtrSRNZK9zIVIpjEzqPFiEQJeN2gp+BjEV 915JUW8uZoTbkgRNmQIcMlkAg0EAq6l7KYXiUaArjeFwkR04hB3OKPDk8jPva/3F mbsMU/Fs2DtpfaiLrg6A9CQBuph8qUd8HyP5LW6YROVZdyE9iO4GtAEkkiVGSI5c sidtOrlfUq2KupGe/kLIPCV/JRZxX1j7uGZtRmytPRpIm2Xz58pFfLGQ5LsG6fAI n1VWbbQ01cKtY5tkFZQIFDQ+kXX3oBoyepUrIl/Habqac6y1addRh83m2OfXSK+x b/34XnIeeJwwqajm0kNOw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrgeelgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpd hrtghpthhtohepmhhonhhnihgvrhesihhrohdruhhmohhnthhrvggrlhdrtggrpdhrtghp thhtohepjeegfeefleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Nov 2024 07:34:32 -0500 (EST) Message-ID: <4d69e638-72e1-4bdb-865f-1db2013a872d@gutov.dev> Date: Wed, 27 Nov 2024 14:34:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode To: Eli Zaretskii References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> <86mshnikcx.fsf@gnu.org> <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> <86mshmgjfj.fsf@gnu.org> <626c7114-9024-4272-903f-835342ad4844@gutov.dev> <86wmgpfj8z.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86wmgpfj8z.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 27/11/2024 05:28, Eli Zaretskii wrote: >> Sure, that seems good to me. As long as we're not beholden to keep >> supporting is later. >> >> Not sure if this means that your proposed change to ruby-mode should >> likewise include some text for Commentary. > I can add such text there. Is it okay to install those changes with > that text added? Please go ahead. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 28 09:59:40 2024 Received: (at 74339) by debbugs.gnu.org; 28 Nov 2024 14:59:41 +0000 Received: from localhost ([127.0.0.1]:39297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGfzY-0006YP-HH for submit@debbugs.gnu.org; Thu, 28 Nov 2024 09:59:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGfzW-0006Y9-MC for 74339@debbugs.gnu.org; Thu, 28 Nov 2024 09:59:39 -0500 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 1tGfxH-0002N1-8l; Thu, 28 Nov 2024 09:57:20 -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=htnqI51XBX1yrEaQ/92GKT5kklhG01Z9wGShS6GwSxg=; b=lGG10MKgPiLl D101C4dEUZfNAk51exsrKHurPsQZIzXq5Odt4qzS328ylYcdt1B0IN1/hT4fwzXgwMJegzAj6dH68 cpSq+NJynAK8Y8xaERhEpNUmWa4cZsquZ+6PWBaSxWx+H88PDh6ZAuNCCJ0nhB28qT/Sf7XoWZKt1 Q3gnJeWc/7AKHG4yrKD9a5flKhew+QUZ+CCZcLDdXZ26/y3FlAmxNeOsRTqojUAhpozWXCS0XMfuM pSTPVMJ4Sj70K9AlHNDGla91YTFovAeZtQPLKaMw7JoJUTOylXXDfRXkM/Cs+xSmp1M+iCYyBse0X PJWcc1P3hPTALdCOy94Gkw==; Date: Thu, 28 Nov 2024 16:56:33 +0200 Message-Id: <86serbcspq.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <4d69e638-72e1-4bdb-865f-1db2013a872d@gutov.dev> (message from Dmitry Gutov on Wed, 27 Nov 2024 14:34:30 +0200) Subject: Re: bug#74339: 30.0.92; CC Mode stomps C TS Mode References: <868qtnfd2d.fsf@gnu.org> <86r07elwoh.fsf@gnu.org> <86h68al2qz.fsf@gnu.org> <867c95kaye.fsf@gnu.org> <861pzdk4aq.fsf@gnu.org> <86r075qasz.fsf@gnu.org> <7d4a925a-3960-4412-bdb3-4f752407e00a@gutov.dev> <86zflsnza0.fsf@gnu.org> <861pz1lows.fsf@gnu.org> <86wmgtjj56.fsf@gnu.org> <2f886c4b-d8a1-46b8-bdf3-35f2e9a2949e@gutov.dev> <86mshnikcx.fsf@gnu.org> <162f21b0-9ae6-468d-bd0e-6f20742e67dd@gutov.dev> <86mshmgjfj.fsf@gnu.org> <626c7114-9024-4272-903f-835342ad4844@gutov.dev> <86wmgpfj8z.fsf@gnu.org> <4d69e638-72e1-4bdb-865f-1db2013a872d@gutov.dev> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74339 Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Wed, 27 Nov 2024 14:34:30 +0200 > Cc: monnier@iro.umontreal.ca, 74339@debbugs.gnu.org > From: Dmitry Gutov > > On 27/11/2024 05:28, Eli Zaretskii wrote: > >> Sure, that seems good to me. As long as we're not beholden to keep > >> supporting is later. > >> > >> Not sure if this means that your proposed change to ruby-mode should > >> likewise include some text for Commentary. > > I can add such text there. Is it okay to install those changes with > > that text added? > > Please go ahead. Done, thanks. From unknown Tue Aug 19 01:58:26 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 27 Dec 2024 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator