Re: Tips for quick jumping back and forth

[Dmitry Gutov]

On 11.07.2012 19:02, Drew Adams wrote:
> >   > It'd be neat if there were different ways to navigate
> >   > through the ring; when I discovered Toby Cubitt's
> >   > excellent undo-tree-mode it somewhat revolutionized
> >   > my editing habits. I imagine that having a tree-like
> >   > representation of the marks that allows to easily
> >   > navigate back and forth would be very pleasant.
> >
> > Not sure about sideways navigation, but at least going back
> > and forward between marks would be an improvement.
> >
> > The distinction between local and global mark rings also, I think,
> > complicates things.
>
> What you want is a quick way to navigate to any previously marked position.  And
> of course a quick way to mark each position (e.g. a quick key).  It does not
> matter what "mark" means here - it could be but need not be an Emacs marker
> (e.g. from `C-SPC').

That's correct, except many useful functions, such as `imenu', 
`find-function', and `isearch-mode', automatically push mark before 
performing navigation. So the mark rings become a centralized source of 
information on "where I was before I did that thing".

> AFAICT, it also does not matter whether the marks were defined using a treelike
> pattern of navigation in the first place.  At least not to me, it doesn't.  And
> anyway you don't want to have imposed a particular navigation pattern (e.g. tree
> traversal of some sort).  You want to be able to navigate among marks in any
> order.

If you're just editing text, maybe. But I'd wager that most of the time 
people are using Emacs to read and edit program code.

When I'm reading code, I usually want to be able to follow the control 
flow: read the code of some function, jump into some function it calls, 
jump into some other function from it, etc.
The jumps may be contained to one file, or may be spread across several 
files - if I have to keep in mind which kind the last jump was when I 
want to return, that's a speed bump (hence my dislike for global vs 
local mark rings, etags.el does this better).

> More importantly, to navigate to an arbitrary "marked" position, you need
> _direct_ access.  It's of course also nice to be able to cycle among any group
> of those positions, including all of them.  But cycling, whether tree traversal
> or other, is essentially a fallback, primitive way to get where you want to go.

In the context I mentioned above, a tree could be a good way to 
represent the relations between marked positions. For example, if we 
save position before doing "jump to definition" and also save position 
before jumping back, a parent node would contain a position in a caller 
function, and each child node would point to a definition of a function 
called from parent (that we visited during the current editing session).
If the relations between nodes have defined meanings, traversing them 
will be fast, definitely faster than rings.
Because you know where you want to go, and you don't have to flip 
through the whole ring again if you miss your stop.

> To get to an arbitrary position - especially to get there directly, it helps for
> the position to have a name or to be highlighted in some way, so that you can
> easily (a) recognize it and (b) directly point to it (e.g. mouse, or name
> completion).

That's nice, except traversing along one or two edges of the tree would 
probably be faster (if you know which edges to follow, of course).

With direct access, you also lose the relationship context - like "the 
code I'm looking at now [calls|is called by] the code I was looking at a 
second ago".

> Here are two great ways to do these things, IMNSHO:
> <snipped>

I'll take a look at them, too, thanks.

--Dmitry