GNU bug report logs - #63469
29.0.90; project.el doesn't add menu-bar entries

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Fri, 12 May 2023 17:49:02 UTC

Severity: normal

Found in version 29.0.90

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: sbaugh <at> janestreet.com, Eli Zaretskii <eliz <at> gnu.org>, 63469 <at> debbugs.gnu.org
Subject: bug#63469: 29.0.90; project.el doesn't add menu-bar entries
Date: Thu, 25 May 2023 04:14:41 +0300
On 24/05/2023 09:29, Juri Linkov wrote:
>>>> Maybe in .dir-locals.el.  Actually this works:
>>>>
>>>>     ((nil . ((project-vc-name . "emacs-29"))))
>>>>
>>>> Not sure why non-VC projects can't be named the same way.
>>> And indeed this is a real problem: in file buffers there is
>>> one project name that comes from project-vc-name, and in
>>> non-file buffers another project name deduced from dirs.
>>
>> Are you saying that non-file buffers don't obey the value of
>> project-vc-name set in parent dir's dir-locals.el?
> 
> Exactly.  I see no way to set the same project name both for
> non-file and file buffers.

Please try the patch below. It might have non-negligible effect on 
performance though. Please try and report back.

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 7c51778d5d4..1494665d565 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -816,8 +816,8 @@ project-buffers
         (push buf bufs)))
     (nreverse bufs)))

-(cl-defmethod project-name ((_project (head vc)))
-  (or project-vc-name
+(cl-defmethod project-name ((project (head vc)))
+  (or (project--value-in-dir 'project-vc-name (project-root project))
       (cl-call-next-method)))

>>> This distinction became visible while testing project-mode
>>> on the mode-line.
>>>
>>>> Also noticed that project-vc-name is not marked as safe,
>>>> so always asks a confirmation.
>>> This problem exists only until project.el is loaded.
>>> So maybe the 'safe' cookie should be in ###autoload.
>>
>> Possibly. Would that mean that all :safe attribute assignments should be
>> moved outside of defcustom forms, though?
>>
>> There is a whole bunch of them in project.el alone, most of them are
>> expected to be settable from .dir-locals.el (that's the only point of this
>> attribute).
> 
> I tried out other defcustoms, and indeed all they require confirmation:
> project-vc-ignores, project-vc-merge-submodules,
> project-vc-include-untracked, project-vc-name,
> project-vc-extra-root-markers, project-kill-buffers-display-buffer-list.
> 
> The standard solution is just to use e.g.:
> 
> ;;;###autoload(put 'compilation-directory 'safe-local-variable 'stringp)

Huh, so the attribute :safe only makes proper sense for preloaded 
packages and autoloaded defcustom forms (which are discouraged anyway).

Do you want to write a patch for all those vars in project.el? It will 
probably make sense to push it to emacs-29.




This bug report was last modified 2 years and 43 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.