GNU bug report logs - #79024
31.0.50; Multiple working trees support for VC

Previous Next

Full log

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 79024 <at> debbugs.gnu.org
Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Wed, 30 Jul 2025 12:00:14 +0100

Hello,

On Wed 30 Jul 2025 at 05:24am +03, Dmitry Gutov wrote:

> Hi Sean,
>
> On 29/07/2025 16:21, Sean Whitton wrote:
>> I think you missed this request for input here.  Would you be able to
>> take a look?  Thanks.
>> On Fri 18 Jul 2025 at 10:36am +01, Sean Whitton wrote:
>>
>>> Dmitry, what do you think about a new project-prompter-predicate which
>>> project prompters should use to filter the list of projects offered?  VC
>>> could bind that to something which only lets through related worktrees.
>
> I guess my answer is maybe.
>
> Ideally we should be able to think of some other usage scenarios as well, not
> just from this worktree feature. Maybe add them to the docstring.

Right.  I can most readily imagine code that wants to prompt the user to
select a project, but limit the selection to projects under a particular
directory.

For example if I have a whole bunch of Elisp that's on my load-path
under, say, ~/.emacs.d/elpa/, I could write a function which will bind
project-prompter-predicate to filter out all other projects.  So then I
have a command which is "switch to the source of one of my ELPA packages".

I can also imagine something which filters the selection by forge URI.
So if all my work projects are on a private gitlab instance, I could
write a command which would allow me to select only from my work
projects by matching on the configured remote URI and filtering out
projects on other kinds of remote.

I can imagine something with active nix-envs or something too.

Do you find these examples compelling?

> Questions about implementation:
>
> Will 'project-known-project-roots' use (and be affected by) that predicate?

I don't think so, because that's not an interactive function, and so its
caller can apply a predicate to the return value if wanted.

> Could someone set it up one day and then later see a project-list entry stay
> around in the file but never come up in the prompt, or never be cleared by
> project-forget-zombie-projects?

That could happen if someone gives project-prompter-predicate a global
value, yeah.  I don't think you'd want to do that, though -- I was
thinking it'd be a defvar not a defcustom.

> Also IIUC if we consider the "other-working-trees API" approach, I guess it
> wouldn't exactly fit as a solution, because we'd want to substitute the full
> list instead of filtering. (Is that right?) Then an alternative could be just
> a separate user option for the prompter function here.

I don't think there is an inherent clash here.  The predicate would just
be (lambda (p) (member p working-trees)) where working-trees is the
result of having called known-other-working-trees.

-- 
Sean Whitton

Previous Next

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