RE: Tips for quick jumping back and forth

[Drew Adams]

> Even if your jumps are more arbitrary than that, chances are, 
> even when you C-s for a piece of code, it's somehow related
> to the code you were looking at before that. So jumping back
> and forward between them may be a thing you want to do. And
> that can be made faster than choosing the 
> destination with filtering both times.

You would not filter both times.  When you flip back and forth between two
buffers using `C-x b' (or whatever) you do not ask for all buffers as possible
candidates and filter the list each time.  You just accept the default of the
previously chosen buffer.  Same thing here.

For such a use case you need neither traverse a tree node-by-node nor filter it.
You just go directly to the last node visited.

> How to save a tree structure that would be generally useful, that's a 
> harder question.

Apparently you are interested in only the subset of the code tree/graph made up
of the nodes you have already visited.  Doesn't sound like a biggee.

Or do you want to also present neighbor but unvisited nodes as candidates?  And
possibly not just immediate neighbors but nearby neighbors?  I don't hear that
you have quite decided this.  But I thought that your previous description
involved only visited nodes as candidates.

> > You want to be able to easily navigate in an order that 
> > reflects your code structure.  But you don't want to be limited
> > to that navigation order, do you?  Do you want to _have_ to climb
> > step by step out of a deep code hierarchy to get to a distant
> > cousin node in another part of the tree?  I doubt it.  For that you
> > would quickly abandon your tree climbing, I am sure.
>
> Actually, the answer to that is "maybe", depending on how distant the 
> cousin is, and how well I know the code. For example, if I'm 
> not sure I remember the cousin's exact name, I might pop to the common 
> ancestor and follow from there, to be sure I know where I'm going.
> If I had a visual representation of the tree, that would be 
> even better.

I guess you mean a visual representation of the bushy tree itself, in addition
to a visual representation of only the nodes you have visited.  Perhaps you mean
the latter superimposed on the former.

I assume we are still talking about navigating among visited nodes, since you
made the point that for arbitrary navigation of the full code tree and not just
visited nodes things like imenu and Emacs tags (and Semantic...) can be more
appropriate.

I agree with that point, BTW - but it is a different topic.  For code navigation
in general there are lots of tools available.  The discussion here has (so far)
been about navigating among code bits (parts of the tree) that you have already
visited.
 
> > That was one of my main points: you can order the marks 
> > (nodes of your tree/graph) any way you like, and you can change
> > orders on the fly.
> 
> "Any way I like" is limited by the information I have.
> If I have a hierarchical tree, though, seeing the nodes in a list, 
> ordered and with child nodes additionally indented according to the 
> structure, with filtering, might be quite interesting.

That is what you would have.  As I said, the default order is buffer order.

But be aware that if we are talking only about places already visited then your
view of the tree (whether linearized or 2D) will be limited.  Anything unvisited
will be missing - not a candidate for navigation this way (even if you decide to
visualize it somehow).  You would have to get to it some other way, naturally.

This is much like a folded view of the code, but with the visible/invisible
determined by what you have visited or not.  (Or at least the navigable - maybe
you would decide to also show additional, unvisited nodes - see above.)

> >>> 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).
> >
> > Why do you think so?
> 
> It's just one or two key combinations away.

Not at all.  The only (already visited) parts of the tree that are only one or
two key combinations away are those that are, well, one or two key combinations
away!

And they would be the same distance away if you ordered candidates by last
visit, for instance.  Especially if your navigation model is only from node to
immediately adjacent node.

> That's always faster than invoking the list, entering search
> criteria, picking, etc.

You seem to be using last-visited as your metric of which nodes to represent as
nearby.  And apparently you are interested only in, say, the Nth nearest (by
visit time), to reduce your search space.

Those criteria seem to _be_ your search criteria, and the same criteria can be
used to control a bookmark (or whatever) choice/search just as easily.

IOW, that has nothing, per se, to do with any tree structure, AFAICT.

_If_ you choose to navigate the tree in the first place in some structured way,
and if you mark the nodes visited as you move through them, then the navigation
history will reflect the tree structure in a particular way, which you think
will be helpful.

(The history will reflect the tree structure in some way no matter how you
navigate the tree.  Of course, some ways might be more helpful than others.)

> > the point is that you are not limited to one or two
> > ways of navigating your tree/graph...
> 
> I agree it can be quite useful as well.
> Being able to filter the list, though, doesn't entirely solve the 
> problem of choice. You need to choose what to filter on, maybe also 
> ordering, and that requires some brainpower.

You would choose it beforehand, especially if you find an approach that you like
most of the time, as seems to be the case.

If you like your only-the-N-last-visited-nodes search space then put that into
defining your navigation set (bookmarks "navigation list" plus sort order).  No
special brainpower needed to explore that space afterward.

IOW, however you might want to define (including to order) the set of nodes that
you want to serve as navigation choices, you can do it.

They can be the tree nodes nearest your current position (e.g. in terms of
adjacent-node hops).  Or they can be the nodes you have visited most recently.
Or some combination of the two; or something else.

You can (programmatically) make it quickest and easiest to get to any particular
set of nodes you choose, by controlling the set and the order.  And you can
limit the set size to simplify choosing.

> If you can only move to the neighbor nodes in a tree, this can be 
> performed (nearly) automatically.

So make that your navigation set and limit yourself to it, if you like.

> I mean that if the rule above is always true (you only move 
> from caller to callee or back), your movement directly reflects
> elements of control flow - function call or value return, and
> so helps understanding the code structure. You're more aware
> of the relationships between functions.

Try it, and see how useful you find it to be.  If you limit yourself to
navigating your code that way (`C-M-d' etc.), and if you (manually or
automatically) "mark" each node you visit (or perhaps only selected nodes), then
you can find out how useful your breadcrumbs structure of visited nodes is for
subsequent navigating.

Wrt the automatic creation of bookmarks, I should mention also that Bookmark+
has a (buffer-local or global) mode to do that, which is based on time spent at
a given position with the position's buffer current:
`bmkp-auto-idle-bookmark-mode'.

You can define the bookmarking function that is used for this.  By default it
sets a temporary, autonamed bookmark at the start of the current line.  But it
could do anything you like, including pay attention to the code structure and
code parts already visited etc.

HTH.