Patch: enhanced mark navigation commands

Patch: enhanced mark navigation commands

[Adrian Robert]

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

The attached lisp allows moving around within a buffer or buffers to
places where recent edits or other events took place.  It has been
part of Emacs.app for a while and users have found it useful; I'd like
to propose it being added to the emacs distribution itself, probably
as part of simple.el.

Specifically, the keys M-p and M-n are bound to move forwards and
backwards through the mark history.  Also, immediately after popping a
global mark, e.g., with C-x C-SPC, then the global mark ring is used.

-Adrian

[-- Attachment #2: ns-mark-nav.el --]
[-- Type: application/octet-stream, Size: 2409 bytes --]

;;; ns-mark-nav.el -- mark navigation commands for Emacs

;; Copyright (C) 2005, 2006, 2007
;;        Free Software Foundation, Inc.

;; Author: Adrian Robert (arobert@cogsci.ucsd.edu)
;;         Andrew L. Moore (slewsys@mac.com)

;; This file is part of Emacs.app

;;; Commentary:

;; Support for moving backwards and forwards in the so-called "mark ring".

;; After you load this file, the keys M-p and M-n will move forwards and
;; backwards through the mark history respectively.
;; Generally this is the buffer-local mark ring, but immediately after popping
;; a global mark, e.g., with C-x C-SPC, then the global mark ring is used.

(defvar mark-ring-order 'backward
  "The order in which marks in the current buffer's mark-ring are visited,
either `forward' or `backward' (the default).")
(make-variable-buffer-local 'mark-ring-traversal)
(put 'mark-ring-traversal 'permanent-local t)

(defvar global-mark-ring-order 'backward
  "The order in which marks in the global-mark-ring are visited,
either `forward' or `backward' (the default).")

(defmacro ns-set-mark (ring ring-order order nth)
  "Visit nth mark in ring in ring-order, which is set to order."
  `(progn
     (setq this-command 'set-mark-command)
     (if (not (equal ,ring-order ,order))
	 (progn
	   (setq ,ring-order ,order)
	   (setq ,ring (reverse ,ring))))
     (while (> ,nth 0)
       (setq ,nth (1- ,nth))
       (set-mark-command (eq ,ring mark-ring)))))

(defun ns-pop-mark (order nth)
  "Go to `nth' next/previous mark, depending on whether `direction' is
'forward or 'backward, respectively."
  (if (eq last-command 'pop-global-mark)
      (ns-set-mark global-mark-ring global-mark-ring-order order nth)
    (ns-set-mark mark-ring mark-ring-order order nth)))

;; Main commands
(defun ns-prev-mark (nth)
  "Go to current mark, push it onto mark-ring and pop previous mark.
With prefix argument, nth, go to nth previous mark.
For full description, see `set-mark-command' command."
  (interactive "p")
  (ns-pop-mark 'backward nth))

(defun ns-next-mark (nth)
  "Go to current mark, push it onto mark-ring and pop next mark.
With prefix argument, nth, go to nth next mark.
For full description, see `set-mark-command' command."
  (interactive "p")
  (ns-pop-mark 'forward nth))

;; Keybindings
(global-set-key [(meta p)] 'ns-prev-mark)
(global-set-key [(meta n)] 'ns-next-mark)

(provide 'ns-mark-nav)

;;; mark-nav.el ends here

Re: Patch: enhanced mark navigation commands

[Miles Bader]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:
> Specifically, the keys M-p and M-n are bound to move forwards and
> backwards through the mark history.  Also, immediately after popping a
> global mark, e.g., with C-x C-SPC, then the global mark ring is used.

GIven that M-n and M-p are widely used bindings, I don't think you'll
win many fans by adding global bindings for them, unless the new
bindings clearly don't conflict or interact in strange ways with other
uses.

For instance, comint uses M-n and M-p; is the new functionality not
useful in comint buffers?  Also, given the possibility for moving
between buffers (with global marks), it would be very disconcerting if,
a user was repeatedly hitting, say M-n, and suddenly things "stopped
working" as soon as he popped into a comint (etc) buffer.

Gnus is another heavy user of M-n/M-p.

-Miles

-- 
White, adj. and n. Black.

Re: Patch: enhanced mark navigation commands

[paul r]

> GIven that M-n and M-p are widely used bindings, I don't think you'll
> win many fans by adding global bindings for them, unless the new
> bindings clearly don't conflict or interact in strange ways with other
> uses.


M-n and M-p are also usefull and intuitive as forward-paragraph and
backward-paragraph.

I take this opportunity to propose something. It is clear that we all
must make choices on how to bind quick shortcuts. Usually, one wants a
simple and quick shortcut for operations (s)he does a lot. Of course,
if Adrian wants to jump 4 marks backward, he does not want to type,
for instance, C-x M-m p ( which would mean command - mark - previous )
4 times.
Given they are good chances that he would hit the keybinding 4 times
in a row, without doing any other operation in the middle, one could
take advantage of this special pattern, by letting him hit only 'p' as
long as he wants to keep jumping. This is exactly the behaviour of C-x
e and I find it very cleaver. Loop breaks when any other key it hit.
AFAIK, there is no common practice to make this kind of keybinding, at
least yet. That's why I use the following few lines that are rather
ugly but work well :

;;;; Auto-repeat any command by pressing last shortcut key
(defun auto-repeat-command (command)
 (let ((repeat-repeat-char
        (when (eq last-command-char
                  last-command-event)
          last-command-char)))
   (call-interactively command)
   (while (eq (read-event) repeat-repeat-char)
     ;; Make each repetition undo separately.
     (auto-repeat-command command)
     (setq unread-command-events (list last-input-event)))))


Then, mark jumping can be bound this way :

(global-set-key "\C-x\M-mn" (lambda () (interactive)
                            (auto-repeat-command 'marker-visit-next)))
(global-set-key "\C-x\M-mp" (lambda () (interactive)
                            (auto-repeat-command 'marker-visit-prev)))


Please understand I'm not proposing any particular implementation, but
only something I consider as a desirable behaviour that could be
encouraged when bindings functions that are likely to be called
several times in a row.
Hoping I was clear and used not-too-bad english,

-- paul

Re: Patch: enhanced mark navigation commands

[Dan Nicolaescu]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

  > The attached lisp allows moving around within a buffer or buffers to
  > places where recent edits or other events took place.  It has been
  > part of Emacs.app for a while and users have found it useful; I'd like
  > to propose it being added to the emacs distribution itself, probably
  > as part of simple.el.

Eclipse has a tool-bar button that provides very similar functionality,
you might want to consider adding something like that in case this gets
approved.

Re: Patch: enhanced mark navigation commands

[Juri Linkov]

>   > The attached lisp allows moving around within a buffer or buffers to
>   > places where recent edits or other events took place.  It has been
>   > part of Emacs.app for a while and users have found it useful; I'd like
>   > to propose it being added to the emacs distribution itself, probably
>   > as part of simple.el.
>
> Eclipse has a tool-bar button that provides very similar functionality,
> you might want to consider adding something like that in case this gets
> approved.

Do you mean that after going to a line by its number it allows
returning back to its old position later by typing M-left and forward
by M-right?

BTW, in Emacs `goto-line' doesn't push the mark to the mark ring.
I think it should since often it is used to for long distance
navigation.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Patch: enhanced mark navigation commands

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >   > The attached lisp allows moving around within a buffer or buffers to
  > >   > places where recent edits or other events took place.  It has been
  > >   > part of Emacs.app for a while and users have found it useful; I'd like
  > >   > to propose it being added to the emacs distribution itself, probably
  > >   > as part of simple.el.
  > >
  > > Eclipse has a tool-bar button that provides very similar functionality,
  > > you might want to consider adding something like that in case this gets
  > > approved.
  > 
  > Do you mean that after going to a line by its number it allows
  > returning back to its old position later by typing M-left and forward
  > by M-right?

No, there was no mention of M-{left,right}, just of a tool-bar button. 
No, it's not only about going to a line by its number, but something
very similar to the proposed functionality.

RE: Patch: enhanced mark navigation commands

[Drew Adams]

FWIW, in Icicles you can navigate among the markers in a buffer or among
global markers, in any order.

While doing that, you can complete against the text on each marker's line
(or "<EMPTY LINE>"): each completion candidate is an alist entry (line-text
. marker). More typically, however, you cycle among the markers or click
them in *Completions* with the mouse. You can cycle in either direction, and
you need not visit each marker in sequence (direct access or skip some).

You can sort the candidate marker list in various ways - by default, the
candidates are in marker order (i.e. buffer position). If unsorted, they are
in chronological order, i.e., mark-ring insertion order. Hit a key to change
the sort order - you can have any number of orders.

You can filter the set of candidate markers by matching (or
complement-matching) your minibuffer input against each marker's line. When
you visit a marker, its line is highlighted temporarily. It is a bit like a
dynamic `occur' command (change your input on the fly and it changes the
matching candidates), but an `occur' where the lines are only those with
markers and each marker has a line (candidate).

This all falls out for free by using the general function (command)
`icicle-map' to define the navigating commands (`icicle-goto-marker' and
`icicle-goto-global-marker'). Those definitions are trivial. `icicle-map'
applies a function to alist-entry completion candidates that are chosen
interactively, e.g. by cycling.

In the case of the marker-navigator commands, the function applied by
`icicle-map' just goes to the chosen marker candidate and highlights its
line:

(defun goto-and-highlight (cand)
  (pop-to-buffer (marker-buffer (cdr cand)))
  (goto-char (cdr cand))
  (setq mark-active nil)
  (let ((hl-line-flash-show-period 60)) (hl-line-flash)))
  (point-marker))))) ; Return marker at point, for message.

The complete definition of `icicle-go-to-marker is this (plus some bindings
for sort functions and an error message if no markers):

(defun icicle-goto-marker ()
  "Go to a marker in this buffer."
  (interactive)
  (icicle-map (mapcar #'icicle-marker+text
                      (icicle-markers mark-ring))
              #'goto-and-highlight)))

Function `icicle-marker+text' just creates an alist entry (completion
candidate) using the text of a marker's line as car and the marker as cdr.
Function `icicle-markers' just filters the `mark-ring' for live buffers,
excluding the minibuffer.

You can use `icicle-map' to define a command to traverse any alist, doing
anything you want to the entries. The user picks the entries to act on, in
the ways mentioned above (filter, sort, cycle, complete, choose directly).
The user can act on candidates repeatedly and in any order.

`icicle-map' and commands such as `icicle-goto-marker' that you define using
it are multi-commands. It is that that lets a user choose multiple
completion candidates (e.g. cycle among them) in a single command
invocation.

Re: Patch: enhanced mark navigation commands

[Juri Linkov]

>   > > Eclipse has a tool-bar button that provides very similar functionality,
>   > > you might want to consider adding something like that in case this gets
>   > > approved.
>   >
>   > Do you mean that after going to a line by its number it allows
>   > returning back to its old position later by typing M-left and forward
>   > by M-right?
>
> No, there was no mention of M-{left,right}, just of a tool-bar button.
> No, it's not only about going to a line by its number, but something
> very similar to the proposed functionality.

As I see, these are two separate features: M-left/M-right to navigate
between positions that were recorded after long distance jumps like
`Go to line', and tool-bar buttons to navigate between last edits.
The latter is different in Emacs since positions of last edits
are stored only in the undo list, not in the mark ring.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Patch: enhanced mark navigation commands

[Juri Linkov]

> BTW, in Emacs `goto-line' doesn't push the mark to the mark ring.
> I think it should since often it is used to for long distance
> navigation.

The following patch fixes this:

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.904
diff -c -r1.904 simple.el
*** lisp/simple.el	3 Mar 2008 02:16:00 -0000	1.904
--- lisp/simple.el	9 Mar 2008 21:54:38 -0000
***************
*** 820,829 ****
  
  (defun goto-line (arg &optional buffer)
    "Goto line ARG, counting from line 1 at beginning of buffer.
! Normally, move point in the current buffer.
! With just \\[universal-argument] as argument, move point in the most recently
! displayed other buffer, and switch to it.  When called from Lisp code,
! the optional argument BUFFER specifies a buffer to switch to.
  
  If there's a number in the buffer at point, it is the default for ARG."
    (interactive
--- 820,830 ----
  
  (defun goto-line (arg &optional buffer)
    "Goto line ARG, counting from line 1 at beginning of buffer.
! Normally, move point in the current buffer and leave mark at previous
! position.  With just \\[universal-argument] as argument, move point
! in the most recently displayed other buffer, and switch to it.
! When called from Lisp code, the optional argument BUFFER specifies
! a buffer to switch to.
  
  If there's a number in the buffer at point, it is the default for ARG."
    (interactive
***************
*** 860,865 ****
--- 861,869 ----
        (let ((window (get-buffer-window buffer)))
  	(if window (select-window window)
  	  (switch-to-buffer-other-window buffer))))
+   ;; Leave mark at previous position
+   (or (and transient-mark-mode mark-active)
+       (push-mark))
    ;; Move to the specified line number in that buffer.
    (save-restriction
      (widen)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Patch: enhanced mark navigation commands

[Ted Zlatanov]

On Wed, 5 Mar 2008 08:12:35 +0300 "Adrian Robert" <adrian.b.robert@gmail.com> wrote: 

AR> The attached lisp allows moving around within a buffer or buffers to
AR> places where recent edits or other events took place.  It has been
AR> part of Emacs.app for a while and users have found it useful; I'd like
AR> to propose it being added to the emacs distribution itself, probably
AR> as part of simple.el.

AR> Specifically, the keys M-p and M-n are bound to move forwards and
AR> backwards through the mark history.  Also, immediately after popping a
AR> global mark, e.g., with C-x C-SPC, then the global mark ring is used.

Would next-error and previous-error (which are useful for any motion to
"points of interest" and have aliases defined accordingly) be
appropriate here?  They already handle occur-mode, grep-mode, and
compilation-mode point of interest, and the intent is to provide a DWIM
interface.

It makes sense that if any of those three modes are not on, next-error
and previous-error should move to recent edit points.  If one of those
modes is on, we can provide an override, but I expect users to be happy
with the default behavior as I describe it.  What do you think?

Ted

Re: Patch: enhanced mark navigation commands

[Stefan Monnier]

AR> The attached lisp allows moving around within a buffer or buffers to
AR> places where recent edits or other events took place.  It has been
AR> part of Emacs.app for a while and users have found it useful; I'd like
AR> to propose it being added to the emacs distribution itself, probably
AR> as part of simple.el.

AR> Specifically, the keys M-p and M-n are bound to move forwards and
AR> backwards through the mark history.  Also, immediately after popping a
AR> global mark, e.g., with C-x C-SPC, then the global mark ring is used.

The functionality looks interesting.  But there are a few problems with it:

- loading the file alters the behavior of Emacs.  The `global-set-key'
  calls should be moved out of the top-level, e.g. into a minor-mode.
- it seems to do some funny dances with the mark-ring and global-mark-ring
  (including reversing them), so I'm not sure the interaction with things
  like C-u C-SPC will be right.
- this last point really means that maybe this should be more closely
  integrated into existing functionality such as C-u C-SPC.  After all,
  C-u C-SPC (and/or C-x C-SPC) offers basically the functionality of
  your `ns-prev-mark' (especially together with
  set-mark-command-repeat-pop).  So all we need is a way to provide
  ns-next-mark.  If the main/only use of ns-next-mark is to undo an
  excessive use of ns-prev-mark, then maybe C-u could be used to
  change the direction in a series of C-SPC:
  C-u C-SPC C-SPC C-SPC ... oh no too far ... C-u C-SPC

> Would next-error and previous-error (which are useful for any motion to
> "points of interest" and have aliases defined accordingly) be
> appropriate here?  They already handle occur-mode, grep-mode, and
> compilation-mode point of interest, and the intent is to provide a DWIM
> interface.

> It makes sense that if any of those three modes are not on, next-error
> and previous-error should move to recent edit points.  If one of those
> modes is on, we can provide an override, but I expect users to be happy
> with the default behavior as I describe it.  What do you think?

And then as soon as you run grep, diff, or compile, the feature just
can't be used any more?  Doesn't sound too good to me,


        Stefan

Re: Patch: enhanced mark navigation commands

[Ted Zlatanov]

On Wed, 05 Mar 2008 14:20:23 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Would next-error and previous-error (which are useful for any motion to
>> "points of interest" and have aliases defined accordingly) be
>> appropriate here?  They already handle occur-mode, grep-mode, and
>> compilation-mode point of interest, and the intent is to provide a DWIM
>> interface.

>> It makes sense that if any of those three modes are not on, next-error
>> and previous-error should move to recent edit points.  If one of those
>> modes is on, we can provide an override, but I expect users to be happy
>> with the default behavior as I describe it.  What do you think?

SM> And then as soon as you run grep, diff, or compile, the feature just
SM> can't be used any more?  Doesn't sound too good to me,

I think it's possible to make this useful with navigation layers.

Layers 0-9 reserved for char/word/paragraph/page/etc motion
Layer 10: edits (what Adrian Robert's patch provides)
Layer 11: tags (ctags, etags, etc.); function/variable definitions
Layer 12: grep/diff/compile/occur points
Layer 13: buffers (like cycle-buffer)
Layer 14: Gnus articles or dired files or other bundles of information
Layer 15: Gnus groups (or other aggregators for layer 14)
Layer 16: Gnus topics (or other aggregators for layer 15)

Layers 10 and 11 may have to be swapped.  We may think of more layers,
and what I've listed above is just an idea.  The point is that we'll
give the user a way to move back and forth between things that are
interesting.  Selecting the motion layer can be done in some standard
way, e.g. next-error--10 or whatever makes sense.  I also don't know if
numerical layers will work as a concept, but they seem simple to
understand and configure.

Ted

Re: Patch: enhanced mark navigation commands

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> I think it's possible to make this useful with navigation layers.
>
> Layers 0-9 reserved for char/word/paragraph/page/etc motion
> Layer 10: edits (what Adrian Robert's patch provides)
> Layer 11: tags (ctags, etags, etc.); function/variable definitions
> Layer 12: grep/diff/compile/occur points
> Layer 13: buffers (like cycle-buffer)
> Layer 14: Gnus articles or dired files or other bundles of information
> Layer 15: Gnus groups (or other aggregators for layer 14)
> Layer 16: Gnus topics (or other aggregators for layer 15)
>
> Layers 10 and 11 may have to be swapped.  We may think of more layers,
> and what I've listed above is just an idea.  The point is that we'll
> give the user a way to move back and forth between things that are
> interesting.

To be honest, it sounds maddeningly annoying...

-Miles

-- 
Defenceless, adj. Unable to attack.

Re: Patch: enhanced mark navigation commands

[Ted Zlatanov]

On Thu, 06 Mar 2008 07:10:25 +0900 Miles Bader <miles@gnu.org> wrote: 

MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think it's possible to make this useful with navigation layers.
>> 
>> Layers 0-9 reserved for char/word/paragraph/page/etc motion
>> Layer 10: edits (what Adrian Robert's patch provides)
>> Layer 11: tags (ctags, etags, etc.); function/variable definitions
>> Layer 12: grep/diff/compile/occur points
>> Layer 13: buffers (like cycle-buffer)
>> Layer 14: Gnus articles or dired files or other bundles of information
>> Layer 15: Gnus groups (or other aggregators for layer 14)
>> Layer 16: Gnus topics (or other aggregators for layer 15)
>> 
>> Layers 10 and 11 may have to be swapped.  We may think of more layers,
>> and what I've listed above is just an idea.  The point is that we'll
>> give the user a way to move back and forth between things that are
>> interesting.

MB> To be honest, it sounds maddeningly annoying...

After thinking about it, you're right.  I still think there's a need for
more unified navigation commands than the hodge-podge we have in Emacs
now, but this is not the way to do it.

Ted

Re: Patch: enhanced mark navigation commands

[Juri Linkov]

>>> I think it's possible to make this useful with navigation layers.
>>>
>>> Layers 0-9 reserved for char/word/paragraph/page/etc motion
>>> Layer 10: edits (what Adrian Robert's patch provides)
>>> Layer 11: tags (ctags, etags, etc.); function/variable definitions
>>> Layer 12: grep/diff/compile/occur points
>>> Layer 13: buffers (like cycle-buffer)
>>> Layer 14: Gnus articles or dired files or other bundles of information
>>> Layer 15: Gnus groups (or other aggregators for layer 14)
>>> Layer 16: Gnus topics (or other aggregators for layer 15)
>>>
>>> Layers 10 and 11 may have to be swapped.  We may think of more layers,
>>> and what I've listed above is just an idea.  The point is that we'll
>>> give the user a way to move back and forth between things that are
>>> interesting.
>
> MB> To be honest, it sounds maddeningly annoying...
>
> After thinking about it, you're right.  I still think there's a need for
> more unified navigation commands than the hodge-podge we have in Emacs
> now, but this is not the way to do it.

I doubt that it is possible to build a hierarchy of context-dependent
navigation layers.  Do you remember how many problems were caused by
just two levels of next-error navigation (when next-error from
the grep buffer arrives at a diff output file, what the next call
to next-error should do: continue visiting grep matches or start
visiting diff hunks)?

What would be more useful I think is to find a unified key prefix for
navigation commands.  For instance, `M-g e M-n' would go to the next
error, `M-g t M-n' - to the next tag, `M-g d f M-n' - to the next diff
file in the diff buffer `M-g d h M-n' - to the next diff hunk in the
diff buffer, etc.

Of course, sometimes this might be too much to type, but for every
next call we could just accept the last key (similar to `C-x z z z')
to repeat the last command like `M-g e M-n M-n M-n'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Patch: enhanced mark navigation commands

[Ted Zlatanov]

On Tue, 11 Mar 2008 00:34:32 +0200 Juri Linkov <juri@jurta.org> wrote: 
JL> Ted Z wrote:
>> After thinking about it, you're right.  I still think there's a need for
>> more unified navigation commands than the hodge-podge we have in Emacs
>> now, but this is not the way to do it.

JL> I doubt that it is possible to build a hierarchy of context-dependent
JL> navigation layers.  

Right, that's what I realized when I thought about my suggestion.

What's needed is a standard way of navigating that every mode can
install quickly and without writing much code.  You call
(emacs-standard-keys-install 'my-mode-keymap) and everything Just
Works.  But this is a hard problem that should be solved only if the
Emacs maintainers agree it's a problem, since fixing it will require
changes to many packages and keybindings.

This is related to the discussion on shifted keys and CUA modes.  IMHO,
motion should be an Emacs standard, and each mode should only customize
the things you can navigate, but not the navigation keys themselves.

Then users could set up the navigation preferences they want and have
them work everywhere.

JL> Do you remember how many problems were caused by just two levels of
JL> next-error navigation (when next-error from the grep buffer arrives
JL> at a diff output file, what the next call to next-error should do:
JL> continue visiting grep matches or start visiting diff hunks)?

Yes, I remember.  DWIM is always harder than it looks.

JL> What would be more useful I think is to find a unified key prefix for
JL> navigation commands.  For instance, `M-g e M-n' would go to the next
JL> error, `M-g t M-n' - to the next tag, `M-g d f M-n' - to the next diff
JL> file in the diff buffer `M-g d h M-n' - to the next diff hunk in the
JL> diff buffer, etc.

JL> Of course, sometimes this might be too much to type, but for every
JL> next call we could just accept the last key (similar to `C-x z z z')
JL> to repeat the last command like `M-g e M-n M-n M-n'.

I agree this should be done in a standard way, maybe the way you
describe.

Ted

Re: Patch: enhanced mark navigation commands

[Juri Linkov]

> The attached lisp allows moving around within a buffer or buffers to
> places where recent edits or other events took place.  It has been
> part of Emacs.app for a while and users have found it useful; I'd like
> to propose it being added to the emacs distribution itself, probably
> as part of simple.el.
>
> Specifically, the keys M-p and M-n are bound to move forwards and
> backwards through the mark history.  Also, immediately after popping a
> global mark, e.g., with C-x C-SPC, then the global mark ring is used.

I used to have a similar feature in .emacs which I'd like to
demonstrate here just for reference:

(defun my-sorted-marks ()
  "Returns marks of the current buffer sorted by position."
  (sort (copy-list mark-ring)
        (lambda (m1 m2) (< (marker-position m1) (marker-position m2)))))

(defun my-mark-prev ()
  "Jump to the previous mark."
  (interactive)
  (let ((marks (reverse (my-sorted-marks))) m)
    (while (car marks)
      (if (< (marker-position (car marks)) (point))
          (setq m (car marks) marks nil)
        (setq marks (cdr marks))))
    (if m (goto-char m))))
(define-key global-map [(meta up)] 'my-mark-prev)

(defun my-mark-next ()
  "Jump to the next mark."
  (interactive)
  (let ((marks (my-sorted-marks)) m)
    (while (car marks)
      (if (> (marker-position (car marks)) (point))
          (setq m (car marks) marks nil)
        (setq marks (cdr marks))))
    (if m (goto-char m))))
(define-key global-map [(meta down)] 'my-mark-next)

It navigated marks spatially (by the order of buffer positions),
not temporally (by the order of adding marks to the mark ring).
But it turned out to be quite useless.

OTOH commands like you proposed would be more useful.  But they
are too intrusive.  I think it would be better to have two
commands `goto-prev-mark' and `goto-next-mark' that just move point
to the positions of marks in the mark ring without modifying it
(by using some global pointer for the current position in it).

-- 
Juri Linkov
http://www.jurta.org/emacs/