help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tips for quick jumping back and forth


From: Dmitry Gutov
Subject: Re: Tips for quick jumping back and forth
Date: Fri, 13 Jul 2012 01:30:44 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]