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

Previous Next

Full log

View this message in rfc822 format

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 79024 <at> debbugs.gnu.org
Subject: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Mon, 04 Aug 2025 21:09:40 +0100

Hello,

On Wed 30 Jul 2025 at 03:41pm +03, Dmitry Gutov wrote:

> On 30/07/2025 14:00, Sean Whitton wrote:
>
>>> 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?
>
> They are pretty solid, thanks. Please go ahead.

I'd previously proposed a variable, project-prompter-predicate, which
Lisp code would bind around calls to prompter-prompter.

But I see that the API for project-prompter has already been changed in
Emacs 31 to add a new optional PROMPT argument.  So I've gone with
adding two additional optional arguments instead of adding a new
variable.

>>> 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.
>
> Could be a bit less efficient than just substituting a list. Not sure if
> noticeable.

Yeah.  We'll see.

> Also, this way we could miss worktrees previously created outside of Emacs,
> and not registered in the project history yet. Again, not sure if it's
> critical.

This problem is unavoidable for Mercurial.

For Git I've added a loop to vc--prompt-other-working-tree to call
project-remember-project on the possibilities.

This going back and forth between VC and project has become a bit
convoluted but I think nicely serves the various needs we've identified.

-- 
Sean Whitton

Previous Next

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