this-command oddness

this-command oddness

[David Byers]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (sparc-sun-solaris2.8, X toolkit)
 of 2002-03-18 on sen14.ida.liu.se
configured using `configure  --prefix=/pkg/emacs-21.2 --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_US.ISO8859-1
  value of $LC_CTYPE: iso_8859_1
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_US.ISO8859-1
  value of $LC_NUMERIC: en_US.ISO8859-1
  value of $LC_TIME: en_US.ISO8859-1
  value of $LANG: en_US
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


In the following command:

    (defun db--test-this-command (file)
       (interactive)
       (completing-read "Hit RET: " nil)
       (message "%S" this-command))

I expected the message "db--test-this-command" in the echo area.
Instead I get "exit-minibuffer". Furthermore, last-command becomes
bound to exit-minibuffer rather than db--test-this-command. 

Similarly, in the following command:

    (defun db--test-this-command (file)
       (interactive "f")
       (message "%S" this-command))

I expected the message "db--test-this-command" in the echo area.
Instead I get "minibuffer-complete-and-exit" (after entering a file
name).

The value of this-command in a post-command-hook that is run after one
of the examples above will be "minibuffer-complete-and-exit or
"exit-minibuffer" or rather than "db--test-this-command". Similarly,
the value of last-command is affected.

I assume that this is the result of completing-read interactively
reading characters from the user, re-binding this-command in the
process.

In my opinion, neither completing-read, nor read-from-minibuffer
should alter this-command. I *definitely* think that interactive
should not alter this-command, regardless of what it calls in turn (if
this-command is altered in the call to interactive, the command never
gets a chance to examine the original value of this-command).


I propose that one of the following changes be made:

* Alter completing-read and read-from-minibuffer so they save the
  value of this-command on entry and restore it on exit or at least
  alter interactive so it saves the value of this-command on entry and
  restores it on exit.

* Update the documentation of this-command and last-command to reflect
  the face that they may not behave as expected. Examples like those I
  have shown would be appropriate in the elisp manual. Update the
  documentation for post-command-hook to indicate that this-command
  may have been inadvertently altered by the command that ran last.

I would have submitted patches, but don't have the time to write them
at the moment. Sorry.

-- 
David Byers.

Re: this-command oddness

[Richard Stallman]

    In the following command:

	(defun db--test-this-command (file)
	   (interactive)
	   (completing-read "Hit RET: " nil)
	   (message "%S" this-command))

    I expected the message "db--test-this-command" in the echo area.
    Instead I get "exit-minibuffer". Furthermore, last-command becomes
    bound to exit-minibuffer rather than db--test-this-command. 

That is because the last command read and executed by Emacs was
exit-minibuffer.

I guess you implicitly expected completing-read to save and restore
these values, but it does not.  I don't think that is a bug.
If you call the function explicitly, the responsibility to manage
these values is yours.

    Similarly, in the following command:

	(defun db--test-this-command (file)
	   (interactive "f")
	   (message "%S" this-command))

    I expected the message "db--test-this-command" in the echo area.
    Instead I get "minibuffer-complete-and-exit" (after entering a file
    name).

That could be a real bug.  Here is a patch to change it; could you
try it and report if it causes any problems?

*** callint.c.~1.126.~	Sun May 18 08:28:18 2003
--- callint.c	Thu Aug 28 12:59:24 2003
***************
*** 41,46 ****
--- 41,47 ----
  Lisp_Object Vcommand_history;
  
  extern Lisp_Object Vhistory_length;
+ extern Lisp_Object Vthis_original_command, real_this_command;
  
  Lisp_Object Vcommand_debug_status, Qcommand_debug_status;
  Lisp_Object Qenable_recursive_minibuffers;
***************
*** 291,296 ****
--- 292,305 ----
    int key_count;
    int record_then_fail = 0;
  
+   Lisp_Object save_this_command, save_last_command;
+   Lisp_Object save_this_original_command, save_real_this_command;
+ 
+   save_this_command = Vthis_command;
+   save_this_original_command = Vthis_original_command;
+   save_real_this_command = real_this_command;
+   save_last_command = current_kboard->Vlast_command;
+ 
    if (NILP (keys))
      keys = this_command_keys, key_count = this_command_key_count;
    else
***************
*** 395,400 ****
--- 404,415 ----
  		XSETCDR (teml, Qnil);
  	    }
  	}
+ 
+       Vthis_command = save_this_command;
+       Vthis_original_command = save_this_original_command;
+       real_this_command= save_real_this_command;
+       current_kboard->Vlast_command = save_last_command;
+ 
        single_kboard_state ();
        return apply1 (function, specs);
      }
***************
*** 840,845 ****
--- 855,865 ----
  
    if (record_then_fail)
      Fbarf_if_buffer_read_only ();
+ 
+   Vthis_command = save_this_command;
+   Vthis_original_command = save_this_original_command;
+   real_this_command= save_real_this_command;
+   current_kboard->Vlast_command = save_last_command;
  
    single_kboard_state ();