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#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode Date: Thu, 14 Nov 2024 08:35:26 +0200 Message-ID: <86ldxml3v5.fsf@gnu.org> References: <86servkkdr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30035"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74349@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 14 07:38:28 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 1tBTUp-0007el-9L for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Nov 2024 07:38:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tBTUT-0007Pa-3r; Thu, 14 Nov 2024 01:38:05 -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 1tBTUR-0007PQ-7y for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2024 01:38: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 1tBTUQ-00089k-UG for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2024 01:38: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=K3lk8v/EKV5qegEeLy5nOiAW60xfxCuX/gUJ66Ws0EE=; b=QjLhrr9n+kcusrB5D+1rr3BfIQOBr5Msz5DwMsSYXbIngHKV5o4NGcktLmRu1cx7UHuxMh8Dub6jD3K+NMBIc+GAj5ax5at7C/H0fHS1PIbgzbLYvkfb9gSsZr5kUxv2qimSnQFvNsjUzhFKUPNlbjSUVxOVCsmr81xl69MP0UjEEoWwGG1AgaXZAutAlqBWl832nVRi05hyDOxpeM0RQ181O8wgFIDHU9P+eUZSzv3Fx5WeqB6Lgo2Q2cSRMGYQCjh4tLsMWdnbTxxNuFZm2W79euH8x8OzTMeKL1eGhmS0bVyh7291u9XyHkyu6SvA1pIX10gPggNpUgNKEitEcQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tBTUQ-000460-Fz for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2024 01:38: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: Thu, 14 Nov 2024 06:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74349 X-GNU-PR-Package: emacs Original-Received: via spool by 74349-submit@debbugs.gnu.org id=B74349.173156626915722 (code B ref 74349); Thu, 14 Nov 2024 06:38:02 +0000 Original-Received: (at 74349) by debbugs.gnu.org; 14 Nov 2024 06:37:49 +0000 Original-Received: from localhost ([127.0.0.1]:44671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBTUC-00045V-DC for submit@debbugs.gnu.org; Thu, 14 Nov 2024 01:37:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBTU9-00045H-FU for 74349@debbugs.gnu.org; Thu, 14 Nov 2024 01:37:46 -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 1tBTRx-0007VN-2u; Thu, 14 Nov 2024 01:35: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=K3lk8v/EKV5qegEeLy5nOiAW60xfxCuX/gUJ66Ws0EE=; b=ltFbAUxqEPi6 XCwvB4jMqIB+qOwaAIesaIm7hznTBWXolpLXLTOCACMAEhIJRuU+AowFF3M8anI/0lWpTKQxuF1pC eyroUyqGxgWmPKW7L3dT41cSzHyYwC2Pt3YwGqrTAy87RS1x6YNYjkVaMHCHkUzz8V7+30T5x+oUm xI5KgUy2gsksZGU/t2t+S5qWcLZ4aYID88hkEF1OAupiK3rzaMmOcX/b1cqiIjIl69C6i2iB9VZdn xu7g4mnxZod1p2R8prGEbkZYFb7XmnV3OsBPSYVJvkqSILFyubVOq/Unyq4uZugcx6Z3w/pXutgHf eopJzLuWLXzdkLFT8y2g9A==; In-Reply-To: (message from Stefan Monnier on Wed, 13 Nov 2024 15:42:21 -0500) 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:295302 Archived-At: > From: Stefan Monnier > Cc: 74349@debbugs.gnu.org > Date: Wed, 13 Nov 2024 15:42:21 -0500 > > > So the C file was correctly visited using c-ts-mode, but cc-mode was > > still loaded, quite unexpectedly. > > Could you clarify why you think it's a problem? cc-mode is large; loading it brings in many other cc-* files, which basically in this scenario are just ballast. In the native-compilation case, this means loading quite a few additional *.eln files which are not really used. It's not "economical", and looks unclean to me. There's also the issue of the adverse consequences of loading cc-mode discussed in bug#74339. I hope those will be solved soon, but their current existence was the motivation for me to examine each and every reason for loading cc-mode when I didn't expect that to happen. > > Moreover, the settings in our .dir-locals.el that are defined for > > c-mode were applied to the buffer which is not under c-mode. > > Could you similarly clarify why you think it's a problem? It was unexpected, that's all. > > . hack-dir-local-variables 'funcall's the mode symbol when > > processing directory-local variables for that mode > > It doesn't "funcall" it, but it does make sure the function is loaded: > > ;; If KEY is an extra parent it may remain not loaded > ;; (hence with some of its mode-specific vars missing their > ;; `safe-local-variable' property), leading to spurious > ;; prompts about unsafe vars (bug#68246). > (if (and (symbolp key) (autoloadp (indirect-function key))) > (ignore-errors (autoload-do-load (indirect-function key)))) > > > I didn't expect derived-mode-add-parents to cause c-mode be turned on, > > It's not turned on: its file loaded. Why does it need to be loaded in this case? Is there some technical reason to do so in order to perform the settings of the variables defined by that mode? Or is this just an artifact of the implementation of hack-dir-local-variables, and thus could be avoided? > > and its directory-local settings be applied, when c-ts-mode is > > used to visit a file. > > Looks like you forgot about it, but yes, that was discussed explicitly > when we discussed `derived-mode-add-parents`. We decided back then that > the extra var-settings will likely be harmless. I guess I did forget. But the main issue for me here is that cc-mode is loaded, not that the variables are defined. > > Can this be avoided, please? Users who want to use c-ts-mode for C > > files will not necessarily be happy to have cc-mode and all its > > dependencies loaded, and the c-mode-related settings applied, just > > because of unrelated c-mode settings in .dir-locals.el. It bloats the > > memory footprint of Emacs for no good reason, > > Maybe we could try and add more tests in the above code before deciding > to `autoload-do-load`. E.g. we could first check the list of variables > being set and if they all already have a `safe-local-variable` property, > then we don't need to autoload the mode (and then we'd have to make sure > CC-mode's `safe-local-variable` settings are all autoloaded). If that could be done, I think it would be a good thing, yes. > > and it modifies variables the user didn't mean to touch. > > We don't really know that without reading the user's mind, in the > general case. Maybe the `c-mode` settings set only things like > `indent-tabs-mode` and `require-final-newline` and the users definitely > want them to apply to any mode used for the C files rather than only for > the `cc-c-mode`. Right, I see the logic of setting the variables now.