Re: Command remapping and the delete-frame problem.

[Stefan Monnier]

> 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