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

[Dmitry Gutov <dmitry@gutov.dev>]

On 25/05/2023 21:41, Juri Linkov wrote:
>>>> -(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)))
>>> Thanks, I confirm this uses project-vc-name from dir-locals in non-file
>>> buffers.
>> If you had a chance to verify that the performance is good enough (for
>> using the result in the mode-line), that would be great.
>>
>> Either way...
>>
>>>>> ;;;###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.
>>> With this patch the problem is solved.  I can push it to emacs-29.
>> ...this patch LGTM too. Please go ahead and install it, or even both
>> patches.
> I pushed ###autoload to emacs-29.

Thanks!

> But not sure about your patch
> since currently I have no idea how to verify its performance.
> Maybe it should be pushed to master so that everyone can test it?

I think the performance requirements for 'project-name' are currently 
rather modest: the name is only used when selecting the project (in a 
custom config) and when generating some buffer names. For that, the new 
logic should be fine.

With your feature, however, project-name could be called during 
redisplay, and that might require better performance. So I thought you 
would test it together with the patch for your feature request.

But I suppose if you're not working on it right this moment, I could 
push the patch to emacs-29, and then we could refine the performance (if 
necessary) on master.