Behavior of `this-command-keys'

Behavior of `this-command-keys'

[Jay Belanger]

The behavior of `this-command-keys' doesn't seem to match its
documentation; perhaps I'm misunderstanding something.  The
documentation for `this-command-keys' is:
   This function returns a string or vector containing the key
   sequence that invoked the present command, plus any previous
   commands that generated the prefix argument for this command.
   However, if the command has called `read-key-sequence', it returns
   the last read key sequence.  *Note Key Sequence Input::.  The
   value is a string if all events in the sequence were characters
   that fit in a string.  *Note Input Events::.
Consider something like:
  (defun test ()
    (interactive)
    (sit-for 1)
    (setq result (this-command-keys)))
  (global-set-key "a" 'test)
To me, it sounds like as if `result' should equal "a" (the key which
calls the function) if "ab" were pressed, whether or not the `sit-for'
had run its course.  However, `result' equals "a" or "ab" depending on
how close together the "a" and "b" are pressed.

Jay

Re: Behavior of `this-command-keys'

[Kim F. Storm]

Jay Belanger <belanger@truman.edu> writes:

> The behavior of `this-command-keys' doesn't seem to match its
> documentation; perhaps I'm misunderstanding something.

No, you have found a rather nasty bug.

> Consider something like:
>   (defun test ()
>     (interactive)
>     (sit-for 1)
>     (setq result (this-command-keys)))
>   (global-set-key "a" 'test)

> To me, it sounds like as if `result' should equal "a" (the key which
> calls the function) if "ab" were pressed, whether or not the `sit-for'
> had run its course.  However, `result' equals "a" or "ab" depending on
> how close together the "a" and "b" are pressed.

Since sit-for calls read-event internally, the result depends on whether
you type the b while sit-for is inside read-event or not.

That is obviously a bug.

As far as I can see, we need a non-destructive version of read-event
(wait-for-input SECONDS)

But we almost have that:

 (while-no-input
   (sleep-for SECONDS))

The only problem is that a selection event will interrupt while-no-input.
This is very annoying - also for other purposes than this.  

What can we do?

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

Re: Behavior of `this-command-keys'

[Jay Belanger]

storm@cua.dk (Kim F. Storm) writes:

> Jay Belanger <belanger@truman.edu> writes:
>
>> The behavior of `this-command-keys' doesn't seem to match its
>> documentation; perhaps I'm misunderstanding something.
>
> No, you have found a rather nasty bug.

In the documentation, at least.
I would think the documented behavior would be desirable, but I guess
whoever used this-command-keys can just put it near the top of the
function. 

Jay

Re: Behavior of `this-command-keys'

[Richard Stallman]

    Consider something like:
      (defun test ()
	(interactive)
	(sit-for 1)
	(setq result (this-command-keys)))
      (global-set-key "a" 'test)
    To me, it sounds like as if `result' should equal "a" (the key which
    calls the function) if "ab" were pressed, whether or not the `sit-for'
    had run its course.

It seems that the documentation of this-command-keys is wrong.  Its
value seems to include any keys that were read by read-event.

Given this fact, it is clear why sit-for now has the result it does:
it reads that event using read-event.

Does this fix it?

*** keyboard.c	11 Sep 2006 10:33:19 -0400	1.875
--- keyboard.c	11 Sep 2006 18:06:51 -0400	
***************
*** 3257,3264 ****
        goto retry;
      }
  
!   if (! reread || this_command_key_count == 0
!       || this_command_key_count_reset)
      {
  
        /* Don't echo mouse motion events.  */
--- 3257,3265 ----
        goto retry;
      }
  
!   if ((! reread || this_command_key_count == 0
!        || this_command_key_count_reset)
!       && !end_time)
      {
  
        /* Don't echo mouse motion events.  */
***************
*** 8765,8781 ****
       the initial keymaps from the current buffer.  */
    nmaps = 0;
  
!   if (!NILP (current_kboard->Voverriding_terminal_local_map)
!       || !NILP (Voverriding_local_map))
      {
!       if (3 > nmaps_allocated)
  	{
! 	  submaps = (Lisp_Object *) alloca (3 * sizeof (submaps[0]));
! 	  defs    = (Lisp_Object *) alloca (3 * sizeof (defs[0]));
! 	  nmaps_allocated = 3;
  	}
        if (!NILP (current_kboard->Voverriding_terminal_local_map))
  	submaps[nmaps++] = current_kboard->Voverriding_terminal_local_map;
        if (!NILP (Voverriding_local_map))
  	submaps[nmaps++] = Voverriding_local_map;
      }
--- 8766,8790 ----
       the initial keymaps from the current buffer.  */
    nmaps = 0;
  
!   if (!NILP (current_kboard->Voverriding_terminal_local_map))
      {
!       if (2 > nmaps_allocated)
  	{
! 	  submaps = (Lisp_Object *) alloca (2 * sizeof (submaps[0]));
! 	  defs    = (Lisp_Object *) alloca (2 * sizeof (defs[0]));
! 	  nmaps_allocated = 2;
  	}
        if (!NILP (current_kboard->Voverriding_terminal_local_map))
  	submaps[nmaps++] = current_kboard->Voverriding_terminal_local_map;
+     }
+   else if (!NILP (Voverriding_local_map))
+     {
+       if (2 > nmaps_allocated)
+ 	{
+ 	  submaps = (Lisp_Object *) alloca (2 * sizeof (submaps[0]));
+ 	  defs    = (Lisp_Object *) alloca (2 * sizeof (defs[0]));
+ 	  nmaps_allocated = 2;
+ 	}
        if (!NILP (Voverriding_local_map))
  	submaps[nmaps++] = Voverriding_local_map;
      }


This updates the documentation of this-command-keys.


*** commands.texi	18 Aug 2006 08:26:35 -0400	1.93
--- commands.texi	11 Sep 2006 18:10:34 -0400	
***************
*** 788,798 ****
  @anchor{Definition of this-command-keys}
  This function returns a string or vector containing the key sequence
  that invoked the present command, plus any previous commands that
! generated the prefix argument for this command.  However, if the
! command has called @code{read-key-sequence}, it returns the last read
! key sequence.  @xref{Key Sequence Input}.  The value is a string if
! all events in the sequence were characters that fit in a string.
! @xref{Input Events}.
  
  @example
  @group
--- 788,800 ----
  @anchor{Definition of this-command-keys}
  This function returns a string or vector containing the key sequence
  that invoked the present command, plus any previous commands that
! generated the prefix argument for this command.  Any events read by the
! command using @code{read-event} without a timeout get tacked on to the end.
! 
! However, if the command has called @code{read-key-sequence}, it
! returns the last read key sequence.  @xref{Key Sequence Input}.  The
! value is a string if all events in the sequence were characters that
! fit in a string.  @xref{Input Events}.
  
  @example
  @group

Re: Behavior of `this-command-keys'

[Jay Belanger]

Richard Stallman <rms@gnu.org> writes:

>     Consider something like:
>       (defun test ()
> 	(interactive)
> 	(sit-for 1)
> 	(setq result (this-command-keys)))
>       (global-set-key "a" 'test)
>     To me, it sounds like as if `result' should equal "a" (the key which
>     calls the function) if "ab" were pressed, whether or not the `sit-for'
>     had run its course.
>
> It seems that the documentation of this-command-keys is wrong.  Its
> value seems to include any keys that were read by read-event.

I take it that's the desired value, then.

> Given this fact, it is clear why sit-for now has the result it does:
> it reads that event using read-event.
>
> Does this fix it?

In the above test, the result is always "a"; so I guess the patch
fixes it.

Jay

Re: Behavior of `this-command-keys'

[Richard Stallman]

    > It seems that the documentation of this-command-keys is wrong.  Its
    > value seems to include any keys that were read by read-event.

    I take it that's the desired value, then.

Yes, I think it was intentional.  I believe my patch restores
the behavior as of before the sit-for change.