unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Drew Adams" <drew.adams@oracle.com>,
	"Kévin Le Gouguec" <kevin.legouguec@gmail.com>
Cc: Alan Mackenzie <acm@muc.de>,
	Augusto Stoffel <arstoffel@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
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	[thread overview]
Message-ID: <SA2PR10MB4474CDC1DB201F4F4E73788BF3529@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)

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	other threads:[~2021-05-12 23:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 23:47 Drew Adams [this message]
2021-05-13  6:28 ` Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer] Eli Zaretskii
2021-05-13 14:11   ` [External] : " Drew Adams
2021-05-13 14:41     ` Daniel Mendler
2021-05-13 15:24       ` Alan Mackenzie
2021-05-13 16:12         ` Daniel Mendler
2021-05-13 16:21         ` Augusto Stoffel
2021-05-13 16:44         ` Eli Zaretskii
2021-05-13 16:16       ` Daniel Martín
2021-05-13 16:33         ` Daniel Mendler
2021-05-13 17:41       ` Drew Adams
2021-05-13 18:07         ` Daniel Mendler
2021-05-13 19:36           ` Drew Adams
2021-05-14 21:02             ` John Yates
2021-05-14 21:55               ` Drew Adams
2021-05-15  7:57               ` martin rudalics
2021-05-15 19:46                 ` Drew Adams
2021-05-14 18:16           ` Juri Linkov

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=SA2PR10MB4474CDC1DB201F4F4E73788BF3529@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=acm@muc.de \
    --cc=arstoffel@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=kevin.legouguec@gmail.com \
    --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).