Re: Command remapping and the delete-frame problem.

Re: Command remapping and the delete-frame problem.

[Kim F. Storm]

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.

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.  

The changes are very small, so I expect to commit them later this
evening.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


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

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



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

Re: Command remapping and the delete-frame problem.

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > 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)

The main reason for allowing the symbol name in the first place was
that it is marginally more efficient in command_loop_1 to call
Fkey_binding and thus Flookup_key with a symbol name (the command
found by read_key_sequence), rather than building a 2-element vector
[command CMD] and using that to call Fkey_binding.

But I agree this is not clean, so I'll change that as well.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


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

Re: Command remapping and the delete-frame problem.

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > 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)
> 
> The main reason for allowing the symbol name in the first place was
> that it is marginally more efficient in command_loop_1 to call
> Fkey_binding and thus Flookup_key with a symbol name (the command
> found by read_key_sequence), rather than building a 2-element vector
> [command CMD] and using that to call Fkey_binding.

As RMS suggested, we can pre-build a 2-element vector and always use
that same one, so the loop still doesn't need to allocate.


	Stefan


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

Re: Command remapping and the delete-frame problem.

[Richard Stallman]

    Are you now saying that remapping should have been implemented
    using a specific `command' prefix like this: 

	    (define-key map [command command1] 'command2)

I am not sure about that.  I was talking about what should go in the
keymap data structure.


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

Re: Command remapping and the delete-frame problem.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Are you now saying that remapping should have been implemented
>     using a specific `command' prefix like this: 
> 
> 	    (define-key map [command command1] 'command2)
> 
> I am not sure about that.  I was talking about what should go in the
> keymap data structure.

I have just reworked my original patch for command remapping to use
a `remap' prefix-key for command remapping:

 	    (define-key map [remap command1] 'command2)

Please read the updated section in NEWS.

This removes the ambiguity between commands and event symbols, 
and it has the added bonus of removing some of the limitations
on the previous implementation.  Specifically, a command can now be
remapped into anything accepted by define-key (not just another
command).  I think the new method is much cleaner.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


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

Re: Command remapping and the delete-frame problem.

[Tak Ota]

24 Feb 2002 01:41:11 +0100: storm@cua.dk (Kim F. Storm) wrote:

> I have just reworked my original patch for command remapping to use
> a `remap' prefix-key for command remapping:
> 
>  	    (define-key map [remap command1] 'command2)
> 
> Please read the updated section in NEWS.

I just started rewriting table.el to use the new command remapping
mechanism in place of function advising.  In that process I came up
with a request and a question.

1. Could you add the explanation about the new notation [remap
   command] for KEY argument in `define-key' document?

2. I tried the new remap notation in 21.1.90 and it was simply ignored
   without an error therefore condition-case can't test the
   availability of this feature.  There is no (provide 'command-remap)
   either.  How can a program determine the availability of the new
   feature?  I want to leave function advise for the older versions
   of emacs that does not have command remap feature.

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

Re: Command remapping and the delete-frame problem.

[Richard Stallman]

    2. I tried the new remap notation in 21.1.90 and it was simply ignored
       without an error therefore condition-case can't test the
       availability of this feature.  There is no (provide 'command-remap)
       either.  How can a program determine the availability of the new
       feature?  I want to leave function advise for the older versions
       of emacs that does not have command remap feature.

The version we install in Emacs should have only the command
remapping.  It should not have the advice.  To include the advice
would be clutter and it would make the package harder to maintain, and
it would not help users at all.

As for people using older Emacs versions, they can use your old
version of the file.  There is no reason for the new version of
table.el to support advice.



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

Re: Command remapping and the delete-frame problem.

[Tak Ota]

Mon, 4 Mar 2002 16:41:00 -0700 (MST): Richard Stallman <rms@gnu.org> wrote:

> The version we install in Emacs should have only the command
> remapping.  It should not have the advice.  To include the advice
> would be clutter and it would make the package harder to maintain, and
> it would not help users at all.
> 
> As for people using older Emacs versions, they can use your old
> version of the file.  There is no reason for the new version of
> table.el to support advice.

OK.  I agree.

-Tak

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