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: Fri, 20 Jan 2006 15:25:45 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICAELBDBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICGEKEDBAA.drew.adams@oracle.com>

I realize that I sent this question only yesterday. Today, I noticed that
code identical to what I use (see `my-remap', below) is used in
`arc-mode.el' and `emerge.el' (and `tramp-util.el' and `picture.el' do
something similar), so it's apparently not a far-out request.

Is this a bug? If not, how can I get remapping to substitute _all_ of a
command's bindings?

Thanks.

P.S. Actually, `emerge.el' does _both_ `substitute-key-definition' and
remapping for the same commands. Is this useful? (Perhaps it has to do with
not using an OLDMAP arg with `substitute-key-definition'?)

----

    I sent this to help-gnu-emacs, but I haven't yet found a solution to the
    problem. I wonder too if there might be a bug here.

    I have a minor mode that redefines some of the minibuffer keymaps (e.g.
    minibuffer-local-completion-map). I want turning on the mode to
    implement the new minibuffer bindings, and turning it off to restore the
    minibuffer bindings of vanilla Emacs.

    In some cases, I reuse key sequences that are bound in the global map,
    binding them to other commands in minibuffer maps. Those are
    the bindings that I have a question about.

    In Emacs 20, I simply do this:

    (substitute-key-definition from to
       minibuffer-local-completion-map global-map)

    For example, to bind `C-h' in the minibuffer to command `my-help':

    (substitute-key-definition 'help-command 'my-help
       minibuffer-local-completion-map global-map)

    I do the same for `self-insert-command', replacing it with
    `my-self-insert' for minibuffer maps.

    This is very fast in Emacs 20, but in Emacs 22 it is unbearably slow. It
    takes about 5 seconds for only 10 such key-definition substitutions!
    I think that the slowness might be due, in particular, to dealing with
    the case of `self-insert-command'.

    Someone (Kim?) suggested that I could use `define-key' with [remap...]
    instead of `substitute-key-definition'. I tried using the
    following when my minor mode is turned on:

    (defun my-remap (from to map)
     "Remap command FROM to command TO in keymap MAP."
     (if (boundp 'this-original-command)
         (define-key map `[remap ,from] to)                 ; Emacs 22
       (substitute-key-definition from to map global-map))) ; Emacs 20

    And similarly when it is turned off, using nil for TO, to
    remove the binding
    from MAP (a minibuffer map). 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
    don't know if this is a bug or by design.

    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
    in Emacs 22. There must be some way to do something equivalent using
    command remapping(?).

    Anyone have a suggestion on how to proceed?



    _______________________________________________
    Emacs-devel mailing list
    Emacs-devel@gnu.org
    http://lists.gnu.org/mailman/listinfo/emacs-devel

  reply	other threads:[~2006-01-20 23:25 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
2006-01-19 21:30     ` Drew Adams
2006-01-20 23:25       ` Drew Adams [this message]
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=DNEMKBNJBGPAOPIJOOICAELBDBAA.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.