Annoying paren match messages in minibuffer

Annoying paren match messages in minibuffer

[Geoff Gole]

By default, emacs will display a minibuffer message on seeing the user
type an unmatched paren. This is usually a welcome feature, but can
become annoying when point is in the minibuffer where well-formed
input is not necessarily balanced.

For example:

  emacs -Q
  M-%
  )

This is perfectly sensible input for replace-string, so seeing the nag
message (and have it momentarily displace the minibuffer display) is
irritating. I know that this is not a big deal as any further input
will immediately dismiss the message, but I'd think it would be better
not to show it in the first place. Perhaps paren matching should be
inhibited for minibuffer input that need not be balanced?

I attempted to implement this by binding blink-matching-paren and
show-paren-mode. Unfortunately that continues to inhibit paren
matching if the user moves out of the minibuffer, so is not
satisfactory. The example patch below does this for query-replace.

Thoughts?

--- emacs/lisp/replace.el	2009-01-09 14:01:00.000000000 +0900
+++ /tmp/buffer-content-17773Bqy	2009-01-12 20:33:21.000000000 +0900
@@ -225,12 +225,14 @@

 To customize possible responses, change the \"bindings\" in
`query-replace-map'."
   (interactive
-   (let ((common
-	  (query-replace-read-args
-	   (concat "Query replace"
-		   (if current-prefix-arg " word" "")
-		   (if (and transient-mark-mode mark-active) " in region" ""))
-	   nil)))
+   (let* (blink-matching-paren
+	  show-paren-mode
+	  (common
+	   (query-replace-read-args
+	    (concat "Query replace"
+		    (if current-prefix-arg " word" "")
+		    (if (and transient-mark-mode mark-active) " in region" ""))
+	    nil)))
      (list (nth 0 common) (nth 1 common) (nth 2 common)
 	   ;; These are done separately here
 	   ;; so that command-history will record these expressions

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

> By default, emacs will display a minibuffer message on seeing the user
> type an unmatched paren. This is usually a welcome feature, but can
> become annoying when point is in the minibuffer where well-formed
> input is not necessarily balanced.

Maybe the problem can be fixed by changing the way the message is
displayed.  E.g. it could be displayed as " [unmatched paren]" at the
end of the minibuffer input, as is done for minibuffer
completion messages.

> I attempted to implement this by binding blink-matching-paren and
> show-paren-mode. Unfortunately that continues to inhibit paren
> matching if the user moves out of the minibuffer, so is not
> satisfactory.

For those, you'd need to set the variable buffer-locally rather than
let-bind it.


        Stefan

Re: Annoying paren match messages in minibuffer

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Maybe the problem can be fixed by changing the way the message is
> displayed.  E.g. it could be displayed as " [unmatched paren]" at the
> end of the minibuffer input, as is done for minibuffer
> completion messages.

I think all messages should be.  I've used experimental code to do that
in the past, and it was _really_ nice.  No stupid awkward pauses and
annoyance like the current method, everything just seemed *right*.

However, for whatever reason, the last time this subject came up on
emacs-devel, it proved controversial [of course, it seems like pretty
much _every_ change is controversial on emacs-devel...].

-Miles

-- 
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

>> Maybe the problem can be fixed by changing the way the message is
>> displayed.  E.g. it could be displayed as " [unmatched paren]" at the
>> end of the minibuffer input, as is done for minibuffer
>> completion messages.

> I think all messages should be.  I've used experimental code to do that
> in the past, and it was _really_ nice.  No stupid awkward pauses and
> annoyance like the current method, everything just seemed *right*.

That's my experience as well.  What was that experimental code of yours?


        Stefan

Re: Annoying paren match messages in minibuffer

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > > Maybe the problem can be fixed by changing the way the message is
  > > displayed.  E.g. it could be displayed as " [unmatched paren]" at the
  > > end of the minibuffer input, as is done for minibuffer
  > > completion messages.
  > 
  > I think all messages should be.  I've used experimental code to do that
  > in the past, and it was _really_ nice.  No stupid awkward pauses and
  > annoyance like the current method, everything just seemed *right*.

How about allowing the minibuffer to have a header line, and display
messages in the header line?  This limits the messages to be one line
long, but it's probably easier to read, and it shouldn't be too much of
a distraction.  Just my 2 cents.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

>> I think all messages should be.  I've used experimental code to do that
>> in the past, and it was _really_ nice.  No stupid awkward pauses and
>> annoyance like the current method, everything just seemed *right*.
> How about allowing the minibuffer to have a header line, and display
> messages in the header line?  This limits the messages to be one line
> long, but it's probably easier to read, and it shouldn't be too much of
> a distraction.  Just my 2 cents.

In my setup (where I use a seperate minibuffer-only frame), this would
work OK, maybe, but in general eating up one more line of text
is undesirable.


        Stefan

Re: Annoying paren match messages in minibuffer

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> I think all messages should be.  I've used experimental code to do that
  > >> in the past, and it was _really_ nice.  No stupid awkward pauses and
  > >> annoyance like the current method, everything just seemed *right*.
  > > How about allowing the minibuffer to have a header line, and display
  > > messages in the header line?  This limits the messages to be one line
  > > long, but it's probably easier to read, and it shouldn't be too much of
  > > a distraction.  Just my 2 cents.
  > 
  > In my setup (where I use a seperate minibuffer-only frame), this would
  > work OK, maybe, but in general eating up one more line of text
  > is undesirable.

I didn't mean for the extra header line to always be present, just to be
created on demand when there's a need for an extra message in the
minibuffer.  Yes, this would move the mode-line one line up and down
when displaying the extra header line in the minibufer, but that might
not be a problem given that it's not such a frequent action.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

> I didn't mean for the extra header line to always be present, just to be
> created on demand when there's a need for an extra message in the
> minibuffer.  Yes, this would move the mode-line one line up and down
> when displaying the extra header line in the minibufer, but that might
> not be a problem given that it's not such a frequent action.

Oh, I see, then I guess it'd be OK, tho I'd rather see the message
*below* rather than *above*.


        Stefan

RE: Annoying paren match messages in minibuffer

[Drew Adams]

> > I didn't mean for the extra header line to always be present,
> > just to be created on demand when there's a need for an extra
> > message in the minibuffer.  Yes, this would move the mode-line
> > one line up and down when displaying the extra header line in
> > the minibufer, but that might not be a problem given that it's
> > not such a frequent action.
> 
> Oh, I see, then I guess it'd be OK, tho I'd rather see the message
> *below* rather than *above*.

I don't have a ready-made opinion on this, but please, whatever you do, keep the
possibility for programmers to get the current behavior.

It sounds like we're veering into territory that could well be as annoying, at
least to some, as the behavior that someone originally found annoying. 

So, by all means, implement it, play with it, ask others to play with it, and
maybe even add it to Emacs. It sounds like an idea worth exploring. But please
don't replace the existing behavior, at least as an option for those who prefer
it.

IOW, yes to new, experimental ideas; no to adopting them willy nilly.

Re: Annoying paren match messages in minibuffer

[Geoff Gole]

> For those, you'd need to set the variable buffer-locally rather than
> let-bind it.

I found getting this right a touch tricky due to the possibility of
recursive minibuffers. But here we go:

(defun locally-suppress-paren-matching ()
  (make-local-variable 'blink-matching-paren)
  (setq blink-matching-paren nil)
  (make-local-variable 'show-paren-mode)
  (setq show-paren-mode nil)
  ;; remove suppression so recursive minibuffers can retain matching
  (remove-hook 'minibuffer-setup-hook 'locally-suppress-paren-matching))

;; This can be used to suppress spurious paren matching complaints for
;; minibuffer input that might be sensible without being balanced.
(defmacro with-minibuffer-suppressed-paren-matching (&rest body)
  "Suppresses paren highlighting for minibuffer invocations in
BODY.  On entry to the minibuffer the suppression is removed,
allowing paren highlighting to work for recursive minibuffers."
  `(let ((minibuffer-setup-hook
	  ;; On entry, kill paren matching and remove self from
	  ;; minibuffer-setup-hook (fix for recursive minibuffers).
	  (cons 'locally-suppress-paren-matching minibuffer-setup-hook))
	 (minibuffer-exit-hook
	  ;; On exit, add back the removed hook.
	  (cons (lambda ()
		  (add-hook 'minibuffer-setup-hook
			    'locally-suppress-paren-matching))
		minibuffer-exit-hook)))
     ,@body))

I don't really like this solution. It appears to work, but requires
patching in a whole bunch of places. And check out the "nifty" self
removing hook!

> Maybe the problem can be fixed by changing the way the message is
> displayed.  E.g. it could be displayed as " [unmatched paren]" at the
> end of the minibuffer input, as is done for minibuffer
> completion messages.

I initially thought this might be a bad idea as it would require
special casing paren matching in the minibuffer. The idea is growing
on me, though.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

>> For those, you'd need to set the variable buffer-locally rather than
>> let-bind it.
> I found getting this right a touch tricky due to the possibility of
> recursive minibuffers.

I don't see why that would make any difference: each recursive level
uses a different (mini)buffer.  Oh, wait you mean because of the fact
that minibuffer-setup-hook will apply to the recursive uses as well.

Try minibuffer-with-setup-hook, which encapsulates this hack.


        Stefan

Re: Annoying paren match messages in minibuffer

[Juri Linkov]

>   emacs -Q
>   M-%
>   )
>
> This is perfectly sensible input for replace-string, so seeing the nag
> message (and have it momentarily displace the minibuffer display) is
> irritating. I know that this is not a big deal as any further input
> will immediately dismiss the message, but I'd think it would be better
> not to show it in the first place. Perhaps paren matching should be
> inhibited for minibuffer input that need not be balanced?
>
> I attempted to implement this by binding blink-matching-paren and
> show-paren-mode. Unfortunately that continues to inhibit paren
> matching if the user moves out of the minibuffer, so is not
> satisfactory. The example patch below does this for query-replace.
>
> Thoughts?

Please don't disable these notifications in the minibuffer.
They are useful for detecting unbalanced parenthesis while writing
short Lisp snippets or regexps with a lot of grouping constructs
in the minibuffer.

An annoyance like you reported can be eliminated with the following
simple patch:

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.966
diff -u -r1.966 simple.el
--- lisp/simple.el	9 Jan 2009 04:44:21 -0000	1.966
+++ lisp/simple.el	13 Jan 2009 23:28:42 -0000
@@ -5229,7 +5229,9 @@
                  ;; a matching-char info, in which case the two CDRs
                  ;; should match.
                  (eq matching-paren (cdr (syntax-after (1- oldpos))))))
