minibuffer-message binds inhibit-quit

minibuffer-message binds inhibit-quit

[Drew Adams]

This let binding was recently added to `minibuffer-message':

;; A quit during sit-for normally only interrupts the sit-for,
;; but since minibuffer-message is used at the end of a command,
;; at a time when the command has virtually finished already, a C-g
;; should really cause an abort-recursive-edit instead (i.e. as if
;; the C-g had been typed at top-level).  Binding inhibit-quit here
;; is an attempt to get that behavior.
(inhibit-quit t)

I don't know about the effects of the binding (can't check until I get a more
recent Windows build) - perhaps this change is appropriate. But if it requires
the assumption stated in the comment, then it is not appropriate.

The assumption is invalid - it is by no means necessarily true that
"minibuffer-message is used at the end of a command, at a time when the command
has virtually finished already".

`minibuffer-message' should be for messages during minibuffer input - that's
all. Nothing should be assumed about when the command that calls it might be
ended or is "virtually finished". 

It should not even be assumed that the reading of minibuffer input is "virtually
finished already", let alone the command that calls for it. About all that can
be assumed about the calling context is that the minibuffer is active and it is
the current buffer.

Reading minibuffer input is a process, not an atomic event. It has a keymap, and
it can involve multiple user interactions. I sometimes use more than one
minibuffer message during the course of minibuffer input, to reflect the current
interaction status.

Again, this feedback is about the comment. I don't know whether the binding
itself is appropriate, but the comment, as expressed, is not.

Re: minibuffer-message binds inhibit-quit

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 24 Jun 2008 13:52:01 -0700
> 
> This let binding was recently added to `minibuffer-message':
> 
> ;; A quit during sit-for normally only interrupts the sit-for,
> ;; but since minibuffer-message is used at the end of a command,
> ;; at a time when the command has virtually finished already, a C-g
> ;; should really cause an abort-recursive-edit instead (i.e. as if
> ;; the C-g had been typed at top-level).  Binding inhibit-quit here
> ;; is an attempt to get that behavior.
> (inhibit-quit t)
> 
> I don't know about the effects of the binding (can't check until I get a more
> recent Windows build) - perhaps this change is appropriate. But if it requires
> the assumption stated in the comment, then it is not appropriate.
> 
> The assumption is invalid - it is by no means necessarily true that
> "minibuffer-message is used at the end of a command, at a time when the command
> has virtually finished already".
> 
> `minibuffer-message' should be for messages during minibuffer input - that's
> all. Nothing should be assumed about when the command that calls it might be
> ended or is "virtually finished". 

Are you sure you are not confusing minibuffer with the echo area?  The
minibuffer and `minibuffer-message' are not normally used for messages
during minibuffer input; that's what the echo area is for.

Re: minibuffer-message binds inhibit-quit

[Eli Zaretskii]

> Date: Wed, 25 Jun 2008 00:28:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Are you sure you are not confusing minibuffer with the echo area?  The
> minibuffer and `minibuffer-message' are not normally used for messages
> during minibuffer input; that's what the echo area is for.

Btw, I think by ``command'' the comment you cited means the command
that called `minibuffer-message'.  For example, the message "No match"
is displayed when I type TAB to complete a string that has no
completions; in this case, ``the command'' is the one bound to the TAB
key in the minibuffer, and that command is indeed done when the
message is visible.  Perhaps that is the cause of your confusion: you
seem to think that ``the command'' is whatever caused Emacs to enter
the minibuffer in the first place.

RE: minibuffer-message binds inhibit-quit

[Drew Adams]

> Btw, I think by ``command'' the comment you cited means the command
> that called `minibuffer-message'.  For example, the message "No match"
> is displayed when I type TAB to complete a string that has no
> completions; in this case, ``the command'' is the one bound to the TAB
> key in the minibuffer, and that command is indeed done when the
> message is visible.  Perhaps that is the cause of your confusion: you
> seem to think that ``the command'' is whatever caused Emacs to enter
> the minibuffer in the first place.

You're right to distinguish the two sorts of commands. And no doubt the comment
refers to a command initiated from the minibuffer during input (e.g. via a
minibuffer keymap).

But it doesn't follow that that command, which calls `minibuffer-message', is
finished as soon as the message is displayed. You can't argue only from a
specific example: TAB is done as soon as it displays its message, but `my-cmd',
bound to `C-M-S-H-backspace' might not be done as soon as it displays a message.

Regardless of which command calls `minibuffer-message', and when, there is no
guarantee that the command is "virtually finished" when the message is
displayed. A command can do anything after displaying a message.

Again, I don't know if the binding is appropriate. This is only about the
comment, unless the comment's assumption is a requirement for adding the
binding.

Re: minibuffer-message binds inhibit-quit

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 24 Jun 2008 15:26:17 -0700
> 
> But it doesn't follow that that command, which calls `minibuffer-message', is
> finished as soon as the message is displayed. You can't argue only from a
> specific example: TAB is done as soon as it displays its message, but `my-cmd',
> bound to `C-M-S-H-backspace' might not be done as soon as it displays a message.

No, that's not an example, that's a general principle: in Emacs,
redisplay happens only when Emacs is idle.  Ergo, if you see the
message on the screen, the command that produced it is done.

RE: minibuffer-message binds inhibit-quit

[Drew Adams]

> Are you sure you are not confusing minibuffer with the echo area?  The
> minibuffer and `minibuffer-message' are not normally used for messages
> during minibuffer input; that's what the echo area is for.

No, I don't believe so. 

AFAIK, `minibuffer-message' has always displayed a message in the minibuffer,
not the echo area. You see your input there at the same time. `message', on the
other hand, displays in the echo area. The echo-area obscures the minibuffer;
the message replaces the minibuffer content (temporarily).

AFAIK, `minibuffer-message' is intended to be used during minibuffer input.

"This function displays STRING temporarily at the end of the
 minibuffer text, for two seconds, or until the next input
 event arrives, whichever comes first."

"The text is displayed for a period controlled by
 `minibuffer-message-timeout', or until the next input event
 arrives, whichever comes first."

[BTW, note the discrepancy between the Elisp manual entry and the doc string,
wrt the timeout period.]



FWIW, I tend to use this, which chooses the display function depending on
whether the minibuffer is active:

(defun icicle-msg-maybe-in-minibuffer (format-string &rest args)
  "Display FORMAT-STRING as a message.
If called with the minibuffer inactive, this is done using `message'.
Otherwise, it is done using `minibuffer-message'."
  (if (active-minibuffer-window)
      (save-selected-window
        (select-window (minibuffer-window))
        (minibuffer-message
          (apply #'format (concat "  [" format-string "]") args)))
    (apply #'message format-string args)))

Re: minibuffer-message binds inhibit-quit

[Stefan Monnier]

> It should not even be assumed that the reading of minibuffer input is
> "virtually finished already", let alone the command that calls for
> it.  About all that can be assumed about the calling context is that
> the minibuffer is active and it is the current buffer.

You're arguing on principle.  Please provide an actual concrete
situation demonstrating the problem.  This way we will better be able to
assess whether the harm is worth the benefit or not.


        Stefan