all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Behavior of `this-command-keys'
@ 2006-09-11 17:54 Jay Belanger
  2006-09-11 22:13 ` Kim F. Storm
  2006-09-12  2:01 ` Richard Stallman
  0 siblings, 2 replies; 6+ messages in thread
From: Jay Belanger @ 2006-09-11 17:54 UTC (permalink / raw)
  Cc: 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Behavior of `this-command-keys'
  2006-09-11 17:54 Behavior of `this-command-keys' Jay Belanger
@ 2006-09-11 22:13 ` Kim F. Storm
  2006-09-12 16:42   ` Jay Belanger
  2006-09-12  2:01 ` Richard Stallman
  1 sibling, 1 reply; 6+ messages in thread
From: Kim F. Storm @ 2006-09-11 22:13 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Behavior of `this-command-keys'
  2006-09-11 17:54 Behavior of `this-command-keys' Jay Belanger
  2006-09-11 22:13 ` Kim F. Storm
@ 2006-09-12  2:01 ` Richard Stallman
  2006-09-12 16:40   ` Jay Belanger
  1 sibling, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2006-09-12  2:01 UTC (permalink / raw)
  Cc: belanger, emacs-devel

    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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Behavior of `this-command-keys'
  2006-09-12  2:01 ` Richard Stallman
@ 2006-09-12 16:40   ` Jay Belanger
  2006-09-13 15:10     ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Jay Belanger @ 2006-09-12 16:40 UTC (permalink / raw)
  Cc: 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Behavior of `this-command-keys'
  2006-09-11 22:13 ` Kim F. Storm
@ 2006-09-12 16:42   ` Jay Belanger
  0 siblings, 0 replies; 6+ messages in thread
From: Jay Belanger @ 2006-09-12 16:42 UTC (permalink / raw)
  Cc: 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Behavior of `this-command-keys'
  2006-09-12 16:40   ` Jay Belanger
@ 2006-09-13 15:10     ` Richard Stallman
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2006-09-13 15:10 UTC (permalink / raw)
  Cc: belanger, emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2006-09-13 15:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-11 17:54 Behavior of `this-command-keys' Jay Belanger
2006-09-11 22:13 ` Kim F. Storm
2006-09-12 16:42   ` Jay Belanger
2006-09-12  2:01 ` Richard Stallman
2006-09-12 16:40   ` Jay Belanger
2006-09-13 15:10     ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.