[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Command remapping and the delete-frame problem.
From: |
Stefan Monnier |
Subject: |
Re: Command remapping and the delete-frame problem. |
Date: |
Fri, 22 Feb 2002 11:24:14 -0500 |
> Earlier today, I wrote:
> >
> > Are you now saying that remapping should have been implemented
> > using a specific `command' prefix like this:
> >
> > (define-key map [command command1] 'command2)
> >
> > I can see that this is better than the current implementation as it
> > makes a clear destinction (in the keymaps) between commands and other
> > symbols like those used on the menu-bar, and a few symbols which are
> > both commands and keys (e.g. `undo').
> >
> > All of this makes a lot of sense -- should I go back and change the
> > implementation to use an explicit `command' prefix for command
> > remapping?
>
> Actually, I went ahead an made the changes in a fully transparent way.
> This means that internally, remapping command FOO to BAR is stored as
> a binding for [command FOO], i.e. the "event" `command' is bound to a
> keymap in which FOO is mapped to BAR.
Good. The delete-frame bug was that C-x 5 0 was bount to the
command `delete-frame' and that there is a `delete-frame' event
which is bound to `handle-delete-frame', so with the remapping
C-x 5 0 found itself suddenly remapped to `handle-delete-frame' (which
burped because it didn't expect to be bound to a key sequence).
> But the interface to define-key, lookup-key and key-binding hasn't
> changed. They just take FOO as the KEY argument - which is still an
> unambuguous way to represent command remapping, as those functions
> don't otherwise accept a symbol as the KEY argument.
That now sounds like a hack and I don't think it's worth keeping it.
Especially since it's not compatible with the XEmacs hack where
a non-vector argument passed to one of those functions is interpreted
the same as a length-1 vector so you can
(define-key 'button1 'command)
instead of
(define-key [button1] 'command)
which is itself a shorthand for
(define-key [(button1)] 'command)
-- Stefan