Re: Tips for quick jumping back and forth

[Dmitry Gutov]

On 11.07.2012 22:33, Drew Adams wrote:
> > 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

The limitation is not necessary, I think. So, I'm puzzled by the 
built-in behavior, and I point it out.

> which you point out.  Hence your attempt to (manually? programmatically?) mark
> where-I-was.

Programmatically, through before-advice. I don't have a tree (yet?), 
though, just two stacks.

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

I think `imenu' and `find-tag' facility serve that purpose better, since 
you may want to jump to any class or function, not just some of them you 
have bookmarked.

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

That graph description was one of many possible interpretations, but I 
wanted to illustrate that when a structure has meaning, it can become 
easier to use.

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.

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

I agree that sometimes it shouldn't, but you can always additionally 
implement regexp search or other filtering, like you did with bookmarks.

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

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

Yes, I just wanted to elaborate on the reason why.

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

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.

On the other hand, if we don't have a structure saved, or if we just 
have the two mark rings, we can't even do the "pop back" action confidently.

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

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

> > > 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. That's always faster than 
invoking the list, entering search criteria, picking, etc.

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

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.
If you can only move to the neighbor nodes in a tree, this can be 
performed (nearly) automatically.

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

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.