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: Drew Adams
Subject: RE: Tips for quick jumping back and forth
Date: Wed, 11 Jul 2012 11:33:18 -0700

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

Sure, but as you say afterward this builtin, automatic where-I-was marking can
have its own drawbacks, including the global ring vs local rings limitation
which you point out.  Hence your attempt to (manually? programmatically?) mark
where-I-was.

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

Yes, so?  You still want to be able to navigate among code positions in any
order.

In particular, _you_ say you want to be able to navigate among them in a
particular order that you establish to represent the code calling hierarchy.
That's one of many possible structures (position relations), and even a single
tree/graph allows for many different traversals.

Which is my point.  The structure of a set of positions (ring, tree, whatever)
should not limit how you access individual positions or groups of positions.

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

OK.

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

That's just an argument that the global and local rings do not cut the mustard
for you.  Sounds good to me.  I agree.  They are what they are, and no more.

I hear you and go beyond what you're saying: the structure of the positions you
set should not limit your navigation of its elements in any way.

It's fine to have some help that favors certain predefined navigations/relations
over others.  But that's different from having the marker set's structure impose
predefined order(s).

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.

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

OK, so you mark those positions - manually (ugh) or automatically.  And you set
up a structure that records the relations (the order).  Great.

I agree that if you have a graphical (e.g. 2D) representation of that
order/structure, then you can see it as a whole and directly access positions or
access them using tree/graph traversal.  Think code folding, for instance.

Barring a 2D representation, you can use a linear ordering of the tree/graph - a
particular traversal.  And that you can do using either of the features I
mentioned.  (Again, think code folding: your code is both a tree/graph and a
linear representation.)  And you can flip among multiple such traversals.

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.

But more importantly, you are not limited to following any particular order
mechanically ("cycling") - you can also access any node directly.

IOW, your tree traversal order might be helpful sometimes, but you should not
want to be limited to it, any more than you want to be limited to the ring
navigation that you decry.

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

If you know where you want to go, you should not need to get there one step at a
time by traversing branches of a bushy tree.  If you can already see its
signpost on the other side of the bush, just go to it directly.

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

Here's the picture: You've got a list of your tree nodes, in an order that you
find useful.  You can immediatly hide/show particular nodes (by name or another
property), on the fly.  You can easily see all nodes that match some condition
(related to their names, creation dates, last access time, or anything else).
And you can immediately get to any of them you like after such filtering.  And
you can trip among groups of them in various orders.

The power is in the filtering.  Once you can see your destination, hey, just go
there.  Navigation as, first and foremost, filtering.  The same thing you would
do in (e.g. functional) programming to access parts of a tree.  You would map,
filter, whatever, to massage the tree into one that puts what you want at your
fingertips.  You would not necessarily mechanically set out on a depth- or
breadth- or best-first Silk Road traversal of all nodes from here to there.

I say "necessarily" because the point is that you are not limited to one or two
ways of navigating your tree/graph.  But nothing prevents you from getting there
the hard way, a neighbor node at a time.

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

Why would you lose it?  If you can create it then it is there and it remains.
It is part of the information recorded for your "marks".

Think bookmarks, if you like - you can record anything you like (parent, child,
the whole family tree...) in an individual bookmark, and you can record any
named sets of bookmarks, in particular orders or whatever.  You can record and
keep (or toss) any structure/relationships you like.  You can even program
things so that your recorded info is synced with changes to the real structure.

But again, any structure/relationships that you record are one thing.  How you
navigate among your marks is another thing.  The latter can be informed/helped
by the former, but it should not be limited by it.

> > Here are two great ways to do these things, IMNSHO:
> 
> I'll take a look at them, too, thanks.

If they help, fine.  If not, ignore.  Be aware too that you can program/tweak
either to do pretty much anything you like.




reply via email to

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