Tips for quick jumping back and forth

Tips for quick jumping back and forth

[C K Kashyap]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Dear Emacs friends,

I need some tips for quick jumping around. As in, say I'm editing a line
and need to go up a couple of paragraphs to edit something and then resume
at my original position.
The way I used to accomplish this in Vi was using mm to mark the current
position into m register and then go somewhere and come back by pressing 'm

Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a position
into a register and then jump back to it usng C-x-r-j ... is there a better
way? Rather, what's a better way?

Regards,
Kashyap

[-- Attachment #2: Type: text/html, Size: 663 bytes --]

Re: Tips for quick jumping back and forth

[Jambunathan K]

C K Kashyap <ckkashyap@gmail.com> writes:

> Dear Emacs friends,
>
> I need some tips for quick jumping around. As in, say I'm editing a
> line and need to go up a couple of paragraphs to edit something and
> then resume at my original position. 
> The way I used to accomplish this in Vi was using mm to mark the
> current position into m register and then go somewhere and come back
> by pressing 'm
>
> Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a
> position into a register and then jump back to it usng C-x-r-j ... is
> there a better way? Rather, what's a better way?

C-h K C-x C-SPC

It will land you in an Info node.  See that node and the node previous
to it.

> Regards,
> Kashyap
>
>

-- 

Re: Tips for quick jumping back and forth

[Andreas Röhler]

Am 07.07.2012 07:43, schrieb C K Kashyap:
> Dear Emacs friends,
>
> I need some tips for quick jumping around. As in, say I'm editing a line
> and need to go up a couple of paragraphs to edit something and then resume
> at my original position.
> The way I used to accomplish this in Vi was using mm to mark the current
> position into m register and then go somewhere and come back by pressing 'm
>
> Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a position
> into a register and then jump back to it usng C-x-r-j ... is there a better
> way? Rather, what's a better way?
>
> Regards,
> Kashyap
>

use a couple of hard-coded register-commands which got keys

for example

(global-set-key [(control kp-1)] 'gehe-zu-register-x)

with (control u) (control kp-1) the point is registered

(control kp-1) will jump back to it

(defun gehe-zu-register-x (&optional arg)
   "With C-u remember buffer and point"
   (interactive "P")
   (if arg
       (progn
	(window-configuration-to-register ?x)
	(message "%s" "Jump back with \[C-kp-1] or \\C-x j x"))
     (jump-to-register ?x)
     (message "%s"   "With Arg: remember point and buffer")))


Cheers,

Andreas

Re: Tips for quick jumping back and forth

[José A. Romero L.]

W dniu sobota, 7 lipca 2012 07:43:59 UTC+2 użytkownik C K Kashyap napisał:
(...)
> The way I used to accomplish this in Vi was using mm to mark the current position into m register and then go somewhere and come back by pressing &#39;m</div>
(...)

hmm, use Evil?

   http://emacswiki.org/emacs/Evil

Cheers,
--
José A. Romero L.
escherdragon at gmail
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

Re: Tips for quick jumping back and forth

[Xah Lee]

On Jul 6, 10:43 pm, C K Kashyap <ckkash...@gmail.com> wrote:
> Dear Emacs friends,
>
> I need some tips for quick jumping around. As in, say I'm editing a line
> and need to go up a couple of paragraphs to edit something and then resume
> at my original position.
> The way I used to accomplish this in Vi was using mm to mark the current
> position into m register and then go somewhere and come back by pressing 'm
>
> Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a position
> into a register and then jump back to it usng C-x-r-j ... is there a better
> way? Rather, what's a better way?
>
> Regards,
> Kashyap

i've tried all ways in past years, including custom elisp that push
marks. But i found split windows to be best.

e.g. split window. Go to where you wanna be. When done, unsplit.

give split/unsplit a easy key. e.g. Alt+3, Alt+4 in ergoemacs.

 Xah

Re: Tips for quick jumping back and forth

[Dmitry Gutov]

C K Kashyap <ckkashyap@gmail.com> writes:

 > I need some tips for quick jumping around. As in, say I'm editing a 
line and
 > need to go up a couple of paragraphs to edit something and then 
resume at my
 > original position.
 > The way I used to accomplish this in Vi was using mm to mark the current
 > position into m register and then go somewhere and come back by 
pressing 'm
 >
 > Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a 
position into
 > a register and then jump back to it usng C-x-r-j ... is there a 
better way?
 > Rather, what's a better way?

You can try this package:
https://github.com/dgutov/point-stack/blob/master/point-stack.el

It's a more general solution for back-and-forth navigation, but you can
also save any position manually with a hotkey.

--Dmitry

Re: Tips for quick jumping back and forth

[Francesco Mazzoli]

At Sat, 7 Jul 2012 11:13:59 +0530,
C K Kashyap wrote:
> Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a position
> into a register and then jump back to it usng C-x-r-j ... is there a better
> way? Rather, what's a better way?

I use `C-<SPC> C-<SPC>' to set the mark, and `C-u C-<SPC>' to jump back. No
registers involved.

--
Francesco * Often in error, never in doubt

Re: Tips for quick jumping back and forth

[notbob]

On 2012-07-07, Francesco Mazzoli <f@mazzo.li> wrote:
>
> I use `C-<SPC> C-<SPC>' to set the mark, and `C-u C-<SPC>' to jump back. No
> registers involved.

I occasionally do something stupid like hit the wrong keystroke, usually
C-e, which puts me at the end of the line.  I was somewhat sure there
was an equally simple keystroked to return me to where I once was
where.  NO!?  If not, I'm bummed.  I thought emacs was "powerful".
Seems a simple function.  And by GOD, can't let vi outdo on this!      

nb


-- 
vi --the heart of evil!

Re: Tips for quick jumping back and forth

[Dmitry Gutov]

notbob <notbob@nothome.com> writes:

 > On 2012-07-07, Francesco Mazzoli <f@mazzo.li> wrote:
 >> I use `C-<SPC> C-<SPC>' to set the mark, and `C-u C-<SPC>' to jump 
 >> back. No registers involved.
 >
 > I occasionally do something stupid like hit the wrong keystroke, usually
 > C-e, which puts me at the end of the line.  I was somewhat sure there
 > was an equally simple keystroked to return me to where I once was
 > where.  NO!?  If not, I'm bummed.  I thought emacs was "powerful".
 > Seems a simple function.  And by GOD, can't let vi outdo on this!

Can vi undo just any navigation command?

Re: Tips for quick jumping back and forth

[C K Kashyap]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Thank you so much all of you ---

I think C-<SPC> C-<SPC> then C-u C-<SPC> works for me

The split window trick seems neat - actually very neat - One question
though ... when I split the window and then move somewhere else, I would
then have to switch to the other windows before making it the only one -
right? Some extra key strokes seem to be involved.

What I like best about Emacs is that I could've written up a script and
bound to keys as Andreas suggested but I prefer to do find out if there is
an "Emacs" way to do it already.

Thank you all for your suggestions. I shifted to Emacs a couple of years
ago (after being a Vi guy for over 10 years!) because I fell in love with
functional programming (in Haskell actually).

Regards,
Kashyap



On Sat, Jul 7, 2012 at 8:57 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> notbob <notbob@nothome.com> writes:
>
> > On 2012-07-07, Francesco Mazzoli <f@mazzo.li> wrote:
> >> I use `C-<SPC> C-<SPC>' to set the mark, and `C-u C-<SPC>' to jump >>
> back. No registers involved.
> >
> > I occasionally do something stupid like hit the wrong keystroke, usually
> > C-e, which puts me at the end of the line.  I was somewhat sure there
> > was an equally simple keystroked to return me to where I once was
> > where.  NO!?  If not, I'm bummed.  I thought emacs was "powerful".
> > Seems a simple function.  And by GOD, can't let vi outdo on this!
>
> Can vi undo just any navigation command?
>
>

[-- Attachment #2: Type: text/html, Size: 2160 bytes --]

Re: Tips for quick jumping back and forth

[suvayu ali]

On Sun, Jul 8, 2012 at 5:28 AM, C K Kashyap <ckkashyap@gmail.com> wrote:
> I would then have to switch to the other windows before making it the only
> one - right? Some extra key strokes seem to be involved.

C-x 0 - delete current window

-- 
Suvayu

Open source is the future. It sets us free.

Re: Tips for quick jumping back and forth

[C K Kashyap]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

Nice....thanks Suvayu.

Regards,
Kashyap

On Sun, Jul 8, 2012 at 9:01 AM, suvayu ali <fatkasuvayu+linux@gmail.com>wrote:

> On Sun, Jul 8, 2012 at 5:28 AM, C K Kashyap <ckkashyap@gmail.com> wrote:
> > I would then have to switch to the other windows before making it the
> only
> > one - right? Some extra key strokes seem to be involved.
>
> C-x 0 - delete current window
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>

[-- Attachment #2: Type: text/html, Size: 893 bytes --]

Re: Tips for quick jumping back and forth

[rusi]

On Jul 8, 8:31 am, suvayu ali <fatkasuvayu+li...@gmail.com> wrote:
> On Sun, Jul 8, 2012 at 5:28 AM, C K Kashyap <ckkash...@gmail.com> wrote:
>
> > I would then have to switch to the other windows before making it the only
> > one - right? Some extra key strokes seem to be involved.
>
> C-x 0 - delete current window

Or C-x 1
You need to play with C-x {2,3,1,0}
Then get them into your fingers (spine actually) so you can forget
about it

I used to do C-x 2 C-x 3 C-x 2 C-x 3 and frighten my students -  20
years ago we only had ttys and this was more unexpected
I mention this because after that the different utility of 0 and 1
will be more apparent

Re: Tips for quick jumping back and forth

[B. T. Raven]

Die Sat Jul 07 2012 00:43:59 GMT-0500 (Central Daylight Time) C K
Kashyap <ckkashyap@gmail.com> scripsit:

> Dear Emacs friends,
> 
> I need some tips for quick jumping around. As in, say I'm editing a line
> and need to go up a couple of paragraphs to edit something and then
> resume at my original position. 
> The way I used to accomplish this in Vi was using mm to mark the current
> position into m register and then go somewhere and come back by pressing 'm
> 
> Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a
> position into a register and then jump back to it usng C-x-r-j ... is
> there a better way? Rather, what's a better way?
> 
> Regards,
> Kashyap

It might seem hokey to you,  but the fastest way to navigate is usually
via  C-s and C-r. If your need is as simple as you describe it, just
type your bookmark directly into the text (even in the middle of a word,
wherever the cursor happens to be, e.g.: bbb or zzz. Then move to where
you will edit with C-s or C-r and press enter (that leaves the cursor on
the next character after (or next before with C-r) the search string in
the minibuffer). Make your edit and then C-s or C-r back to bbb or zzz
and delete it. Doing it this way makes use of only the simplest
commands, the ones you use hundreds or thousands of times a day.

Ed

p.s. If isearch-recursive-edit variable worked then there might be a
more elegant way to search, move, edit, return to start of search.

Re: Tips for quick jumping back and forth

[Xah Lee]

On Jul 7, 8:28 pm, C K Kashyap <ckkash...@gmail.com> wrote:
> Thank you so much all of you ---
>
> I think C-<SPC> C-<SPC> then C-u C-<SPC> works for me
>
> The split window trick seems neat - actually very neat - One question
> though ... when I split the window and then move somewhere else, I would
> then have to switch to the other windows before making it the only one -
> right? Some extra key strokes seem to be involved.

use delete-window to unsplit. also give that a easy key.

in ErgoEmacs, it's:

【Alt+3】 delete-other-windows
【Alt+4】 split-window-vertically
【Alt+0】 delete-window
【Alt+s】 other-window

keys are based on frequency of use and ease of press.

 Xah

Re: Tips for quick jumping back and forth

[Ken Goldman]

On 7/7/2012 11:31 PM, suvayu ali wrote:
> On Sun, Jul 8, 2012 at 5:28 AM, C K Kashyap<ckkashyap@gmail.com>  wrote:
>> I would then have to switch to the other windows before making it the only
>> one - right? Some extra key strokes seem to be involved.
>
> C-x 0 - delete current window
>

Or for mouse lovers:

mouse-2 on a status bar deletes the other window(s)
mouse-3 on a status bar deletes that window

Re: Tips for quick jumping back and forth

[Le Wang]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Sat, Jul 7, 2012 at 1:43 PM, C K Kashyap <ckkashyap@gmail.com> wrote:

> Dear Emacs friends,
>
> I need some tips for quick jumping around. As in, say I'm editing a line
> and need to go up a couple of paragraphs to edit something and then resume
> at my original position.
>

I find registers hard to use.  Here is a thread I started a while back
singing the virtues of session.el:

http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00758.html

it allows you to jump through all locations in the buffer were you've made
a change in reverse chronological order.

I've written jump-char https://github.com/lewang/jump-char to quickly to
quickly go to occurrences of a char close by.  Jump-char integrates with
ace-jump-mode https://github.com/winterTTr/ace-jump-mode/ , which is better
if there are lots of occurrences.

The only time I actually use registers is while recording a macro.

HTH.

-- 
Le

[-- Attachment #2: Type: text/html, Size: 1444 bytes --]

Re: Tips for quick jumping back and forth

[Philipp Haselwarter]

On Sat, Jul 07 2012 08:19 (@1341641958), Jambunathan K wrote:

> C K Kashyap <ckkashyap@gmail.com> writes:
>
>> Dear Emacs friends,
>>
>> I need some tips for quick jumping around. As in, say I'm editing a
>> line and need to go up a couple of paragraphs to edit something and
>> then resume at my original position. 
>> The way I used to accomplish this in Vi was using mm to mark the
>> current position into m register and then go somewhere and come back
>> by pressing 'm
>>
>> Now, I know that in emacs I can do it using C-x-r-<SPC> to mark a
>> position into a register and then jump back to it usng C-x-r-j ... is
>> there a better way? Rather, what's a better way?
>
> C-h K C-x C-SPC
>
> It will land you in an Info node.  See that node and the node previous
> to it.
>
>> Regards,
>> Kashyap

It'd be neat if there were different ways to navigate through the ring;
when I discovered Toby Cubitt's excellent undo-tree-mode it somewhat
revolutionized my editing habits. I imagine that having a tree-like
representation of the marks that allows to easily navigate back and
forth would be very pleasant.

-- 
Philipp Haselwarter

Re: Tips for quick jumping back and forth

[Dmitry Gutov]

Philipp Haselwarter <philipp@haselwarter.org> writes:
 > It'd be neat if there were different ways to navigate through the ring;
 > when I discovered Toby Cubitt's excellent undo-tree-mode it somewhat
 > revolutionized my editing habits. I imagine that having a tree-like
 > representation of the marks that allows to easily navigate back and
 > forth would be very pleasant.

Not sure about sideways navigation, but at least going back and forward
between marks would be an improvement.

The distinction between local and global mark rings also, I think,
complicates things.

Re: Tips for quick jumping back and forth

[Eric Abrahamsen]

On Wed, Jul 11 2012, Dmitry Gutov wrote:

> Philipp Haselwarter <philipp@haselwarter.org> writes:
>> It'd be neat if there were different ways to navigate through the ring;
>> when I discovered Toby Cubitt's excellent undo-tree-mode it somewhat
>> revolutionized my editing habits. I imagine that having a tree-like
>> representation of the marks that allows to easily navigate back and
>> forth would be very pleasant.
>
> Not sure about sideways navigation, but at least going back and forward
> between marks would be an improvement.
>
> The distinction between local and global mark rings also, I think,
> complicates things.

Since this thread seems determined to live forever, here are two useful
functions I copied from the interwebs somewhere:

--8<---------------cut here---------------start------------->8---
(defun jump-to-mark ()
  "Jumps to the local mark, respecting the `mark-ring' order.
This is the same as using \\[set-mark-command] with the prefix argument."
  (interactive)
  (set-mark-command 1))
(global-set-key (kbd "M-`") 'jump-to-mark)

(defun push-mark-no-activate ()
  "Pushes `point' to `mark-ring' and does not activate the region
Equivalent to \\[set-mark-command] when \\[transient-mark-mode] is disabled"
  (interactive)
  (push-mark (point) t nil)
  (message "Pushed mark to ring"))
(global-set-key (kbd "C-`") 'push-mark-no-activate)
--8<---------------cut here---------------end--------------->8---

I use "C-x C-SPC" for cycling through the global mark, and "M-`" for
cycling the local one.

E

-- 
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-07-08 on pellet

RE: Tips for quick jumping back and forth

[Drew Adams]

>  > It'd be neat if there were different ways to navigate 
>  > through the ring; when I discovered Toby Cubitt's
>  > excellent undo-tree-mode it somewhat revolutionized
>  > my editing habits. I imagine that having a tree-like
>  > representation of the marks that allows to easily
>  > navigate back and forth would be very pleasant.
> 
> Not sure about sideways navigation, but at least going back 
> and forward between marks would be an improvement.
> 
> The distinction between local and global mark rings also, I think,
> complicates things.

What you want is a quick way to navigate to any previously marked position.  And
of course a quick way to mark each position (e.g. a quick key).  It does not
matter what "mark" means here - it could be but need not be an Emacs marker
(e.g. from `C-SPC').

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.

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.

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

Here are two great ways to do these things, IMNSHO:

1. Autonamed bookmarks, with Bookmark+.  You can create them with a single
keystroke.  They have recognizable names that by default show their buffer
positions.  They can optionally be highlighted in a number of different ways and
based on a number of different conditions/events.  They can be temporary or you
can save them persistently (individually or en masse).  You can cycle among any
group of them by just hitting a repeating key.

So a single key to create, easily recognized, direct-access navigation, cycling.

2a. Icicles.  First, it improves what Bookmark+ offers, by providing various
ways to match the bookmark names, and letting you easily change sort orders for
cycling.

2b. Icicles.  Second, it gives you the same kind of navigation for the ordinary
markers of the `mark-ring' and the `global-mark-ring' (separately) as it does
for bookmarks.  You can use the same key to set a marker and to navigate to one.
What about the names - how do you recognize a marker and access it directly?
The text of the line is the name.  By default the completion candidates are in
marker (i.e., buffer position) order - just hit a key to change to the next sort
order.

So a single key to create, easily recognized, direct-access navigation, cycling.

Have fun.  HTH.

Re: Tips for quick jumping back and forth

[Dmitry Gutov]

On 11.07.2012 19:02, Drew Adams wrote:
>>   > It'd be neat if there were different ways to navigate
>>   > through the ring; when I discovered Toby Cubitt's
>>   > excellent undo-tree-mode it somewhat revolutionized
>>   > my editing habits. I imagine that having a tree-like
>>   > representation of the marks that allows to easily
>>   > navigate back and forth would be very pleasant.
>>
>> Not sure about sideways navigation, but at least going back
>> and forward between marks would be an improvement.
>>
>> The distinction between local and global mark rings also, I think,
>> complicates things.
>
> What you want is a quick way to navigate to any previously marked position.  And
> of course a quick way to mark each position (e.g. a quick key).  It does not
> matter what "mark" means here - it could be but need not be an Emacs marker
> (e.g. from `C-SPC').

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

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

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

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

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

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

> Here are two great ways to do these things, IMNSHO:
> <snipped>

I'll take a look at them, too, thanks.

--Dmitry

RE: Tips for quick jumping back and forth

[Drew Adams]

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

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.

RE: Tips for quick jumping back and forth

[Drew Adams]

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

You would not filter both times.  When you flip back and forth between two
buffers using `C-x b' (or whatever) you do not ask for all buffers as possible
candidates and filter the list each time.  You just accept the default of the
previously chosen buffer.  Same thing here.

For such a use case you need neither traverse a tree node-by-node nor filter it.
You just go directly to the last node visited.

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

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.

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

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.

I assume we are still talking about navigating among visited nodes, since you
made the point that for arbitrary navigation of the full code tree and not just
visited nodes things like imenu and Emacs tags (and Semantic...) can be more
appropriate.

I agree with that point, BTW - but it is a different topic.  For code navigation
in general there are lots of tools available.  The discussion here has (so far)
been about navigating among code bits (parts of the tree) that you have already
visited.
 
> > 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.

That is what you would have.  As I said, the default order is buffer order.

But be aware that if we are talking only about places already visited then your
view of the tree (whether linearized or 2D) will be limited.  Anything unvisited
will be missing - not a candidate for navigation this way (even if you decide to
visualize it somehow).  You would have to get to it some other way, naturally.

This is much like a folded view of the code, but with the visible/invisible
determined by what you have visited or not.  (Or at least the navigable - maybe
you would decide to also show additional, unvisited nodes - see above.)

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

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.

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

Those criteria seem to _be_ your search criteria, and the same criteria can be
used to control a bookmark (or whatever) choice/search just as easily.

IOW, that has nothing, per se, to do with any tree structure, AFAICT.

_If_ you choose to navigate the tree in the first place in some structured way,
and if you mark the nodes visited as you move through them, then the navigation
history will reflect the tree structure in a particular way, which you think
will be helpful.

(The history will reflect the tree structure in some way no matter how you
navigate the tree.  Of course, some ways might be more helpful than others.)

> > the point is that you are not limited to one or two
> > ways of navigating your tree/graph...
> 
> 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.

You would choose it beforehand, especially if you find an approach that you like
most of the time, as seems to be the case.

If you like your only-the-N-last-visited-nodes search space then put that into
defining your navigation set (bookmarks "navigation list" plus sort order).  No
special brainpower needed to explore that space afterward.

IOW, however you might want to define (including to order) the set of nodes that
you want to serve as navigation choices, you can do it.

They can be the tree nodes nearest your current position (e.g. in terms of
adjacent-node hops).  Or they can be the nodes you have visited most recently.
Or some combination of the two; or something else.

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.

> If you can only move to the neighbor nodes in a tree, this can be 
> performed (nearly) automatically.

So make that your navigation set and limit yourself to it, if you like.

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

Try it, and see how useful you find it to be.  If you limit yourself to
navigating your code that way (`C-M-d' etc.), and if you (manually or
automatically) "mark" each node you visit (or perhaps only selected nodes), then
you can find out how useful your breadcrumbs structure of visited nodes is for
subsequent navigating.

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

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.

HTH.

Re: Tips for quick jumping back and forth

[Edward at Work]

On Friday, July 6, 2012 10:43:59 PM UTC-7, C K Kashyap wrote:
> Dear Emacs friends,
> 
> </div>
> I need some tips for quick jumping around. As in, say I&#39;m editing a line and need to go up a couple of paragraphs to edit something and then resume at my original position. </div>
> 
> The way I used to accomplish this in Vi was using mm to mark the current position into m register and then go somewhere and come back by pressing &#39;m</div>
> 
> </div>
> Now, I know that in emacs I can do it using C-x-r-&lt;SPC&gt; to mark a position into a register and then jump back to it usng C-x-r-j ... is there a better way? Rather, what&#39;s a better way?</div>
> 
> 
> </div>
> Regards,</div>
> Kashyap</div>

The simplest solution, provided you know ahead of time you're coming back, is to 1) set the mark (C-space) (set-mark-command), 2) Go do what you need to do wherever you need to do it, & finally 3) return by exchanging the point (where you are) with the mark (C-x C-x) (exchange-point-and-mark).

Edward

Re: Tips for quick jumping back and forth

[Dmitry Gutov]

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

[Kevin Rodgers]

On 7/7/12 8:44 AM, notbob wrote:
> On 2012-07-07, Francesco Mazzoli<f@mazzo.li>  wrote:
>>
>> I use `C-<SPC>  C-<SPC>' to set the mark, and `C-u C-<SPC>' to jump back. No
>> registers involved.
>
> I occasionally do something stupid like hit the wrong keystroke, usually
> C-e, which puts me at the end of the line.  I was somewhat sure there
> was an equally simple keystroked to return me to where I once was
> where.  NO!?  If not, I'm bummed.  I thought emacs was "powerful".
> Seems a simple function.  And by GOD, can't let vi outdo on this!

buffer-undo-list can record the position before the inadvertant command
so that C-x u would move you back, but the movement commands don't take
advantage of that feature.

C-h v buffer-undo-list:
...
An entry of the form POSITION indicates that point was at the buffer
location given by the integer.  Undoing an entry of this form places
point at POSITION.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Tips for quick jumping back and forth

[Jambunathan K]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> On 7/7/12 8:44 AM, notbob wrote:
>> On 2012-07-07, Francesco Mazzoli<f@mazzo.li>  wrote:
>>>
>>> I use `C-<SPC>  C-<SPC>' to set the mark, and `C-u C-<SPC>' to jump back. No
>>> registers involved.
>>
>> I occasionally do something stupid like hit the wrong keystroke, usually
>> C-e, which puts me at the end of the line.  I was somewhat sure there
>> was an equally simple keystroked to return me to where I once was
>> where.  NO!?  If not, I'm bummed.  I thought emacs was "powerful".
>> Seems a simple function.  And by GOD, can't let vi outdo on this!
>
> buffer-undo-list can record the position before the inadvertant command
> so that C-x u would move you back, but the movement commands don't take
> advantage of that feature.
>
> C-h v buffer-undo-list:
> ...
> An entry of the form POSITION indicates that point was at the buffer
> location given by the integer.  Undoing an entry of this form places
> point at POSITION.

When one is browsing a source repository - the context for the OP, IIRC
- one is most likely visiting unmodified files.  So a question of undo
does arise.

I think if one wants to visit the point where changes were introduced,
one can use

  C-h f highlight-changes-mode

and use the navigation command provided by that mode.



Personally - I mostly work with version controlled files - I use a
combination of

  M-x diff-buffer-with-file 

and use hunks in diff buffer to provide me a map of places that are of
interest to me.
--