emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: enhanced mark navigation commands


From: Stefan Monnier
Subject: Re: Patch: enhanced mark navigation commands
Date: Wed, 05 Mar 2008 14:20:23 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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




reply via email to

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