From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: Patch: enhanced mark navigation commands
Date: Tue, 11 Mar 2008 10:08:49 -0500 [thread overview]
Message-ID: <86r6ehqovy.fsf@lifelogs.com> (raw)
In-Reply-To: 87pru2nslr.fsf@jurta.org
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
next prev parent reply other threads:[~2008-03-11 15:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-05 5:12 Patch: enhanced mark navigation commands Adrian Robert
2008-03-05 6:19 ` Miles Bader
2008-03-05 12:23 ` paul r
2008-03-05 6:41 ` Dan Nicolaescu
2008-03-06 0:57 ` Juri Linkov
2008-03-06 1:47 ` Dan Nicolaescu
2008-03-06 7:18 ` Drew Adams
2008-03-06 10:09 ` Juri Linkov
2008-03-09 21:55 ` Juri Linkov
2008-03-05 16:11 ` Ted Zlatanov
2008-03-05 19:20 ` Stefan Monnier
2008-03-05 19:48 ` Ted Zlatanov
2008-03-05 22:10 ` Miles Bader
2008-03-10 13:09 ` Ted Zlatanov
2008-03-10 22:34 ` Juri Linkov
2008-03-11 15:08 ` Ted Zlatanov [this message]
2008-03-06 0:54 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86r6ehqovy.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).