unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@IRO.UMontreal.CA>,
	"'Juri Linkov'" <juri@jurta.org>
Cc: '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 14:22:24 -0800	[thread overview]
Message-ID: <002d01c97696$93c6a190$c2b22382@us.oracle.com> (raw)
In-Reply-To: <jwviqohmucr.fsf-monnier+emacs@gnu.org>

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






  reply	other threads:[~2009-01-14 22:22 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 [this message]
2009-01-14 23:10               ` Stefan Monnier
2009-01-15  0:52                 ` Drew Adams
2009-01-15  2:41                   ` Stefan Monnier
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='002d01c97696$93c6a190$c2b22382@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=geoffgole@gmail.com \
    --cc=juri@jurta.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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).