bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory

[Spencer Baugh <sbaugh@janestreet.com>]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 04/06/2023 19:36, Juri Linkov wrote:
>>> On top of your patch, I can implement the feature I mentioned with the
>>> patch at the end.  This causes the following nice behavior:
>>>
>>> 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el
>>> 2. C-x p p ~/src/emacs/trunk
>>> 3. f
>>> 4. M-n and the minibuffer contains "lisp/progmodes/project.el"
>>> 5. RET and we have now easily switched to the same file in another
>>>     project
>>>
>>> Does the implementation seem OK?
>>>
>>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>>> index ac7be8dcbb2..b1e01df5314 100644
>>> --- a/lisp/progmodes/project.el
>>> +++ b/lisp/progmodes/project.el
>>> @@ -1008,7 +1008,12 @@ project-find-file
>>>            (dirs (list root)))
>>>       (project-find-file-in
>>>        (or (thing-at-point 'filename)
>>> -         buffer-file-name)
>>> +         (and buffer-file-name
>>> +              (if-let (buffer-proj (and project-current-directory-override
>>> +                                       (project-current nil default-directory)))
>> But we are going to remove project-current-directory-override in bug#63648
>> where default-directory will be changed to next-default-directory.
>
> I guess the proposed logic could be reimplemented without using
> project-current-directory-override -- just based on the changed value
> of default-directory. And using the parent directory of
> buffer-file-name.
>
> But so far the patch over there is not complete yet, is it? I wouldn't
> say it's a settled matter so far.

Yes, I expect there are any number of alternative implementation
strategies, I'm not at all tied to using
project-current-directory-override.  Happy to port to whatever approach
we end up with.

>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127
>> and then it was deemed to be not too general to handle, so I backed it out
>> inhttps://debbugs.gnu.org/58447#160  with such conclusion:
>>    OTOH, `C-x p f M-p' in another project is not my primary
>> workflow.
>>    But if someone wants to keep a plain history, this could be added
>>    later in master, e.g. by a new value of project-read-file-name-function
>>    and a function that is mostly a copy of project--read-file-cpd-relative.
>> So maybe this could be implemented in master now?
>
> I think the design there was to use relative file names in history? Or
> a different variable for project file name history (which would use
> relative names only). I'm not ruling that out, but the patch proposed
> here is a little more focused.
>
> OTOH, it only allows finding the "current" file in the other project,
> but not other files that were previously visited too. Spencer, what do
> you think about that capability? Do you also feel it is missing and
> would like to look into it next? Then the current patch might be the
> wrong direction.

Hm, the main thing I want is to make it very easy to visit the current
file in another project - I am frequently getting user requests for that
feature.  (Mainly because our workflow heavily uses a "git worktree"
equivalent, where users have one project for each bug/branch they're
working on, all with basically the same layout, so "visit the same file
in a different project" is also "visit the same file in a different
branch", which is often useful.  (I actually might work on some code to
help implement the same kind of workflow for Emacs development, one
worktree per bug/branch))

I'm not sure I understand the alternative - the idea would be to share
project file name history between all projects?  I guess that could be
nice, although I don't personally use file name history that much, and
AFAIK it wouldn't solve any concrete user problems, so I'm not really
motivated to implement it.

However, if we did share project file name history in that way, I'd want
to still automatically prepend the "current file" as history.  Even if
we didn't navigate to the current file via project-find-file, I still
want to make it very easy to visit the current file in another project.
Just sharing project file name history doesn't provide that.