Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

> I gave examples in my reply to Juri. `message' uses the echo area. The
> effect is to temporarily replace the minibuffer.  And the message can
> be preempted if input arrives. Those characteristics can be useful
> during some minibuffer dialogs.

I don't see any examples here, nor there.  In case it's not clear,
I expect an example where it would be incorrect/inconvenient for message
(inside a minibuffer) to delegate its work to minibuffer-message, and
that the incorrectness/inconvenience isn't due (directly or indirectly)
to the delay introduced by `message'.

>> > You need to be _able_, somehow, to specifically get the normal
>> > `minibuffer-message' behavior even when  not in the minibuffer (or
>> > even when it's not active).
>> 
>> Again, where's the evidence: currently minibuffer-message is 
>> pretty much unusable in a non-minibuffer buffer, yet I haven't seen
>> a single bug report about it.

> No one suggested using `minibuffer-message' to display a message outside the
> minibuffer.

Of course you did: (active-minibuffer-window) can return non-nil outside
of the minibuffer, so your suggestion to use choose minibuffer-message
based on (active-minibuffer-window) implies to use minibuffer-message
(sometimes) outside of a minibuffer.

Also the above text says quite explicitly that you sometimes want
minibuffer-message's behavior even when not in the minibuffer.

> This part of the discussion was about how to know whether/when it
> could be appropriate to call `minibuffer-message'. My point here was
> that it is not appropriate to do so unless the minibuffer is active,
> that is, unless some minibuffer window is active. It is not enough
> that a minibuffer window might be the current window. If no user input
> is taking place, then `minibuffer-message' is inappropriate.

Why not?

> Again, see my mail to Juri for descriptions of various cases. It
> depends on what you mean by "in a non-minibuffer buffer". Which buffer
> is current is not an adequate determination of whether the user is "in
> the minibuffer", in the sense of being able to enter input there. If
> the minibuffer is active, then the user is generally "in the
> minibuffer" in this sense, even if, for the moment, some other buffer
> might happen to be current.

Open up 2 windows.  Run ielm in one of the two.  In the other, do M-x,
then switch to the ielm window and do (active-minibuffer-window) RET
and you'll see that it may return non-nil in cases where the user is not
"in the minibuffer", just because it has a minibuffer active somewhere.

> temporarily make other buffers current. Throughout this minibuffer dialog, the
> minibuffer is _active_, so it generally makes sense to use the
> `minibuffer-message' behavior to display messages there.

Check the code of minibuffer-message: it displays the message in the
current buffer, regardless of whether it's a minibuffer or whether
there's an active minibuffer.

> `minibufferp' does not do that - it returns non-nil for a minibuffer
> even if no minibuffer is active, that is, even if no user input is
> possible.

Yes.  Note that it's pretty much completely irrelevant, because it's
pretty damn exceptional for minibufferp to be true while there is no
active minibuffer.  I.e. what happens in such a corner case is not
terribly important.

> `active-minibuffer-window' is, IMO, the right test.  But you need not
> be convinced.

Indeed, I'm not.  I know there are real cases where it would make the
wrong decision, see example below.

> What do you mean by an unrelated minibuffer being active? Unrelated to what?

Say you have a M-x minibuffer open but you've switched to some other
buffer, say a shell buffer and you're using completion and the
completion code needs to say "Sole completion": your suggestion would
cause a " [Sole completion]" message to be added at the end of the M-x
minibuffer (i.e. an unrelated minibuffer), rather than replacing
it altogether.


        Stefan