From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 14:24:09 2024 Received: (at submit) by debbugs.gnu.org; 13 Nov 2024 19:24:09 +0000 Received: from localhost ([127.0.0.1]:43677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBIyG-0006xV-Cy for submit@debbugs.gnu.org; Wed, 13 Nov 2024 14:24:09 -0500 Received: from lists.gnu.org ([209.51.188.17]:48962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBIyD-0006xN-Hk for submit@debbugs.gnu.org; Wed, 13 Nov 2024 14:24:06 -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 1tBIyB-0001y4-NP for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 14:24: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 1tBIyB-0000um-Fe for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2024 14:24:03 -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=Sexlf8+CtZOrV55c7GmhIAL0fyHgxpd0aPQwyDjMvsg=; b=VwPOZu0Bf9mGRW KAO0kJ9JFlXEZK6yJl8epdNCVmZFoARaEiDsEOWbdGzI24mnnH0spqpy/UpXlScW0mnPIGijcwACb ViyaDwBi6uRa5Mpxt6DrGkjjpwIfR3baJurgjbZcOtnMpT8X2ER/G1dlboRdWTN5n+1xsXLqSaony vkgjXQJOM2P7+JB6rrjLaEtMz3n6Qi8noxVZDVlfo32aBjuMGdKM5nCRvAuC/VKqCLnZy4oMYAVXX CJ30E4cMD/nlKGMPTGUip2l4Ov58fvGD4Il4jEhcW6Mi8+VWQhJ3n1TUVYXyz1mpMfmkei7z5xtR1 mB6qDanSMz3+mFdicFqg==; Date: Wed, 13 Nov 2024 21:24:00 +0200 Message-Id: <86servkkdr.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 30.0.92; Visiting a file under c-ts-mode loads cc-mode X-Debbugs-Cc: Stefan Monnier 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-: (featurep 'cc-mode) RET => nil M-x load-library RET c-ts-mode RET M-: (featurep 'cc-mode) RET => nil C-x C-f src/dispnew.c RET M-: major-mode RET => c-ts-mode M-: (featurep 'cc-mode) RET => t M-: c-noise-macro-names RET => ("INLINE" "NO_INLINE" "ATTRIBUTE_NO_SANITIZE_UNDEFINED" "UNINIT" "CALLBACK" "ALIGN_STACK" "ATTRIBUTE_MALLOC" "ATTRIBUTE_DEALLOC_FREE" "ANDROID_EXPORT" "TEST_STATIC" "INLINE_HEADER_BEGIN" "INLINE_HEADER_END") So the C file was correctly visited using c-ts-mode, but cc-mode was still loaded, quite unexpectedly. 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. AFAICT, this happens because of three factors: . Loading c-ts-mode evaluates this: (derived-mode-add-parents 'c-ts-mode '(c-mode)) . We have in our .dir-locals.el settings for c-mode: (c-mode . ((c-file-style . "GNU") (c-noise-macro-names . ("INLINE" "NO_INLINE" "ATTRIBUTE_NO_SANITIZE_UNDEFINED" "UNINIT" "CALLBACK" "ALIGN_STACK" "ATTRIBUTE_MALLOC" "ATTRIBUTE_DEALLOC_FREE" "ANDROID_EXPORT" "TEST_STATIC" "INLINE_HEADER_BEGIN" "INLINE_HEADER_END")) (electric-quote-comment . nil) (electric-quote-string . nil) (indent-tabs-mode . t) (mode . bug-reference-prog))) . hack-dir-local-variables 'funcall's the mode symbol when processing directory-local variables for that mode A C and Lisp backtrace showing that cc-mode was loaded as side effect of processing .dir-locals.el is shown below. I could understand why a mode is funcall'ed when it is being turned on, but I didn't expect derived-mode-add-parents to cause c-mode be turned on, and its directory-local settings be applied, when c-ts-mode is used to visit a file. That's at least unexpected, and arguably a bug. 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, and it modifies variables the user didn't mean to touch. Here's the backtrace. I obtained it by setting a breakpoint in Fload and waiting for cc-mode to be loaded. (gdb) break Fload Breakpoint 3 at 0x84b569: file lread.c, line 1326. (gdb) commands Type commands for breakpoint(s) 3, one per line. End with a line saying just "end". >pp file >end (gdb) c Continuing. Thread 1 hit Breakpoint 3, Fload (file=XIL(0x80000000094bf9d8), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1326 1326 file_stream stream UNINIT; "cc-mode" (gdb) bt #0 Fload (file=XIL(0x80000000094bf9d8), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1326 #1 0x0084d064 in save_match_data_load (file=XIL(0x80000000094bf9d8), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1783 #2 0x007fcf6d in load_with_autoload_queue (file=XIL(0x80000000094bf9d8), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at eval.c:2382 #3 0x007fd29b in Fautoload_do_load (fundef=XIL(0xc0000000094bf998), funname=XIL(0), macro_only=XIL(0)) at eval.c:2428 #4 0x007fff77 in funcall_subr (subr=0xe5d100 , numargs=1, args=0xa0916b8) at eval.c:3165 #5 0x0086d77d in exec_byte_code (fun=XIL(0xa0000000094c03a8), args_template=513, nargs=1, args=0xa091768) at bytecode.c:812 #6 0x008007f3 in funcall_lambda (fun=XIL(0xa00000000df14188), nargs=1, arg_vector=0xa091560) at eval.c:3252 #7 0x007ff8b9 in funcall_general (fun=XIL(0xa00000000df14188), numargs=1, args=0xa091560) at eval.c:3044 #8 0x007ffbe2 in Ffuncall (nargs=2, args=0xa091558) at eval.c:3093 #9 0x007fef39 in run_hook_wrapped_funcall (nargs=2, args=0xa091558) at eval.c:2872 #10 0x007ff2f2 in run_hook_with_args (nargs=2, args=0xa091558, funcall=0x7feef1 ) at eval.c:2953 #11 0x007fef88 in Frun_hook_wrapped (nargs=2, args=0xa091558) at eval.c:2887 #12 0x0080038b in funcall_subr (subr=0xe5d2c0 , numargs=2, args=0xa091558) at eval.c:3184 #13 0x0086d77d in exec_byte_code (fun=XIL(0xa000000009bc4278), args_template=769, nargs=1, args=0xa091560) at bytecode.c:812 #14 0x008007f3 in funcall_lambda (fun=XIL(0xa000000009556de8), nargs=2, arg_vector=0x607e9f0) at eval.c:3252 #15 0x007ff8b9 in funcall_general (fun=XIL(0xa000000009556de8), numargs=2, args=0x607e9f0) at eval.c:3044 #16 0x007ffbe2 in Ffuncall (nargs=3, args=0x607e9e8) at eval.c:3093 #17 0x007f099a in Ffuncall_interactively (nargs=3, args=0x607e9e8) at callint.c:250 #18 0x0080038b in funcall_subr (subr=0xe5c840 , numargs=3, args=0x607e9e8) at eval.c:3184 #19 0x007ff852 in funcall_general (fun=XIL(0xa000000000e5c840), numargs=3, args=0x607e9e8) at eval.c:3040 #20 0x007ffbe2 in Ffuncall (nargs=4, args=0x607e9e0) at eval.c:3093 #21 0x007fed45 in Fapply (nargs=3, args=0x607ebf8) at eval.c:2765 #22 0x007f0fea in Fcall_interactively (function=XIL(0x85c18c8), record_flag=XIL(0), keys=XIL(0xa00000000b9f6798)) at callint.c:342 #23 0x007fff77 in funcall_subr (subr=0xe5c880 , numargs=3, args=0xa091078) at eval.c:3165 #24 0x0086d77d in exec_byte_code (fun=XIL(0xa000000009bc6ba0), args_template=1025, nargs=1, args=0x607f7a0) at bytecode.c:812 #25 0x008007f3 in funcall_lambda (fun=XIL(0xa000000009bc6ba0), nargs=1, arg_vector=0x607f798) at eval.c:3252 #26 0x007ff8b9 in funcall_general (fun=XIL(0xa000000009bc6ba0), numargs=1, args=0x607f798) at eval.c:3044 #27 0x007ffbe2 in Ffuncall (nargs=2, args=0x607f790) at eval.c:3093 #28 0x00705721 in command_loop_1 () at keyboard.c:1550 #29 0x007fa8d1 in internal_condition_case (bfun=0x704b31 , handlers=XIL(0x90), hfun=0x703b8a ) at eval.c:1613 #30 0x00704596 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1168 #31 0x007f9956 in internal_catch (tag=XIL(0x12720), func=0x70455f , arg=XIL(0x90)) at eval.c:1292 #32 0x00704501 in command_loop () at keyboard.c:1146 #33 0x007035ea in recursive_edit_1 () at keyboard.c:754 #34 0x00703888 in Frecursive_edit () at keyboard.c:837 #35 0x006fe9a9 in main (argc=2, argv=0x7b225f8) at emacs.c:2635 Lisp Backtrace: "autoload-do-load" (0xa0916b8) "dir-locals-collect-variables" (0xa091630) "hack-dir-local--get-variables" (0xa0915c0) 0xdf14188 PVEC_CLOSURE "run-hook-wrapped" (0xa091558) "hack-dir-local-variables" (0xa0914d8) "hack-local-variables" (0xa091490) "run-mode-hooks" (0xa091448) "c-ts-mode" (0xa0913f8) "set-auto-mode-0" (0xa0913a8) "set-auto-mode--apply-alist" (0xa091328) "set-auto-mode" (0xa0912d0) "normal-mode" (0xa091280) "after-find-file" (0xa091220) "find-file-noselect-1" (0xa091190) "find-file-noselect" (0xa091108) "find-file" (0x607e9f0) "funcall-interactively" (0x607e9e8) "call-interactively" (0xa091078) "command-execute" (0x607f798) In GNU Emacs 30.0.92 (build 22, i686-pc-mingw32) of 2024-11-13 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: ELisp/l Minor modes in effect: bug-reference-prog-mode: t 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 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 epg rfc6068 epg-config gnus-util 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 cl-extra shortdoc text-property-search comp-common rx derived help-fns radix-tree help-mode vc-git diff-mode track-changes easy-mmode vc-dispatcher bug-reference byte-opt gv bytecomp byte-compile cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-seq 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 103247 13845) (symbols 48 10527 0) (strings 16 31840 3566) (string-bytes 1 855779) (vectors 16 16474) (vector-slots 8 171529 10546) (floats 8 88 4) (intervals 40 673 162) (buffers 896 13)) From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 15:42:36 2024 Received: (at 74349) by debbugs.gnu.org; 13 Nov 2024 20:42:36 +0000 Received: from localhost ([127.0.0.1]:43825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKCB-0002As-OU for submit@debbugs.gnu.org; Wed, 13 Nov 2024 15:42:36 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBKC7-0002AH-DR for 74349@debbugs.gnu.org; Wed, 13 Nov 2024 15:42:31 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8C113100126; Wed, 13 Nov 2024 15:42:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731530544; bh=wolRTQH7UbOlt2zFP3AhE1QArv8CuN6JKCtN6KGIiNA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=j7/ZQVhP/3BKNp3b9EjQYPQb2bjKadYCAuSXvp8ndi0jSWxvPgXnyLOOySALcuatT Wq5omSlT0cJpqqLq2k51pm0aj9EnzDSLaKsOAkt9ZhBut2mptq3fAhq5wIhuB5Q9Jd arnsqQ6tTiwyOuP7j8GH7gokG/gwE6wzk735+4mozIgS5Pk7CXMrUHnG2c+kx2Gttj SMhQpuqKrJCzLxAo4DOEd2yiQBPljbNXjUeJMpV8w79X+y4wk1iqo4u81tYg/tOVoR bLVbNMJAEjtLazFNuAAty78MRL7DindSHe3vtkacecsfYU7Y9aqlHBn8d/VILeQ2Ke xkzsOjCgVVXhg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8909A100042; Wed, 13 Nov 2024 15:42:24 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 75E381204D5; Wed, 13 Nov 2024 15:42:24 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode In-Reply-To: <86servkkdr.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Nov 2024 21:24:00 +0200") Message-ID: References: <86servkkdr.fsf@gnu.org> Date: Wed, 13 Nov 2024 15:42: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.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: 74349 Cc: 74349@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 (---) > 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? > 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? > . 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. > 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. > 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). > 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`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 01:37:48 2024 Received: (at 74349) by debbugs.gnu.org; 14 Nov 2024 06:37:49 +0000 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 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 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==; Date: Thu, 14 Nov 2024 08:35:26 +0200 Message-Id: <86ldxml3v5.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 13 Nov 2024 15:42:21 -0500) Subject: Re: bug#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode References: <86servkkdr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74349 Cc: 74349@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: 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 11:21:58 2024 Received: (at 74349) by debbugs.gnu.org; 14 Nov 2024 16:21:58 +0000 Received: from localhost ([127.0.0.1]:46896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBcbW-0007Gm-4N for submit@debbugs.gnu.org; Thu, 14 Nov 2024 11:21:58 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42055) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tBcbU-0007GT-Vc for 74349@debbugs.gnu.org; Thu, 14 Nov 2024 11:21:57 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BC932100180; Thu, 14 Nov 2024 11:21:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731601309; bh=Eb8MXpOJ5jYox7erQnPljrwjj9u+ngPIwy3d3ZqDNrA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RiOYm9cHkthKhWcT0i3+T1eJ//kln3vWFiMgoIhwchM3AynbXjp9ViHeELxwW+HAZ eyPiYqSSIHf02C9WiGTv12Ck0MsnDlcHqm4cSo1McIPKj9fXOQK6tdsfFT891FcHxa ONVTFltPrVe8yubnmBGSOhhNzPE6cP8uGvHcLsKeD9csHEz2bc99Jhu5gRXwJ0xLTR M7OrXTgVPTM+e4bEHbhT2NkU3V9qWLwqjBsdZEYxCQl+lh31um9DIi1eJWreE6z7BH 878oMixlIpwI1XVd50Hui48vHPwA6p38lkvPxA0HL9vRHJr5wYc1EKQn8YE+3NE/Vp rbe7VCqsvJhtQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AF853100043; Thu, 14 Nov 2024 11:21:49 -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 93D2D1201A9; Thu, 14 Nov 2024 11:21:49 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode In-Reply-To: <86ldxml3v5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2024 08:35:26 +0200") Message-ID: References: <86servkkdr.fsf@gnu.org> <86ldxml3v5.fsf@gnu.org> Date: Thu, 14 Nov 2024 11:21: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.239 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: 74349 Cc: 74349@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 (---) >> Could you clarify why you think it's a problem? > cc-mode is large; loading it brings in many other cc-* files, which That's indeed an inconvenient, but we usually consider it minor (several modes seem happy to (require 'cc-mode) just to use one or two variables from it such as syntax-tables). > There's also the issue of the adverse consequences of loading cc-mode > discussed in bug#74339. Right, that's a self-inflicted problem because we did not follow our own recommendation that loading a file should not affect the behavior of Emacs. > 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. Fair enough. >> 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? As the comment explains: we load the mode to try and avoid spuriously querying the user about "unsafe" settings. > Is there some technical reason to do so in order to perform the > settings of the variables defined by that mode? Not to set the variable, but to check whether the setting is safe: If your `.dir-locals.el` sets a variable FOO which is defined as `safe-local-variable` in BASEMODE (e.g. `c-mode`) but you actually use DERIVEDMODE (e.g. `c-ts-mode`) for that file and DERIVEDMODE does not load BASEMODE, then we may have to load BASEMODE to discover that the setting is safe. The patch below should implement the refinement I suggested, where we (auto)load BASENAME only in the case one of the vars doesn't yet have a `safe-local-variable` property. BTW, I notice that CC-mode's settings of `safe-local-variable` aren't all autoloaded: % grep safe-local lisp/progmodes/cc*.el lisp/progmodes/cc-vars.el:;;;###autoload(put 'c-basic-offset 'safe-local-variable 'integerp) lisp/progmodes/cc-vars.el:(put 'c-syntactic-indentation 'safe-local-variable 'booleanp) lisp/progmodes/cc-vars.el:(put 'c-syntactic-indentation-in-macros 'safe-local-variable 'booleanp) lisp/progmodes/cc-vars.el:;;;###autoload(put 'c-backslash-column 'safe-local-variable 'integerp) lisp/progmodes/cc-vars.el:;;;###autoload (put 'c-font-lock-extra-types 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:;;;###autoload (put 'c++-font-lock-extra-types 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:;;;###autoload (put 'objc-font-lock-extra-types 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:;;;###autoload (put 'java-font-lock-extra-types 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:;;;###autoload (put 'idl-font-lock-extra-types 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:;;;###autoload (put 'pike-font-lock-extra-types 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:(put 'c-noise-macro-names 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:(put 'c-noise-macro-with-parens-names 'safe-local-variable #'c-string-list-p) lisp/progmodes/cc-vars.el:(put 'c-macro-names-with-semicolon 'safe-local-variable lisp/progmodes/cc-vars.el:;;;###autoload(put 'c-file-style 'safe-local-variable 'string-or-null-p) % Alan, I assume this "inconsistency" is accidental (I "fixed" it in the patch below). Stefan diff --git a/lisp/files.el b/lisp/files.el index bffdaa288a5..1bc2372eeec 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -4484,6 +4484,21 @@ dir-locals-collect-mode-variables ;; Need a new cons in case we setcdr later. (push (cons variable value) variables))))) +(defun dir-locals--load-mode-if-needed (key alist) + ;; 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). + (when (and (symbolp key) (autoloadp (indirect-function key))) + (let ((unsafe nil)) + (pcase-dolist (`(,var . ,_val) alist) + (unless (or (memq var '(mode eval)) + (get var 'safe-local-variable)) + (setq unsafe t))) + (when unsafe + (ignore-errors + (autoload-do-load (indirect-function key))))))) + (defun dir-locals-collect-variables (class-variables root variables &optional predicate) "Collect entries from CLASS-VARIABLES into VARIABLES. @@ -4514,15 +4514,9 @@ (funcall predicate key) (or (not key) (derived-mode-p key))) - ;; 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)))) (let* ((alist (cdr entry)) (subdirs (assq 'subdirs alist))) - (if (or (not subdirs) + (when (or (not subdirs) (progn (setq alist (remq subdirs alist)) (cdr-safe subdirs)) @@ -4531,6 +4525,7 @@ ;; variables apply to this directory and N levels ;; below it (0 == nil). (equal root (expand-file-name default-directory))) + (dir-locals--load-mode-if-needed key alist) (setq variables (dir-locals-collect-mode-variables alist variables)))))))) (error diff --git a/lisp/progmodes/cc-vars.el b/lisp/progmodes/cc-vars.el index f0e4c957ea5..305e324747d 100644 --- a/lisp/progmodes/cc-vars.el +++ b/lisp/progmodes/cc-vars.el @@ -530,7 +530,7 @@ c-syntactic-indentation :type 'boolean :group 'c) (make-variable-buffer-local 'c-syntactic-indentation) -(put 'c-syntactic-indentation 'safe-local-variable 'booleanp) +;;;###autoload(put 'c-syntactic-indentation 'safe-local-variable #'booleanp) (defcustom c-syntactic-indentation-in-macros t "Enable syntactic analysis inside macros. @@ -550,7 +550,7 @@ c-syntactic-indentation-in-macros :type 'boolean :group 'c) -(put 'c-syntactic-indentation-in-macros 'safe-local-variable 'booleanp) +;;;###autoload(put 'c-syntactic-indentation-in-macros 'safe-local-variable #'booleanp) (defcustom c-defun-tactic 'go-outward "Whether functions are recognized inside, e.g., a class. @@ -1732,7 +1732,7 @@ c-noise-macro-names :version "26.1" :type '(repeat :tag "List of names" string) :group 'c) -(put 'c-noise-macro-names 'safe-local-variable #'c-string-list-p) +;;;###autoload(put 'c-noise-macro-names 'safe-local-variable #'c-string-list-p) (make-variable-buffer-local 'c-noise-macro-names) (defcustom c-noise-macro-with-parens-names nil @@ -1749,7 +1749,7 @@ c-noise-macro-with-parens-names :version "26.1" :type '(repeat :tag "List of names (possibly empty)" string) :group 'c) -(put 'c-noise-macro-with-parens-names 'safe-local-variable #'c-string-list-p) +;;;###autoload(put 'c-noise-macro-with-parens-names 'safe-local-variable #'c-string-list-p) (make-variable-buffer-local 'c-noise-macro-with-parens-names) (defun c-make-noise-macro-regexps () @@ -1798,8 +1798,7 @@ c-macro-names-with-semicolon `c-make-macros-with-semi-re' to set the necessary internal variables.") (make-variable-buffer-local 'c-macro-names-with-semicolon) -(put 'c-macro-names-with-semicolon 'safe-local-variable - #'c-string-or-string-list-p) +;;;###autoload(put 'c-macro-names-with-semicolon 'safe-local-variable #'c-string-or-string-list-p) (defun c-make-macro-with-semi-re () ;; Convert `c-macro-names-with-semicolon' into the regexp From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 23 07:32:38 2024 Received: (at 74349) by debbugs.gnu.org; 23 Nov 2024 12:32:39 +0000 Received: from localhost ([127.0.0.1]:57035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEpJW-0004LS-Az for submit@debbugs.gnu.org; Sat, 23 Nov 2024 07:32:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEpJU-0004LD-D2 for 74349@debbugs.gnu.org; Sat, 23 Nov 2024 07:32: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 1tEpJO-0007Sl-EJ; Sat, 23 Nov 2024 07:32:30 -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=SOsnH+sp+TREqTpUUwON+PjCdFF1G1oeuCwI4HdvvoU=; b=b9ZlyQ6znCBC JWe/D5ZJUHnAdPlFuSHAqz+kr/i47VeKKWwz0teHpliC19pwM68+FJ/44g/VBoIvrdguZDdle1HYd RUPGUuf991F1WRtJP9+4g9D+w7XCr21EzoOvOS/5dSzZkjNoNHCSzV3kSA7u5FVNVthWELI+xqC2P vgNIda5UO4WvhSog3QcCEp4EqI2sqTftKsqao3I3idJywMKeGvgD1mMPTgrAyvc4xVZnpkz/KCdZg Qi+BDA8NFumBsVhsXfPoS7qdVd/sEMnc/IOwbvm1pSbm4sC0PrCIBDXxL0+BIXDC8/heZnJBn50ia 9pyK1V5yB210tkrxhYX7fg==; Date: Sat, 23 Nov 2024 14:32:14 +0200 Message-Id: <861pz2m8q9.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 14 Nov 2024 11:21:49 -0500) Subject: Re: bug#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode References: <86servkkdr.fsf@gnu.org> <86ldxml3v5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74349 Cc: 74349@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: 74349@debbugs.gnu.org > From: Stefan Monnier > Date: Thu, 14 Nov 2024 11:21:49 -0500 > > >> Could you clarify why you think it's a problem? > > cc-mode is large; loading it brings in many other cc-* files, which > > That's indeed an inconvenient, but we usually consider it minor (several > modes seem happy to (require 'cc-mode) just to use one or two > variables from it such as syntax-tables). > > > There's also the issue of the adverse consequences of loading cc-mode > > discussed in bug#74339. > > Right, that's a self-inflicted problem because we did not follow our own > recommendation that loading a file should not affect the behavior > of Emacs. > > > 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. > > Fair enough. > > >> 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? > > As the comment explains: we load the mode to try and avoid spuriously > querying the user about "unsafe" settings. > > > Is there some technical reason to do so in order to perform the > > settings of the variables defined by that mode? > > Not to set the variable, but to check whether the setting is safe: If > your `.dir-locals.el` sets a variable FOO which is defined as > `safe-local-variable` in BASEMODE (e.g. `c-mode`) but you actually use > DERIVEDMODE (e.g. `c-ts-mode`) for that file and DERIVEDMODE does not > load BASEMODE, then we may have to load BASEMODE to discover that the > setting is safe. > > The patch below should implement the refinement I suggested, where we > (auto)load BASENAME only in the case one of the vars doesn't yet have > a `safe-local-variable` property. I think you should install this on master, thanks. > BTW, I notice that CC-mode's settings of `safe-local-variable` aren't > all autoloaded: > > % grep safe-local lisp/progmodes/cc*.el > lisp/progmodes/cc-vars.el:;;;###autoload(put 'c-basic-offset 'safe-local-variable 'integerp) > lisp/progmodes/cc-vars.el:(put 'c-syntactic-indentation 'safe-local-variable 'booleanp) > lisp/progmodes/cc-vars.el:(put 'c-syntactic-indentation-in-macros 'safe-local-variable 'booleanp) > lisp/progmodes/cc-vars.el:;;;###autoload(put 'c-backslash-column 'safe-local-variable 'integerp) > lisp/progmodes/cc-vars.el:;;;###autoload (put 'c-font-lock-extra-types 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:;;;###autoload (put 'c++-font-lock-extra-types 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:;;;###autoload (put 'objc-font-lock-extra-types 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:;;;###autoload (put 'java-font-lock-extra-types 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:;;;###autoload (put 'idl-font-lock-extra-types 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:;;;###autoload (put 'pike-font-lock-extra-types 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:(put 'c-noise-macro-names 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:(put 'c-noise-macro-with-parens-names 'safe-local-variable #'c-string-list-p) > lisp/progmodes/cc-vars.el:(put 'c-macro-names-with-semicolon 'safe-local-variable > lisp/progmodes/cc-vars.el:;;;###autoload(put 'c-file-style 'safe-local-variable 'string-or-null-p) > % > > Alan, I assume this "inconsistency" is accidental (I "fixed" it in the > patch below). Alan, any comments? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 23 22:13:29 2024 Received: (at 74349) by debbugs.gnu.org; 24 Nov 2024 03:13:29 +0000 Received: from localhost ([127.0.0.1]:60196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF33x-0007BB-1X for submit@debbugs.gnu.org; Sat, 23 Nov 2024 22:13:29 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57061) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tF33v-0007At-9j for 74349@debbugs.gnu.org; Sat, 23 Nov 2024 22:13:27 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CF9EF1001D9; Sat, 23 Nov 2024 22:13:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1732418000; bh=ebYg04mQoXxEBd0wavnL+lb5ln0lmV9HjSHaN3qBd48=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=c3pMJWvKSdTRuvnK77P3ExmRob+ZtJMVTZ6S+067iCOXjZUPxC2OIJh1jBA3fMlNx QSvHLK/ONe7WAl2YHWx1PTGG2PsJrUYrXkOLMv0Z5K4cWVFzn43kUlrRKU6cCbG0L6 1W5IaulL7z0o4ohAr84Wu/+1hK1leXhkJA+rXSwHGqRgDItQZ2hVBrQOVW62ymCeEs Xf8YUm0txKF8WrRHlKEDuJKNSYvO+Nmn1SOLSBx5uuzQxo4A4G4m6G7LpeAyL5gOAV i1SlA+yUNdSiKk7B7e0R7azzSw5y5gI5Bey78/FZGIH7csIP9OL3NXAE9ufPLf2KXZ cyltx34z9ngfw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 32DE5100134; Sat, 23 Nov 2024 22:13:20 -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 03C9C1206CB; Sat, 23 Nov 2024 22:13:19 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode In-Reply-To: <861pz2m8q9.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 Nov 2024 14:32:14 +0200") Message-ID: References: <86servkkdr.fsf@gnu.org> <86ldxml3v5.fsf@gnu.org> <861pz2m8q9.fsf@gnu.org> Date: Sat, 23 Nov 2024 22:13:19 -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.012 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: 74349 Cc: 74349@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 (---) >> The patch below should implement the refinement I suggested, where we >> (auto)load BASENAME only in the case one of the vars doesn't yet have >> a `safe-local-variable` property. > > I think you should install this on master, thanks. Done, thanks. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 07 07:20:16 2024 Received: (at 74349-done) by debbugs.gnu.org; 7 Dec 2024 12:20:16 +0000 Received: from localhost ([127.0.0.1]:45678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJtnE-0001Xe-78 for submit@debbugs.gnu.org; Sat, 07 Dec 2024 07:20:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJtnC-0001Uf-KL for 74349-done@debbugs.gnu.org; Sat, 07 Dec 2024 07:20: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 1tJtn6-0000qJ-Du; Sat, 07 Dec 2024 07:20:08 -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=/nODwn3WIj8IMkIewd7+IMmP/ekayS0f1QPvHlF4Cdo=; b=goFcNRn2RpBV fJ3sJEgarCgXPiXONkmthxq/NKJSeDuJQG9pBEy/KtWzudT4zkmJHdZZNTgjW1cQ2WusAlHHf0WC6 c3y/D/bZGGbdQaDzkiUskkC+Z0dFuUMC7qiwA5t7GlLE6rqXZvLo4QGod+v7N5TFAavHBeK9xMH8B iV6lhGWKCnNOJPR7UThJsFD/NjeKpD4y0HrVKXemxWZPBAyFOkg/HwwXcQrq5lu5fCIlUVljFzqGU AI0YPVXu42gT4PSMuTgrN79GJKSAfS2enIjGZZLuDtg+kCx/L/xMHIwgXvxr4a4T07QNlprsVUE/i gbL+r7SYi3C0x36SJKlhIg==; Date: Sat, 07 Dec 2024 14:20:05 +0200 Message-Id: <864j3fk7m2.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 23 Nov 2024 22:13:19 -0500) Subject: Re: bug#74349: 30.0.92; Visiting a file under c-ts-mode loads cc-mode References: <86servkkdr.fsf@gnu.org> <86ldxml3v5.fsf@gnu.org> <861pz2m8q9.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74349-done Cc: 74349-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 (---) > From: Stefan Monnier > Cc: 74349@debbugs.gnu.org > Date: Sat, 23 Nov 2024 22:13:19 -0500 > > >> The patch below should implement the refinement I suggested, where we > >> (auto)load BASENAME only in the case one of the vars doesn't yet have > >> a `safe-local-variable` property. > > > > I think you should install this on master, thanks. > > Done, thanks. No further comments, so I'm now closing this bug. From unknown Fri Sep 19 17:09:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 04 Jan 2025 12:24:08 +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