`key-binding' and XEmacs-style events

`key-binding' and XEmacs-style events

[Stuart D. Herring]

I have noticed, when writing some automatic key-generation code, that
(key-binding [(?a)]) (or any other character) yields a type error because
?a is not a symbol.  The problem is that at keymap.c:1615, if the
function's argument is a vector and its first element is a cons, it is
assumed that the element is a mouse-like event which is a list started by
a symbol.  This does no particular harm for (key-binding [(control ?a)])
because 'control is merely discovered to have no interesting properties as
an event symbol, but it's a problem in the trivial one-character case.

Obviously (key-binding [?a]) works just as well, but in order to write
code that flexibly manipulates keystrokes it would be nice if the XEmacs
syntax could always be used even in degenerate cases.  I don't claim to
understand events very well, so perhaps I am alone in this opinion, but
this strikes me as a bug.  Thoughts?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: `key-binding' and XEmacs-style events

[Richard Stallman]

    Obviously (key-binding [?a]) works just as well, but in order to write
    code that flexibly manipulates keystrokes it would be nice if the XEmacs
    syntax could always be used even in degenerate cases.

I agree.  Would someone please fix this and ack?

Re: `key-binding' and XEmacs-style events

[Stefan Monnier]

>     Obviously (key-binding [?a]) works just as well, but in order to write
>     code that flexibly manipulates keystrokes it would be nice if the XEmacs
>     syntax could always be used even in degenerate cases.

> I agree.  Would someone please fix this and ack?

AFAIK, [?a] works in XEmacs as well.  It's only when you have modifiers that
the Emacs syntax is not understood by XEmacs.


        Stefan

Re: `key-binding' and XEmacs-style events

[Stuart D. Herring]

>>     Obviously (key-binding [?a]) works just as well, but in order to
>> write
>>     code that flexibly manipulates keystrokes it would be nice if the
>> XEmacs
>>     syntax could always be used even in degenerate cases.
>
>> I agree.  Would someone please fix this and ack?
>
> AFAIK, [?a] works in XEmacs as well.  It's only when you have modifiers
> that
> the Emacs syntax is not understood by XEmacs.

We're talking about going the other way -- supporting (key-binding [(?a)])
in Emacs (I don't know what XEmacs thinks of event-lists with no
modifiers).  The simplest fix seems to be to move the check that the list
is at least two long before the code that uses its first element as a
symbol:

*** keymap.c.~1.345.~	2007-02-08 09:45:05.000000000 -0700
--- keymap.c	2007-03-01 15:26:32.000000000 -0700
***************
*** 1612,1621 ****

        /* We are not interested in locations without event data */

!       if (EVENT_HAS_PARAMETERS (event))
  	{
  	  Lisp_Object kind = EVENT_HEAD_KIND (EVENT_HEAD (event));
! 	  if (CONSP (XCDR (event)) && EQ (kind, Qmouse_click))
  	    position = EVENT_START (event);
  	}
      }
--- 1612,1621 ----

        /* We are not interested in locations without event data */

!       if (EVENT_HAS_PARAMETERS (event) && CONSP (XCDR (event)))
  	{
  	  Lisp_Object kind = EVENT_HEAD_KIND (EVENT_HEAD (event));
! 	  if (EQ (kind, Qmouse_click))
  	    position = EVENT_START (event);
  	}
      }

That will still die on (key-binding [(?a ?b)]), but that's meaningless
anyway.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: `key-binding' and XEmacs-style events

[Kim F. Storm]

"Stuart D. Herring" <herring@lanl.gov> writes:

> We're talking about going the other way -- supporting (key-binding [(?a)])
> in Emacs 

Yes, but we don't have to fix it.

If you want to write portable code, simply use the GNU Emacs format [?a],
as this is also supported by XEmacs.

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

Re: `key-binding' and XEmacs-style events

[Stuart D. Herring]

>> We're talking about going the other way -- supporting (key-binding
>> [(?a)])
>> in Emacs
>
> Yes, but we don't have to fix it.
>
> If you want to write portable code, simply use the GNU Emacs format [?a],
> as this is also supported by XEmacs.

What I am actually interested in can be seen at
http://www.emacswiki.org/cgi-bin/wiki/unbound.el: this code mechanically
manipulates keystrokes.  By far the easiest way to do this is to generate
XEmacs lists with modifiers and base events, rather than having to
generate the symbol 'C-end and the low-ASCII ?\C-a and the high-bit-set
?\C-` with separate rules.  Then the natural way of representing an
unmodified key is a list containing 0 modifiers and the base event, but
that fails (for `key-binding' only; `lookup-key' and `define-key' accept
it) because it doesn't happen to begin with a symbol.

