Re: Tips for quick jumping back and forth

[Dmitry Gutov <dgutov@yandex.ru>]

On 12.07.2012 3:44, Drew Adams wrote:
>> 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.

The full function call graph may be useful, but we don't have that in 
Emacs, at least not for most of the supported languages (CEDET?).

So we can try to rebuild it partially by tracing start and destination 
points of invocations of select navigation functions.

The harder part is grouping start points into single node. When we visit 
different functions called inside a certain function, we'll do that from 
different buffer positions. How do we decide that the parent node for 
resulting graph edges should be the same? `beginning-of-defun' and 
`end-of-defun' come to mind, but they don't really work for nested 
functions in js-mode, or for methods in ruby-mode (they just move to the 
beginning or end of the class).

I guess we could just track the last used node, but this way the 
resulting graph may deviate further from the call graph.

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

Navigating a full code graph, provided we have one, would be different.
For one, it's not hierarchical, any function can call any other 
function, so there can be multiple "parent" nodes, and we'd need to be 
able to choose the destination node when we're going "back", not just 
when going "forward".

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

No I mean only the visited nodes. You can't bookmark unvisited nodes 
either, so the comparison is meaningless there.

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

Sure, I just meant that for closest candidates it would be easier to 
jump along the edges than filter and choose.

Also, I think that you want to do that more often than jump to a faraway 
node, simply because when you're reading or writing, you mostly think 
about and touch directly related pieces of code.

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

Not the last visited, but the closest by distance in edges, probably.
I could have just came from a very distant tree node, for example, by 
traversing the edges, or with direct jump. The closest nodes definitely 
won't be the most recently visited ones.

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

No, "previously visited node" was just an easy illustration. If we want 
to build and use a graph, it won't be adequately represented by any 
linear ordering.

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

That's quite neat.

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

That might be useful.

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

I don't see how it can recreate the code structure from a set of points 
I spent some time at. Sure, it can group the points somehow, but not 
build directional relations.