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

[Dmitry Gutov <dmitry@gutov.dev>]

On 21/08/2023 10:06, Juri Linkov wrote:
>>>> +(defcustom project-file-name-history-relativize nil
>>>> +  "If non-nil, paths in `file-name-history' are adjusted for the current project.
>>>> +
>>> Instead of, or in addition to 'project-file-name-history-relativize',
>>> another option may be needed to define whether to check the
>>> existence of the constructed file name.  This could help
>>> to filter out irrelevant file names constructed from
>>> different projects.
>>
>> It could indeed. But it could also prevent the user from easily creating
>> a new file with the name from a "sister" project.
> 
> It would be unfortunate to lose this useful feature.
> 
>> We've discussed this before in this thread, including the idea of some
>> predicate checking the projects for compatibility, etc. What behavior would
>> you actually choose yourself?
> 
> I guess introducing a notion of "sibling projects" is unavoiable
> to exclude such situations where relative file names from one project
> are proposed in an unrelated project:
> 
>    Find file in /project/root/: relative/filename/from/unrelated/project
> 
> Then one possibility is to add an option to define sibling projects.
> Like 'find-sibling-rules', but maybe simply to contain alists of
> sibling projects.  Or projects in 'project--list' could have
> a new property 'group' where a project belongs to.
> 
> Then sibling projects could share the common file history.
> 
> And a new command e.g. 'project-find-sibling-file' could
> jump to a sibling project file immediately in case of
> two sibling projects, or ask to select with completion
> for more projects.

That would require a new generic (project-sibling-projects) and a proper 
description of what a "sibling" project is supposed to be. And probably 
still not going to work for VC-aware backend OOTB (it'll require some 
backend specific hook for the users to define that logic).

Sounds a little complicated, so given that one can still reach almost 
the same functionality through history completion ('C-x p p ... RET f 
C-n RET'), maybe it's a bit of an overkill? I'm open to further 
arguments, though.