Obviously it is possible to detect the case of an unmodified event and
emit a non-list for it, but it makes the code needlessly more complex.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: `key-binding' and XEmacs-style events

[Richard Stallman]

    AFAIK, [?a] works in XEmacs as well.  It's only when you have modifiers that
    the Emacs syntax is not understood by XEmacs.

I quoted the wrong part of his message.  This is the actual bug:

    I have noticed, when writing some automatic key-generation code, that
    (key-binding [(?a)]) (or any other character) yields a type error because
    ?a is not a symbol.  The problem is that at keymap.c:1615, if the
    function's argument is a vector and its first element is a cons, it is
    assumed that the element is a mouse-like event which is a list started by
    a symbol.

Would someone please fix this, then ack?

Re: `key-binding' and XEmacs-style events

[Richard Stallman]

    We're talking about going the other way -- supporting (key-binding [(?a)])
    in Emacs (I don't know what XEmacs thinks of event-lists with no
    modifiers).  The simplest fix seems to be to move the check that the list
    is at least two long before the code that uses its first element as a
    symbol:

Would someone please install your patch?

Re: `key-binding' and XEmacs-style events

[David Kastrup]

"Stuart D. Herring" <herring@lanl.gov> writes:

> We're talking about going the other way -- supporting (key-binding [(?a)])
> in Emacs (I don't know what XEmacs thinks of event-lists with no
> modifiers).  The simplest fix seems to be to move the check that the list
> is at least two long before the code that uses its first element as a
> symbol:
>
> *** keymap.c.~1.345.~	2007-02-08 09:45:05.000000000 -0700
> --- keymap.c	2007-03-01 15:26:32.000000000 -0700
> ***************
> *** 1612,1621 ****
>
>         /* We are not interested in locations without event data */
>
> !       if (EVENT_HAS_PARAMETERS (event))
>   	{
>   	  Lisp_Object kind = EVENT_HEAD_KIND (EVENT_HEAD (event));
> ! 	  if (CONSP (XCDR (event)) && EQ (kind, Qmouse_click))
>   	    position = EVENT_START (event);
>   	}
>       }
> --- 1612,1621 ----
>
>         /* We are not interested in locations without event data */
>
> !       if (EVENT_HAS_PARAMETERS (event) && CONSP (XCDR (event)))
>   	{
>   	  Lisp_Object kind = EVENT_HEAD_KIND (EVENT_HEAD (event));
> ! 	  if (EQ (kind, Qmouse_click))
>   	    position = EVENT_START (event);
>   	}
>       }
>
> That will still die on (key-binding [(?a ?b)]), but that's meaningless
> anyway.

As the one who has been responsible for that piece of code originally:
it more or less tried to use enough clues to figure out the right
meaning of a sequence.  These tests fall short of completely
guaranteeing that their _is_ a proper sequence to be interpreted, the
idea is that something will just throw an error in case it isn't.

Extending the cases seems certainly reasonable as long as one makes
sure that other occurences of EVENT_HAS_PARAMETERS will interpret the
same sequence in the same manner.

It might possibly even make sense to change EVENT_HAS_PARAMETERS
itself to cater for such cases.

Can those sequences come about in any manner except by manually
specifying them?  Is this format documented anywhere?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `key-binding' and XEmacs-style events

[David Kastrup]

"Stuart D. Herring" <herring@lanl.gov> writes:

>>> We're talking about going the other way -- supporting (key-binding
>>> [(?a)])
>>> in Emacs
>>
>> Yes, but we don't have to fix it.
>>
>> If you want to write portable code, simply use the GNU Emacs format [?a],
>> as this is also supported by XEmacs.
>
> What I am actually interested in can be seen at
> http://www.emacswiki.org/cgi-bin/wiki/unbound.el: this code
> mechanically manipulates keystrokes.  By far the easiest way to do
> this is to generate XEmacs lists with modifiers and base events,
> rather than having to generate the symbol 'C-end and the low-ASCII
> ?\C-a and the high-bit-set ?\C-` with separate rules.  Then the
> natural way of representing an unmodified key is a list containing 0
> modifiers and the base event, but that fails (for `key-binding'
> only; `lookup-key' and `define-key' accept it) because it doesn't
> happen to begin with a symbol.

Is it documented anywhere that this a valid way to create a key
sequence with modifiers?

Should we document it?

Should we change EVENT_HAS_PARAMETERS itself maybe?  Or EVENTP?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `key-binding' and XEmacs-style events

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     We're talking about going the other way -- supporting
>     (key-binding [(?a)]) in Emacs (I don't know what XEmacs thinks
>     of event-lists with no modifiers).  The simplest fix seems to be
>     to move the check that the list is at least two long before the
>     code that uses its first element as a symbol:
>
> Would someone please install your patch?

Done, but I am not sure that we have all the documentation in place
that would have made it possible to avoid programming this bug in the
first place.

And I am utterly unsure that this will cover all cases of some
XEmacs-style sequences possibly being confused with events.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `key-binding' and XEmacs-style events

