all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Question on remapping keys
Date: Mon, 16 Jan 2006 09:46:10 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICKEIGDBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <yoijek397wo4.fsf@linus003.dd.chalmers.se>

    >      (define-key map [remap `,from] to)
                           `[remap ,from]

Right. Thanks, Johan, but that doesn't completely solve the problem. The
result of remapping is this for minibuffer-local-completion-map:

(keymap
 ...
 (remap keymap
        (scroll-left . my-scroll-left)
        (scroll-right . my-scroll-right)
        (scroll-down . my-scroll-down)
        (scroll-up . my-scroll-up)
        (next-line . my-next-line)
        (previous-line . my-previous-line)
        (help-command . my-help)
        (self-insert-command . my-self-insert))
 ...)

This looks promising, but it seems to work only partially. For instance,

(where-is-internal 'my-scroll-up
                   (list minibuffer-local-completion-map))

returns ([remap scroll-up]), which looks good. `M-x' followed by `C-v' does
invoke `my-scroll-up', but `M-x' followed by [next] (also bound to
`scroll-up' in `global-map') does not invoke `my-scroll-up' - it invokes
`next-history-element', just as in vanilla Emacs.

IOW, apparently not all bindings of `scroll-up' got remapped. I'm looking
for behavior similar to that of `substitute-key-definition':
remap/substitute _all_ bindings. This is especially important since I
apparently have no control over which single binding gets remapped - that
is, only one binding of the command seems to be remapped, and I don't know
how to pick which one.

Similarly,

(where-is-internal 'my-help
                   (list minibuffer-local-completion-map))

returns ([remap help-command]). That suggests that `help-command' was
remapped, but using `C-h' in the minibuffer does not invoke `my-help'.
(Why?)

If I use `substitute-key-definition', providing `global-map' as the OLDMAP
arg, it works perfectly, but the performance is unacceptable. There must be
some way to do something equivalent using command remapping (?).

  reply	other threads:[~2006-01-16 17:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1249.1137374555.26925.help-gnu-emacs@gnu.org>
2006-01-16  2:07 ` Question on remapping keys Johan Bockgård
2006-01-16 17:46   ` Drew Adams [this message]
2006-01-19 21:30     ` Drew Adams
2006-01-20 23:25       ` Drew Adams
2006-01-16  1:19 Drew Adams

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=DNEMKBNJBGPAOPIJOOICKEIGDBAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /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.