GNU bug report logs -
#63829
29.0.90; project-find-file's future history breaks with common-parent-directory
Previous Next
Full log
Message #68 received at 63829 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 1 year and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.