[Richard Stallman]

    And I am utterly unsure that this will cover all cases of some
    XEmacs-style sequences possibly being confused with events.

A list as a member of a key sequence has no meaning except
in terms of XEmacs compatibility, so I think confusion is not
possible.

Re: `key-binding' and XEmacs-style events

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     And I am utterly unsure that this will cover all cases of some
>     XEmacs-style sequences possibly being confused with events.
>
> A list as a member of a key sequence has no meaning except
> in terms of XEmacs compatibility, so I think confusion is not
> possible.

key-binding can be called with a mouse event inside of a key sequence
vector.  That was what the problem report was about in the first
place.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `key-binding' and XEmacs-style events

[Richard Stallman]

    > A list as a member of a key sequence has no meaning except
    > in terms of XEmacs compatibility, so I think confusion is not
    > possible.

    key-binding can be called with a mouse event inside of a key sequence
    vector.  That was what the problem report was about in the first
    place.

I stand corrected -- but the original problem report was not about a
mouse event, it was about using a character inside a list.

The car of a mouse event list is a symbol.   If the recent fix
does not alter what is done when the car is a symbol, it should not
alter treatment of mouse events.  Isn't that so?

Re: `key-binding' and XEmacs-style events

[Stuart D. Herring]

> Is it documented anywhere that this a valid way to create a key
> sequence with modifiers?

See (elisp)Changing Key Bindings.

> Should we change EVENT_HAS_PARAMETERS itself maybe?  Or EVENTP?

As far as I can tell, this is the only place where it matters.  "Real"
events -- those that are generated by user input -- are never of this
form, since it's not the "real" representation.  (This is at least true
for keys; I don't know whether mouse events can have this structure, but
they can't very well be misclassified by the current macros!)  Even
`lookup-key' handles them properly; it's just the special code in
`key-binding' that needs to decide whether to intuit a position that
doesn't already support them.

I actually considered changing EVENT_HAS_PARAMETERS first, but decided
that (since I knew of no other bugs caused by it) it was safer and simpler
to just change the logic in the one place.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: `key-binding' and XEmacs-style events

[Stuart D. Herring]

>     > A list as a member of a key sequence has no meaning except
>     > in terms of XEmacs compatibility, so I think confusion is not
>     > possible.
>
>     key-binding can be called with a mouse event inside of a key sequence
>     vector.  That was what the problem report was about in the first
>     place.
>
> I stand corrected -- but the original problem report was not about a
> mouse event, it was about using a character inside a list.
>
> The car of a mouse event list is a symbol.   If the recent fix
> does not alter what is done when the car is a symbol, it should not
> alter treatment of mouse events.  Isn't that so?

Unless I made a mistake, the fix I made does nothing at all except
avoiding an error when the car of a list is not a symbol: the rest of the
code proceeds as it did before and (since the modifier lists are in
general handled correctly) does the right thing.  If it is a symbol,
exactly the same code is executed, merely with certain side-effect-free
expressions evaluated in a slightly different order.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: `key-binding' and XEmacs-style events

[Stuart D. Herring]

>>     We're talking about going the other way -- supporting
>>     (key-binding [(?a)]) in Emacs (I don't know what XEmacs thinks
>>     of event-lists with no modifiers).  The simplest fix seems to be
>>     to move the check that the list is at least two long before the
>>     code that uses its first element as a symbol:
>>
>> Would someone please install your patch?
>
> Done, but I am not sure that we have all the documentation in place
> that would have made it possible to avoid programming this bug in the
> first place.
>
> And I am utterly unsure that this will cover all cases of some
> XEmacs-style sequences possibly being confused with events.

Thanks, David!  I forgot to include a ChangeLog entry, since I didn't know
the patch would just go in as it was; the one you supplied has an
off-by-one error, which the following patch fixes.

*** ChangeLog.~1.5584.~	2007-03-06 09:58:24.000000000 -0700
--- ChangeLog	2007-03-06 10:03:57.000000000 -0700
***************
*** 29,35 ****

  2007-03-02  Stuart D. Herring <herring@lanl.gov>

! 	* keymap.c (Fkey_binding): Don't consider two-element lists as
  	events.

  2007-03-01  Kenichi Handa  <handa@m17n.org>
--- 29,35 ----

  2007-03-02  Stuart D. Herring <herring@lanl.gov>

! 	* keymap.c (Fkey_binding): Don't consider one-element lists as
  	events.

  2007-03-01  Kenichi Handa  <handa@m17n.org>

Thanks again,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.