RE: Annoying paren match messages in minibuffer

[Drew Adams]

> > Not just the delay. You need to be _able_, somehow, to 
> > specifically get the normal `message' behavior even when
> > a minibuffer read is in progress. See my reply to Juri.
> 
> Other than the delay, I see no evidence that what you assert is true.

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.

But, as I also said, that is the exception - most of the time, the
`minibuffer-message' behavior makes sense during minibuffer input.

Believe me (or not); I use both, and I do use such a DWIM most of the time.

> > 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. 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.

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.

A minibuffer interaction can last, and minibuffer keys can be hit to run
commands during that interaction. And some of those commands can do things that
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. The test for being
active correctly lets code know whether a session of user input is ongoing,
regardless of which window or buffer might be current at the moment.

> > See my reply to Juri. `minibufferp' returns non-nil for every
> > minibuffer, whether active or not, and it returns non-nil for
> > a minibuffer even if _none_ of the minibuffers are active. 
> > That is, it returns non-nil even if there is no user-input
> > interaction going on. That is the wrong condition.
> 
> Care to give a scenario where that's a problem?  It's pretty extremely
> rare to be inside a minibuffer that's not active, if you ask me.

Functions such as `minibuffer-window-active-p' and `active-minibuffer-window'
can help distinguish an inactive minibuffer from the active minibuffer (if any).


`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. (I do not use
`minibufferp' much myself, BTW, because I usually want code that works also with
older Emacs versions.)

The user is not asked for input except in the _active_ minibuffer. And messages
should be written only to the active minibuffer (a la `minibuffer-message') or
to the echo area (a la `message'). `active-minibuffer-window' is, IMO, the right
test. But you need not be convinced.

> > The proper test, IMO, is whether the minibuffer is active, that is,
> > whether some minibuffer is active. It has nothing 
> > (necessarily) to do with the current window/buffer.
> 
> So when some unrelated minibuffer is active, you want to display your
> message next to its content, giving the impression that the message
> refers to the minibuffer's content?  That doesn't sound right at all.

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

AFAIK, at most one minibuffer window can be active at a time. If none is active,
then the user is not entering input in a minibuffer. In that case, only the
current `message' behavior makes sense, IMO.

If a minibuffer window is active, then that is the window where user minibuffer
input is to be entered, and it is the window where minibuffer messages ([...])
should be displayed.

Perhaps we're not communicating. I don't really care about
`active-minibuffer-window' or whether you're convinced wrt my suggestion for
coding a DWIM feature for this - do it your way.

All I really care about is that programmers will retain the ability to override
such a DWIM feature to specifically do what they _really_ mean in some context.
IOW, please keep the ability to do either what `message' does today or what
`minibuffer-message' does today, whenever the minibuffer is active. If you do
that, then there's no harm in adding a DWIM feature such as was proposed,
implemented any way you like.