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

[Dmitry Gutov]

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.