-        (message "Mismatched parentheses"))
+	(if (window-minibuffer-p (selected-window))
+	    (minibuffer-message " [Mismatched parentheses]")
+	  (message "Mismatched parentheses")))
        ((not blinkpos)
         (or blink-matching-paren-distance
             ;; Don't complain when `$' with no blinkpos, because it

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Annoying paren match messages in minibuffer

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> An annoyance like you reported can be eliminated with the following
> simple patch:
>
> -        (message "Mismatched parentheses"))
> +	(if (window-minibuffer-p (selected-window))
> +	    (minibuffer-message " [Mismatched parentheses]")
> +	  (message "Mismatched parentheses")))

This patch looks like the right thing to do.  Does anyone see any
problems with this change?

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

>> An annoyance like you reported can be eliminated with the following
>> simple patch:
>> 
>> -        (message "Mismatched parentheses"))
>> +	(if (window-minibuffer-p (selected-window))
>> +	    (minibuffer-message " [Mismatched parentheses]")
>> +	  (message "Mismatched parentheses")))

> This patch looks like the right thing to do.  Does anyone see any
> problems with this change?

Other than the fact that this should be done automatically by `message'?
No,


        Stefan

RE: Annoying paren match messages in minibuffer

[Drew Adams]

> >> An annoyance like you reported can be eliminated with the following
> >> simple patch:
> >> -        (message "Mismatched parentheses"))
> >> +	(if (window-minibuffer-p (selected-window))
> >> +	    (minibuffer-message " [Mismatched parentheses]")
> >> +	  (message "Mismatched parentheses")))
> 
> > This patch looks like the right thing to do.  Does anyone see any
> > problems with this change?
> 
> Other than the fact that this should be done automatically by 
> `message'? No,

