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

[Dmitry Gutov]

On 18/08/2023 23:57, Spencer Baugh wrote:
> 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...
>
> I guess the ideal thing we'd want is to move point to the same function,
> which is a bit trickier...  could be done with imenu perhaps.  Not
> sure...

We don't know how much these files could be different. One could be 
empty (a newly-created one), or having totally different contents.

There is a way to detect a useful offset if the files are similar enough 
(using 'diff -u''s output), I think we have that in diff-hl. But calling 
'diff' when any file is visited seems like it will be minority 
preference... I think.

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

Sure, why not. As a part of your personal (or company-wise) settings?

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

Just in case you were not aware: project-switch-commands can also be set 
to a single symbol, then just that command will be invoked.

> 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)

I'm not convinced yet by the idea of 'project-siblings' generic (need 
more uses/users), but the rest sounds good and very doable anyway.