From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode Date: Sat, 16 Nov 2024 18:17:08 +0000 Message-ID: References: <86wmh5hrya.fsf@gnu.org> <86cyiwimlr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29375"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , 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 19:18:23 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 1tCNNG-0007UA-Vb for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Nov 2024 19:18:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tCNMy-0003nv-LT; Sat, 16 Nov 2024 13:18:04 -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 1tCNMx-0003nW-Bj for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 13:18: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 1tCNMw-0001y5-SQ for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 13:18:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=NjiZ/YSDPdXQa/RaPRPjQ0FsFCkBfS6NTOELYqt1Sg8=; b=GXiE///PK7FOyojQMsJONyzZ0yVfq+mGGMV6y+a3ENvgiJAPXKVPPQx0pF8Oy/DNaJ5uwldoHogAgbT1MwoXqBeiqkrEhL8sAw4kWqkdu4y8B6raBwI5pKGwpp9TZoRnvmU1GFKotmfLJ1V88CeEa2LUVMU7xyZVTAjQqgXxuygOjFlqqyMl2hjRYP92ZokHhKHCA1W6f9GlJjwfbfv9OSRoW+3xnkCVJOBrUuzVkhFxpRGECb265ne3IZpSoWxRSUFPtS3bFgpIqztHwlUnzRsSPJxj6r46iYyoYUx0hGAiszBrHKmFhuhxT/4MMb/f/Ghz0QawxcwQ7n7G7OgZLA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tCNMw-0008Ew-IJ for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 13:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 18:18: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.173178103831607 (code B ref 74339); Sat, 16 Nov 2024 18:18:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 16 Nov 2024 18:17:18 +0000 Original-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 Original-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 Original-Received: (qmail 47415 invoked by uid 3782); 16 Nov 2024 19:17:09 +0100 Original-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 Original-Received: (qmail 11369 invoked by uid 1000); 16 Nov 2024 18:17:08 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295480 Archived-At: 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).