From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode Date: Sat, 16 Nov 2024 13:45:45 +0200 Message-ID: <86o72fh05y.fsf@gnu.org> References: <86zfm1in2p.fsf@gnu.org> <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17728"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, monnier@iro.umontreal.ca, 74339@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 16 12:46:25 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tCHFv-0004US-Qh for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Nov 2024 12:46:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tCHFd-0006YF-5b; Sat, 16 Nov 2024 06:46:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tCHFb-0006Xq-38 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 06:46:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tCHFa-0000Rc-Dl for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 06:46:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=7wZyTrhILSnd9sUuHU/O3+a6QWQqEHoFnvXvCZcUm48=; b=IpgFF5vABlcXnpYxXM+pU5wKOoj+PcpeO/rmPzKyKaxTL0YC5dAtcqUQSIRbZXPEyBoB175qwfgWx/Q63+8l3txEUUz+A45hfFDIv23cLnt4/KALtsweYpvk2yhftrBRfsWPZAXqioegX4G1h0oXNjXjQrZwZCWjxeNAYqdbIdZkgwPPqpjn+mu6mGLVtpuMd8ko1VNxYmpobeg4mEJaCViTxh+2rRB5REYr++0BH2aYn1d/AnyncZf+NPT6OpPdZ7tOJdfRMLtjYzvtQQx++S2r3caOFId9fo/lOy1dz4imBgagtHTrOq1VdddlRAsXeg5gOql+nU7n7YLaN3EGLg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tCHFa-0006Vl-2d for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 06:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 11:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74339 X-GNU-PR-Package: emacs Original-Received: via spool by 74339-submit@debbugs.gnu.org id=B74339.173175755925019 (code B ref 74339); Sat, 16 Nov 2024 11:46:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 11:45:59 +0000 Original-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 Original-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 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 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==; In-Reply-To: (message from Stefan Kangas on Fri, 15 Nov 2024 19:22:47 -0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295447 Archived-At: > 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.