emacs-devel
[Top][All Lists]
Advanced

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

Indicate better the current use of the echo area / minibuffer [was: Cont


From: Drew Adams
Subject: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]
Date: Wed, 12 May 2021 23:47:07 +0000

On this topic of Isearch vs minibuffer, since it's been
broached -

I think most people agree that users often mistakenly
think they're in the minibuffer during Isearch.  That
doesn't help anyone.

As I've said, I, for one, think it's good that Isearch
doesn't use the minibuffer.  But I think it might help
if there were a visual indication of some kind, to
distinguish Isearching from use of the minibuffer, and
Isearching from (other) use of the echo area.
___

With my setup there's no such possible confusion, as I
use a standalone minibuffer frame (which is of course
also used for Isearch and the echo area).

The frame background changes hue slightly for Isearch -
no possible confusion.  And it changes (a different)
hue slightly for inactive (no minibuffer) and for each
recursive minibuffer (new hue for each, up to a limit,
then cycle).

I'm not suggesting that vanilla Emacs use a standalone
minibuffer frame (!).  But I am suggesting that it
might help to provide some visual indication of states
such as the following: (a) whether Isearch is active,
(b) whether the minibuffer is active, and (c) whether
a recursive edit is in progress (and what level).
___

We already have [[...]] in the mode-line for (c).

My tiny library `rec-edit.el' makes the level more
obvious, by optionally highlighting bracket pairs with
different faces (different by default).

And it gives you the single key `C-M-c' to both enter
and exit a recursive edit.  (It exits, unless you use
a prefix arg.)

The behavior is turned on/off with a minor mode.

https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el
___

_Apart_ from indicating recursive editing and level:

I tend to think that indication of the current state
of the echo area / minibuffer is better indicated in
that area itself.

The hue change I mentioned (for a standalone frame)
is a good approach, I think.  The effect is subtle,
not in your face.  You sense the change, more than 
you  consciously register it.  But it's there, so
if you ever do pay attention to it you can tell what
state you're in - what you're doing and expected to
do or not do.

It becomes second nature - you'll never think/feel
that you're in a minibuffer when you're isearching,
and you can easily sense the difference between a
read that doesn't use the minibuffer (it's inactive)
and one that does.

Dunno whether or how much it would be feasible to
make the echo area/minibuffer window have a slight
change in hue to reflect state changes.  Just a
thought.

If we did opt for somehow indicating state change
for this area, I think the indication should be
right there - in that area.  And it should remain
in effect as long as the particular state does.

E.g., it shouldn't consist of a "notification",
such as a message or a flash or ding.  It should
be subtle but perceptive.

Thoughts?

reply via email to

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