I won't know until I try it, and I don't have the time to do that right now. But
I suspect that this will sometimes lead to problems due to the delay involved
with `minibuffer-message'.

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.

BTW, don't you need to ensure that the minibuffer window is active?

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

Re: Annoying paren match messages in minibuffer

[Juri Linkov]

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

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

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

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

> As a general solution it would be better to change `message'
> to take care about the minibuffer's case.

I see 3 solutions:
1 - change `message' to use minibuffer-message when in the minibuffer.
    As pointed out, the delay can be problematic.
2 - change minibuffer-message to call `message' when not in minibuffer.
    This is easy to do and shouldn't suffer from those same problems
    but won't catch as many cases.
3 - introduce a new function that uses one or the other depending
    on `minibufferp'.  This won't catch any case until we start changing
    code to use it.  But it's the safest and easiest solution.  The only
    hard part would be agreeing on its name.

> I think `active-minibuffer-window' is not suitable for this.

Indeed, we have `minibufferp' for that.


        Stefan

RE: Annoying paren match messages in minibuffer

[Drew Adams]

> > As a general solution it would be better to change `message'
> > to take care about the minibuffer's case.
> 
> I see 3 solutions:
> 1 - change `message' to use minibuffer-message when in the minibuffer.
>     As pointed out, the delay can be problematic.

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.

> 2 - change minibuffer-message to call `message' when not in 
>     minibuffer.
>     This is easy to do and shouldn't suffer from those same problems
>     but won't catch as many cases.

