RE: Annoying paren match messages in minibuffer

[Drew Adams]

> >> 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.
> 
> > No, it would not, because I would not use the DWIM function
> > (`msg-maybe-in-minibuffer') to display such a message.  I would not,
> > because the shell completion code in question is not using the
> > minibuffer, and it is unlikely that it would ever be called from
> > the minibuffer.
> 
> Huh?  The shell completion is used in M-!

I was thinking only of `shell-mode' (you did say "a shell buffer", and you
didn't mention minibuffer activation here). Yes, in that case, it would be like
the other examples I gave of candidates for such a DWIM.

But if the minibuffer is already open elsewhere for `M-x', then how would `M-!'
(even somewhere else) act at the same time? It wouldn't.

If you meant with non-nil `enable-recursive-minibuffers', then the `M-!' would
take over the role of active minibuffer - there is only ever one active
minibuffer at a time. The argument remains the same. Only when the minibuffer is
active does `minibuffer-message' behavior make sense, and then it makes sense
only in the active minibuffer.

If you set `enable-recursive-minibuffers' to t, and you have two frames, and you
do `M-x' in one frame, and then you do `M-!' in the other frame, the active
(recursive) minibuffer follows - it is exactly the right place to display "[Sole
completion]" - right where you hit `M-!'. If `enable-recursive-minibuffers' is
nil, then you cannot run `M-!' when `M-x' is in progress. 

If you meant a separate shell buffer, as you said originally, then see my
previous response. If the shell completion code doesn't know whether it is run
by `M-!' or, say, in `shell-mode', then the DWIM as I defined it is appropriate
- the message will show up in the echo area if from a shell buffer, and in the
active minibuffer (in the frame where you hit `M-!') otherwise. It will not, as
you suggested, show up in the minibuffer that was active (from the `M-x') before
you hit `M-!'.
 
> Also I have some work-in-progress patches to replace some of the shell
> and lisp-symbol completion code (and sym-comp.el) to use
> minibuffer-complete.

Yes, I did that myself in fact, in Icicles, and I was going to suggest that you
do the same in Emacs, in particular so that users can benefit from the new
`completion-styles' feature. (Yes, I am in favor of the feature, even though I
think the _default_ completion behavior should not be changed from the
traditional behavior.)

Good - that will mean I can likely toss my code that enhances each of those
separate places because they didn't call `completing-read'. If code that
completes buffer text (e.g. symbols, env vars, file names, shell command names)
simply calls `completing-read' whenever there are multiple completion
candidates, then I can get rid of all of those special-purpose enhancements
(hacks). Icicles automatically kicks in (in Icicle mode) whenever
`completing-read' is used.

> There very much is a need for this completion code
> to magically decide when to use message and when to use
> minibuffer-message, and until now the best test I've found is
> minibufferp, not active-minibuffer-window.

Go for it. As I said, I don't care much how you implement it, as long as you
leave programmers a way to explicitly get the traditional `message' behavior.

And, again, I advise you not to just change `message', which would have a
blanket effect even when it's not appropriate, but to instead substitute a new
function in those places where it is likely that the code could be called from
either a minibuffer or top level.