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

[Juri Linkov]

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