Again, the simple test of "in the minibuffer" (or even whether the minibuffer is
active, which is more appropriate) is not appropriate for all cases. 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).

Currently, a programmer can get any of the behaviors discussed, including the
conditional behaviors. Please don't replace that flexibility with a single
one-size-fits-all behavior.

> 3 - introduce a new function that uses one or the other depending
>     on `minibufferp'.  This won't catch any case until we 
>     start changing code to use it.  But it's the safest and easiest 
>     solution.  The only hard part would be agreeing on its name.

If change there must be, please choose #3. Any name you like.

> > I think `active-minibuffer-window' is not suitable for this.
> 
> Indeed, we have `minibufferp' for that.

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.

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.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

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

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

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

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


        Stefan

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.

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

RE: Annoying paren match messages in minibuffer

[Drew Adams]

I really don't have time to discuss this in detail.

As long as you keep also the ability to get the traditional `message' (i.e. echo
area) behavior somehow, I don't really care how you implement a DWIM feature for
messages. However, I strongly advise against simply _replacing_ `message' by any
DWIM messaging function - see below for some reasons.

A few points in reply, below, in hopes of clearing up some misunderstanding.

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

No, the code I sent does `(select-window (minibuffer-window))' if
`(active-minibuffer-window)'. The minibuffer message can only appear in the
minibuffer, and only when it is active.

> so your suggestion to use choose minibuffer-message
> based on (active-minibuffer-window) implies to use minibuffer-message
> (sometimes) outside of a minibuffer.

No, see above. The minibuffer message is always in the minibuffer (with my
approach).

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

That is precisely a case in which a message from the IELM buffer should use the
traditional `message' behavior, that is, use the echo area, not the minibuffer.
It is inappropriate for a message to appear in any minibuffer (active or not),
if it is unrelated in any way to a minibuffer (i.e. input) operation.

