GNU bug report logs - #79126
vc-switch-working-tree does not work if there is no matching file

Previous Next

Full log

View this message in rfc822 format

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Dmitry Gutov <dmitry <at> gutov.dev>, Eshel Yaron <me <at> eshelyaron.com>,  79126 <at> debbugs.gnu.org
Subject: bug#79126: vc-switch-working-tree does not work if there is no matching file
Date: Wed, 06 Aug 2025 18:36:01 +0100

Hello,

On Wed 06 Aug 2025 at 12:06pm -04, Spencer Baugh wrote:

> Dmitry Gutov <dmitry <at> gutov.dev> writes:
>
>> On 06/08/2025 17:08, Sean Whitton wrote:
>>> +;; The default value works for file-visiting and Dired buffers.
>>> +;; Non-file-visiting major modes (other than `dired-mode'), where there
>>> +;; is a sensible notion of a matching buffer, can set this.
>>> +;; File-visiting major modes shouldn't set it, except possibly some
>>> +;; highly specialized ones.
>>> +(defvar project-find-matching-buffer-function #'project-find-matching-file
>>> +  "Function to switch to a matching buffer in another project.
>>> +Usually set buffer-locally by non-file-visiting major modes.
>>> +The function will be called with no arguments.  If the other project is
>>> +already determined, `project-current-directory-override' will be bound
>>> +to a directory under that other project.  Otherwise the function should
>>> +prompt for the other project, usually with `project-read-project'.")
>>
>> How about we try to simplify that hook?
>>
>> The command will check whether there is an overriding project and pass
>> that value as an argument to project-find-matching-buffer-function. Or
>> just the root directory, is that is simpler.
>>
>> Or two arguments: current-root and new-root. That should cut the
>> default function's definition by about a third, and do even better for
>> the specialized ones.
>
> Yes, I agree with that, we should at least pass the new project as an
> argument.  Passing the current project too sounds even better.
>
> IMO, it's slightly nicer to pass project objects rather than the root
> file names, since that avoids duplicate filesystem accesses to find
> project information (e.g. the vc backend) when necessary, but either way
> is fine.
>
> (This is maybe overengineering, but: we could even make it take *either*
> a root file name or a project object, so that callers can pass whatever
> is most convenient for them.  Then the code inside could use some new
> helper function which when passed a file name, returns (project-current
> nil file-name), and when passed anything else, returns that thing.  That
> might be simple enough, and this function would be fairly useful I
> think)

Sounds good, I agree with factoring things out along these lines.

I think we might want a function which wraps the (funcall
project-find-matching-buffer-function), and that could handle ensuring a
project object.

-- 
Sean Whitton

Previous Next

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