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.