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