[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.
Re: Tips for quick jumping back and forth, B. T. Raven, 2012/07/08
Re: Tips for quick jumping back and forth, Dmitry Gutov, 2012/07/11
Re: Tips for quick jumping back and forth, Edward at Work, 2012/07/11