emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Annoying paren match messages in minibuffer


From: Drew Adams
Subject: RE: Annoying paren match messages in minibuffer
Date: Fri, 16 Jan 2009 11:10:30 -0800

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]