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

[Dmitry Gutov <dmitry@gutov.dev>]

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.

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