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

[Spencer Baugh]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 22/05/2023 22:49, Spencer Baugh wrote:
>> And actually, the mention of VC makes
>> me realize: We already do something expensive by default for every new
>> buffer: Query the VC state.  So maybe it's not so bad to run
>> project-current every time we make a new buffer?  Or at least, in the
>> exact same situations that we query the VC state?  Maybe we can even
>> implement some sharing between the project-current lookup and the VC
>> state query, for the vc project backend?
>
> The VC project backend is not the only backend out there. Others'
> performance characteristics may well be different.
>
> Further, its root-finding logic is different from VC. We also cannot
> simply see which backend the current file is registered at because
> project-vc has different options which affect how the root is
> determined.
>
> Long story short, we won't be able to simply reuse VC's cached info.

I assume you've already considered this thoroughly, but could we just
get rid of all those differences/merge them into vc?  For example, I
wonder if we could teach vc to have an option like
project-vc-merge-submodules...  or at least, teach vc to discover the
parent project.  That could maybe be useful in vc...

>> (I personally agree that this should be always on, with perhaps a user
> option to turn it off.)
>
> I'm fairly sure not everybody will like the additional delay when
> visiting files over Tramp.

We could simply not run it automatically for files on TRAMP.  Do we run
the vc find-file hook for files on TRAMP?  Maybe we shouldn't...