From: Richard Stallman <rms@gnu.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: bypassing defining prefix keys
Date: Mon, 05 Feb 2007 14:10:07 -0500 [thread overview]
Message-ID: <E1HE9E7-0005ZH-My@fencepost.gnu.org> (raw)
In-Reply-To: <BDEIJAFNGDOAGCJIPKPBAEGJCCAA.drew.adams@oracle.com>
(define-key dired-mode-map "*" nil)
(define-key dired-mode-map "*/" 'dired-mark-directories)
...
This explains the behavior I get, but I wonder if `*' and `%' should be
defined this way. Is there a guideline or policy on this? Obviously, it
would be better for my key-completion code if `*' and `%' were defined as
real prefix keys.
Actually this DOES define them as prefix keys; this is a valid way to
do so. The other method is to define it as a symbol and give the
symbol the submap as a function definition.
It seems your completion command works with one method of doing so and
not with the other. But it could handle both.
;; Make all regexp commands share a `%' prefix:
;; We used to get to the submap via a symbol dired-regexp-prefix,
;; but that seems to serve little purpose, and copy-keymap
;; does a better job without it.
I don't understand the part about `copy-keymap' (which is not used in
dired.el, in any case). What is the `copy-keymap' limitation that is hinted
at here?
I think it is this: with a symbol in the way, `copy-keymap' won't copy
that symbol (since an interned symbol is unique), nor whatever map it
points to. With no symbol, it will recursively copy the submap.
Why it should be relevant here, I am not sure. Maybe some other mode does
(or did) `copy-keymap' on `dired-mode-map'.
prev parent reply other threads:[~2007-02-05 19:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-04 19:58 bypassing defining prefix keys Drew Adams
2007-02-04 21:19 ` Andreas Schwab
2007-02-04 21:27 ` Drew Adams
2007-02-04 22:03 ` Andreas Schwab
2007-02-04 22:19 ` Drew Adams
2007-02-05 19:10 ` Richard Stallman [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1HE9E7-0005ZH-My@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=drew.adams@oracle.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.