RE: Annoying paren match messages in minibuffer

[Drew Adams]

> > I do the same thing myself, but only as a separate function.
> > So when I want unconditional behavior (regardless of the
> > current buffer) I can still call either `message' or
> > `minibuffer-message' instead.
> 
> As a general solution it would be better to change `message'
> to take care about the minibuffer's case.

It depends what is done to "take care of" things. If it is only automatic and
you cannot control it, then no thanks. Something automatic for the general case
is fine, as long as you can still specify either behavior (`message' or
`minibuffer-message') explicitly in some way. 

Providing a new, third function for the conditional "smart" behavior is a
reasonable approach and will introduce the fewest problems. Modifying `message'
to implement that behavior always is not TRT, IMO.

> > BTW, don't you need to ensure that the minibuffer window is active?
> 
> I think `active-minibuffer-window' is not suitable for this.
> It returns non-nil even when the current buffer is not the minibuffer,

That's exactly why `active-minibuffer-window' _is_ suitable for this. The
criterion for whether the message should be appended to, rather than replace,
the user input is whether the minibuffer is active - not whether it is the
current window. Whenever it is active (wherever that active window might be), a
user input interaction is going on, and we usually don't want to clobber the
user's input.

A minibuffer interaction with the user can be under way even if the current
buffer changes to another buffer temporarily. I often have another buffer
current during periods when the minibuffer is active. A command (e.g. key)
executed from the minibuffer can do anything at all, including select various
buffers/windows to get something done. Ultimately, of course, focus is usually
returned to the minibuffer when such a command completes. But it is not uncommon
to want to append a message to the user's input during such an interaction.

Nothing says that a minibuffer message (i.e. appended "[...]") is appropriate
only when the current buffer is the minibuffer.

And nothing says that whenever a minibuffer is the current buffer it is also
active (the active minibuffer window). And nothing says that even when it is
active you necessarily want the message to take that "[...]" form and have that
`minibuffer-message' behavior (e.g. delay).

In that context, you might well want to use `message' sometimes, either because
you _want_ to temporarily replace the contents with a message (more noticeable)
or because you don't want the delay that `minibuffer-message' incurs. `message'
is subject to being preempted by input events; `minibuffer-message' is not
(IIRC). And `minibuffer-message's delay is unconditional - once it starts, it
plays itself out. Each behavior has its advantages, depending on what is wanted.


The only generalization here that fits most of the time is that when the
minibuffer is _active_ you usually _do_ want that `minibuffer-message' behavior.
Usually, but not always.

> but there is no need to do this because it doesn't clobber the
> current user input (i.e. when the user switched from the active
> minibuffer to another buffer).

So what? If the minibuffer is not active, then most of the time you do not want
the `minibuffer-message' form to be used. And when it is active, it is not
necessarily the current buffer.

> > FWIW, this is the code I use:
> >
> > (defun msg-maybe-in-minibuffer (format-string &rest args)
> >   "Display FORMAT-STRING as a message.
> > If called with the minibuffer inactive, use `message'.
> > Otherwise, use `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)))

As I said, even that conditional code (which DTRT more often than code that
simply tests whether the minibuffer is the current buffer) is not good enough to
be used 100% of the time. I sometimes need to specifically use `message' or
`minibuffer-message', to get the behavior I want.

Whatever changes you decide to make, please at least be sure to provide some way
for programmers to get either behavior explicitly. Don't provide _only_ DWIM
code that won't listen to explicit WIM instructions.