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.