unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Juri Linkov' <juri@jurta.org>,
	'Chong Yidong' <cyd@stupidchicken.com>,
	'Geoff Gole' <geoffgole@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: Annoying paren match messages in minibuffer
Date: Wed, 14 Jan 2009 21:41:43 -0500	[thread overview]
Message-ID: <jwv8wpdz4jq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <004f01c976ab$8611f9e0$c2b22382@us.oracle.com> (Drew Adams's message of "Wed, 14 Jan 2009 16:52:20 -0800")

> 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




  reply	other threads:[~2009-01-15  2:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-12 12:18 Annoying paren match messages in minibuffer Geoff Gole
2009-01-12 15:20 ` Stefan Monnier
2009-01-13  2:26   ` Miles Bader
2009-01-13 14:00     ` Stefan Monnier
2009-01-13 15:55     ` Dan Nicolaescu
2009-01-13 18:27       ` Stefan Monnier
2009-01-13 18:33         ` Dan Nicolaescu
2009-01-14 22:15           ` Stefan Monnier
2009-01-14 22:30             ` Drew Adams
2009-01-13 13:58   ` Geoff Gole
2009-01-13 18:25     ` Stefan Monnier
2009-01-13 23:28 ` Juri Linkov
2009-01-14 13:46   ` Chong Yidong
2009-01-14 14:01     ` Stefan Monnier
2009-01-14 15:29       ` Drew Adams
2009-01-14 21:12         ` Juri Linkov
2009-01-14 21:52           ` Stefan Monnier
2009-01-14 22:22             ` Drew Adams
2009-01-14 23:10               ` Stefan Monnier
2009-01-15  0:52                 ` Drew Adams
2009-01-15  2:41                   ` Stefan Monnier [this message]
2009-01-16 19:10                     ` Drew Adams
2009-01-16 20:52                       ` Stefan Monnier
2009-01-16 23:42                         ` Drew Adams
2009-01-17  2:15                           ` Stefan Monnier
2009-01-14 22:13           ` Drew Adams
2009-01-14 21:12       ` Juri Linkov
2009-01-14 21:53         ` Stefan Monnier
2009-01-14 18:56   ` Geoff Gole
2009-01-14 21:14     ` Juri Linkov
2009-01-14 22:20       ` Geoff Gole
  -- strict thread matches above, loose matches on Subject: below --
2009-01-14 23:16 Chetan Pandya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv8wpdz4jq.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=cyd@stupidchicken.com \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=geoffgole@gmail.com \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).