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

Previous Next

Full log

Message #107 received at 63469 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>,
 63469 <at> debbugs.gnu.org
Subject: Re: bug#63469: 29.0.90; project.el doesn't add menu-bar entries
Date: Tue, 23 May 2023 00:30:00 +0300

On 23/05/2023 00:20, Spencer Baugh wrote:

>> 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 haven't spent much time on that question, to be honest.

But offhand I could say that those options won't necessarily make sense 
for VC. What would it mean for it to "discover parent project"?

VC doesn't deal with projects, it deals with repositories. And altering 
what repository root it finds (or making the logic customizable) can 
have adverse effects. E.g. we have an option like 
project-vc-merge-submodules which moves the project root to the top 
repository. But as far as VC goes, it needs to be able to check in 
changes inside submodules. One of the steps in vc-git-checkin is to 
change default-directory to the return value of vc-git-root, to have the 
command called there.

Similarly, I'm not sure what kind of effect would be appropriate for 
project-vc-extra-root-markers to have on VC functionality.

>>> (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...

I thought there was some advice for vc-refresh-state somewhere, but I 
can't find it now. If you have time, you're welcome to look around.

Tramp often disables certain costly features (or Emacs packages provide 
options disable such features, when used remotely). This will need to be 
taken into account somehow.

Previous Next

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