this-command oddness

[David Byers <davby@ida.liu.se>]

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.