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

Previous Next

Package: emacs;

Reported by: Sean Whitton <spwhitton <at> spwhitton.name>

Date: Tue, 15 Jul 2025 11:51:02 UTC

Severity: normal

Merged with 79104

Found in version 31.0.50

Done: Sean Whitton <spwhitton <at> spwhitton.name>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79024 <at> debbugs.gnu.org
Subject: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Wed, 30 Jul 2025 15:41:47 +0300
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.

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

All right.

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

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 bug report was last modified 5 days ago.

Previous Next


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