And that is an example of why programmers should still be able to specify such
non-minibuffer messaging behavior. If some code does not expect to be run during
a minibuffer dialog, then it typically does not want to use the minibuffer for
its messages. If some code is likely to be used _either_ from the minibuffer or
not from it, then it can probably benefit from a DWIM function that DTRT based
on the context.

IMO, it is not reliable or desirable to substitute a DWIM for `message' in all
or even in most cases, regardless of how it is defined. Its use should be
reserved for cases where it is likely that the code might be called either from
the minibuffer or from top level.

For example, some toggle commands make sense when run either at top level or
from the minibuffer (via a key) - particularly toggles that affect minibuffer
behavior (e.g. input case sensitivity, completion candidate sort order,
completion method). A message from such a command, echoing what the new
(toggled) value is, can benefit from the automatic determination of which
messaging behavior to use.

But a message from a command that is very unlikely to be run from the minibuffer
should not be subject to such a DWIM guess.

There are really two scenarios where the current buffer might not be the active
minibuffer, even though the minibuffer is active. One is the scenario you cited.
In that case, the user's interaction in IELM is unrelated to the minibuffer that
is active somewhere else (for `M-x').

I certainly agree that it makes no sense for IELM to show such a message in the
active minibuffer - it makes no sense to show it in _any_ minibuffer.

The IELM buffer should use traditional `message' in this context, since it is
not currently involved in a minibuffer interaction with the user; the current
IELM activity is not part of some overall minibuffer interaction. IELM knows
that; a DWIM messaging function cannot know that.

The other scenario is where a minibuffer interaction is in progress, and that
interaction itself uses other buffers, perhaps making them current at one time
or another for various uses, including some user interaction. Overall, the user
is involved in a minibuffer dialog - the other buffers are used as part of that
minibuffer interaction. Their interaction with the user is generally part of the
overall minibuffer interaction.

In Icicles, for instance, you can do a lot of things in the context of
minibuffer completion: get help on completion candidates, navigate Info, search,
perform actions on candidates, etc. Some of those operations can involve making
other buffers current at some point. They can involve user interaction with
other buffers. Yet, overall, this is all part of a minibuffer dialog.

No, this overall interaction is not modal - nothing prevents a user from
directly using the other buffers that are part of this interaction, or even
other unrelated buffers (such as IELM). But buffers that are part of the overall
minibuffer interaction (orchestrated by it, so to speak) should naturally
(typically) interact using messages in the (active) minibuffer, since that is
the general focus of the user's activity.

In this second scenario, it typically makes sense to use the
`minibuffer-message' behavior, not to displace the user's input temporarily via
the `message' behavior.

In my context, that is why I test for `active-minibuffer-window' - to be sure
that the minibuffer is active before I use it for a message.

Please note the qualifications, such as "typically", above.

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

Check the code I was talking about (above): it specifically selects the active
minibuffer before inserting a message. With my code, `minibuffer-message' is
never called with some other buffer current.

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

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. It should use the
normal `message' (echo area) behavior. That particular `Sole completion' message
is for non-minibuffer completion - it is totally unrelated to a minibuffer
interaction.

Summary:

1. `minibuffer-message' behavior is generally appropriate for use by code that
is using the minibuffer, whether or not the current buffer at the time of the
message is the minibuffer itself. The user's focus here is generally on the
minbuffer.

(And if the `minibuffer-message' behavior is used here, the (active) minibuffer
must first be selected, to display the message there.)

2. `message' behavior is generally appropriate for use by code that is not using
the minibuffer, even if the minibuffer might currently be active somewhere for
use by some other interaction.

3. It is the function that displays a message that should decide whether it is
likely that the message might be shown as part of an overall minibuffer
interaction:

If the function is likely to be called from the minibuffer, and that message is
likely to be part of a minibuffer dialog, then `minibuffer-message' behavior can
be appropriate. If the function is likely to be called apart from any minibuffer
interaction, then `message' behavior can be appropriate. If both are likely,
then `msg-maybe-in-minibuffer' can be appropriate.

