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

[Juri Linkov <juri@linkov.net>]

> BTW, one more feature in this vein (stealing this idea from Stefan)
> would be if we automatically moved point to the same location in the
> other file.  That might be a little too magical.  But it would be very
> cool...

One possible implementation would be with the help of saveplace.el.
There are already some similarities between these two packages:
for example, the same fix that you proposed in bug#64088
to use file-remote-p before abbreviating project file names,
should be applied to save-place-abbreviation-file-names
in bug#65055 as well.

> Maybe the right call would be to have a keybinding in C-x p p like j or
> something, which would just instantly jump you to the same file in the
> other project.  So you'd just run C-x p p j and that would open the same
> file in the other project, with point inside the same function (using
> imenu), at the same offset in that function.

A dedicated command with 'C-x p p j' or just 'C-x p j' that will ask
for another project would be the best thing to do.

> Alternatively, maybe C-x p j could be an alternative to C-x p p, and
> when it prompts for a project, it could prompt only for "sibling
> projects" which have the same file structure.  And we could have a
> built-in way to detect sibling projects: Any other worktree of the
> current git repository is a sibling project.  (And we would make this
> extensible too of course; maybe have both project-siblings and
> vc-list-worktrees as extension points)

For switching to a sibling file in another project, I'm using a new
nice command 'find-sibling-file'.  Extending it specifically for projects
looks line a good direction for development.

> That could be helpful for other reasons too: I've often wanted "just put
> me anywhere in this other project, I don't care where", and this could
> be that command.  Although I suppose mostly I want that because C-x p p
> isn't currently a generic prefix for any command, and if we convert it
> to be that (with next-default-directory or something), I won't need
> that.

Probably next-default-directory will reuse the same keymaps,
but let's see where it goes in bug#63648.