GNU bug report logs -
#63829
29.0.90; project-find-file's future history breaks with common-parent-directory
Previous Next
Full log
Message #83 received at 63829 <at> debbugs.gnu.org (full text, mbox):
> 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.
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.