4. `message' can sometimes be the right behavior, even when a minibuffer
interaction is ongoing, and even when the function displaying the message is
generally part of that minibuffer interaction.

Some possible reasons: (1) avoid the delay, (2) preempt the message by the
arrival of user input, (3) replace the minibuffer content with the echo area
temporarily, to temporarily interrupt the dialog and draw attention to the
message.

5. Yes, the delay associated with `minibuffer-message' is a problem in general.
I don't have an improvement in mind for that. It is one reason that I sometimes
use `message' even during minibuffer input (see previous, #1), and I sometimes
forego showing a message altogether - if it's not worth a delay, then it's not
worth showing (unfortunately).

HTH.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

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

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


        Stefan

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.

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

I'll stop here.  For those who haven't dropped the thread yet, the only
thing that should be worth remembering is that I consider
active-minibuffer-window as being the wrong test, so don't use it unless
you *really* know what you're doing.


        Stefan

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.

Re: Annoying paren match messages in minibuffer

[Juri Linkov]

>>> An annoyance like you reported can be eliminated with the following
>>> simple patch:
>>>
>>> -        (message "Mismatched parentheses"))
>>> +	(if (window-minibuffer-p (selected-window))
>>> +	    (minibuffer-message " [Mismatched parentheses]")
>>> +	  (message "Mismatched parentheses")))
>
>> This patch looks like the right thing to do.  Does anyone see any
>> problems with this change?
>
> Other than the fact that this should be done automatically by `message'?

Miles said he has experimental code for this.  Until it's installed
after resolving all controversies, I'd like to fix this particular case.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Annoying paren match messages in minibuffer

[Stefan Monnier]

> Miles said he has experimental code for this.  Until it's installed
> after resolving all controversies, I'd like to fix this particular case.

By all means, install your patch, please,


        Stefan

Re: Annoying paren match messages in minibuffer

[Geoff Gole]

> This patch looks like the right thing to do.  Does anyone see any
> problems with this change?

Shouldn't the second call to message in blink-matching-open be
similarly fixed? Other than that, looks great to me.

Re: Annoying paren match messages in minibuffer

[Juri Linkov]

>> This patch looks like the right thing to do.  Does anyone see any
>> problems with this change?
>
> Shouldn't the second call to message in blink-matching-open be
> similarly fixed? Other than that, looks great to me.

Maybe it should, but I can't find a test case to cause the message
"Unmatched parenthesis" to be displayed in the minibuffer.
Should the minibuffer be in a TeX mode?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Annoying paren match messages in minibuffer

[Geoff Gole]

> Maybe it should, but I can't find a test case to cause the message
> "Unmatched parenthesis" to be displayed in the minibuffer.

Neither can I. It seems my objection was baseless.

Re: Annoying paren match messages in minibuffer

[Chetan Pandya]

> > > I didn't mean for the extra header line to always be present,
> > > just to be created on demand when there's a need for an extra
> > > message in the minibuffer.  Yes, this would move the mode-line
> > > one line up and down when displaying the extra header line in
> > > the minibufer, but that might not be a problem given that it's
> > not such a frequent action.
> > 
> > Oh, I see, then I guess it'd be OK, tho I'd rather see the message
> > *below* rather than *above*.

> I don't have a ready-made opinion on this, but please, whatever you do, keep the
> possibility for programmers to get the current behavior.

> It sounds like we're veering into territory that could well be as annoying, at
> least to some, as the behavior that someone originally found annoying. 

> So, by all means, implement it, play with it, ask others to play with it, and
> maybe even add it to Emacs. It sounds like an idea worth exploring. But please
> don't replace the existing behavior, at least as an option for those who prefer
> it.

> IOW, yes to new, experimental ideas; no to adopting them willy nilly.

Given how much traffic there has been on discussing "message", I tend to agree.
For the people who want to experiment, it is possible to do

(setq messagefn (symbol-function 'message))
(fset 'message 'my-choice-message-function)

So it isn't clear there is any urgency of doing this, unless there are other instances 
where the current behavior is irritable and this solution does not work, but then a 
different solution is needed anyway.

Chetan