Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Drew Adams]

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?

Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 12 May 2021 23:47:07 +0000
> 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>
> 
> 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.

There is such an indication: the cursor is not in the mini-window.

RE: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Drew Adams]

> > 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.
> 
> There is such an indication: the cursor is not in the mini-window.

Yes, there is indeed an "indication of some kind".

ABut as the Subject says, this is about _better_
indicating such things - being _more_ helpful.

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Daniel Mendler]

On 5/13/21 4:11 PM, Drew Adams wrote:
>>> 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.
>>
>> There is such an indication: the cursor is not in the mini-window.
> 
> Yes, there is indeed an "indication of some kind".
> 
> ABut as the Subject says, this is about _better_
> indicating such things - being _more_ helpful.

Personally, I would not like to use such a colorful "subtle" indication
in the echo area. To me this seems more like an implementation detail,
which should not be visible to the user.

The echo area/minibuffer distinction comes up from time to time in
discussions with new users. I know that I had been confused for a while
with the Isearch behavior. The Isearch use of the echo area is
unexpected. Users expect to enter a search string into a separate input
form as is common in many other programs. In Emacs this input form is
the minibuffer.

I would welcome the changes by Augusto. The minibuffer-controlled
Isearch makes entering the search string more robust with regards to
various editing commands as mentioned before by Kévin Le Gouguec.

There exists the ctrlf package on MELPA which also uses the minibuffer,
but it feels hardly justified to install an extra package only to get a
minibuffer-controlled search mode. I also don't want to replace such a
tightly integrated component like Isearch with an external package. If a
minibuffer mode can be added to Isearch with small effort and in a
reasonably clean way, why not do that?

Daniel

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Alan Mackenzie]

Hello, Daniel.

On Thu, May 13, 2021 at 16:41:10 +0200, Daniel Mendler wrote:
> On 5/13/21 4:11 PM, Drew Adams wrote:
> >>> 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.

> >> There is such an indication: the cursor is not in the mini-window.

> > Yes, there is indeed an "indication of some kind".

> > ABut as the Subject says, this is about _better_
> > indicating such things - being _more_ helpful.

> Personally, I would not like to use such a colorful "subtle" indication
> in the echo area. To me this seems more like an implementation detail,
> which should not be visible to the user.

> The echo area/minibuffer distinction comes up from time to time in
> discussions with new users. I know that I had been confused for a while
> with the Isearch behavior. The Isearch use of the echo area is
> unexpected. Users expect to enter a search string into a separate input
> form as is common in many other programs. In Emacs this input form is
> the minibuffer.

That's a rather misleading way of portraying it.  Users used to other
programs tend not to be familiar with incremental search, where point is
not in "a separate input form" but in the buffer they're searching
through.  There is no "separate input form".

Besides, currently isearch can be used in the mini-window, searching
through a minibuffer.  If we are not to lose this feature, things will
get complicated and messy.

> I would welcome the changes by Augusto. The minibuffer-controlled
> Isearch makes entering the search string more robust with regards to
> various editing commands as mentioned before by Kévin Le Gouguec.

But it's a gross kludge.  The principle behind the minibuffer is that
the current edit is suspended, and the current window is switched to a
minibuffer window, and (more or less) normal editing happens in that
mini-window until the user terminates it.  This clashes with the concept
of incremental searching, where point stays in the target window at all
times, guided by a sequence of commands, there being no recursive edit.

> There exists the ctrlf package on MELPA which also uses the minibuffer,
> but it feels hardly justified to install an extra package only to get a
> minibuffer-controlled search mode. I also don't want to replace such a
> tightly integrated component like Isearch with an external package. If a
> minibuffer mode can be added to Isearch with small effort and in a
> reasonably clean way, why not do that?

See above.  It would be anything but clean, given the clash between the
way the minibuffer works and the way incremental search works.
Augusto's original patch was ~500 lines long, which scarcely suggests
"reasonably clean".

You seem to be asking for an Emacs internal mechanism (the minnibuffer)
to be used rather than for particular user visible effects to be seen.
Why not concentrate on the latter, so that we can evaluate such
suggestions and incorporate them into the current way isearch is
implemented?

I am worried that these suggestions for using the minibuffer will get
implemented, and searching in Emacs will move from the delightfully
lightweight feature we have at the moment to something awkward and
sluggish, like most other programs' searching is.

> Daniel

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Daniel Mendler]

On 5/13/21 5:24 PM, Alan Mackenzie wrote:
>> The echo area/minibuffer distinction comes up from time to time in
>> discussions with new users. I know that I had been confused for a while
>> with the Isearch behavior. The Isearch use of the echo area is
>> unexpected. Users expect to enter a search string into a separate input
>> form as is common in many other programs. In Emacs this input form is
>> the minibuffer.
> 
> That's a rather misleading way of portraying it.  Users used to other
> programs tend not to be familiar with incremental search, where point is
> not in "a separate input form" but in the buffer they're searching
> through.  There is no "separate input form".

I deliberately took the perspective of a new user here and I am
convinced that the current behavior is problematic. Incremental search
is also present in other programs, where you enter something and "the
buffer" updates accordingly. The only difference here is that the cursor
 stays in the buffer where the search happens. But the location of the
actual cursor is not that relevant, it is a technical detail. There are
also packages emulating and showing multiple cursors using overlays,
e.g., multiple-cursor.el.

> Besides, currently isearch can be used in the mini-window, searching
> through a minibuffer.  If we are not to lose this feature, things will
> get complicated and messy.

I think it is justified to lose this functionality in the
minibuffer-controlled Isearch mode. I never use the Isearch to search or
jump in the minibuffer. On the other hand I would like to edit the
search string using the normal editing commands which are available in
the `fundamental-mode`.

>> I would welcome the changes by Augusto. The minibuffer-controlled
>> Isearch makes entering the search string more robust with regards to
>> various editing commands as mentioned before by Kévin Le Gouguec.
> 
> But it's a gross kludge.  The principle behind the minibuffer is that
> the current edit is suspended, and the current window is switched to a
> minibuffer window, and (more or less) normal editing happens in that
> mini-window until the user terminates it.  This clashes with the concept
> of incremental searching, where point stays in the target window at all
> times, guided by a sequence of commands, there being no recursive edit.

I am not familiar with the details of the Isearch implementation, but I
don't see why it has to be a kludge in principle. If I would start a new
search package, I would certainly use the minibuffer in combination with
a `post-command-hook` (or an `after-change-function`) to update the
buffer incrementally with the search results. It is not difficult to do
that as one can see in the ctrlf.el package.

Stefan Monnier also stated something along these lines:

"I don't know what impacts it might have on the UI, but I've often
wished (from an implementation point of view) that Isearch used an
actual plain old minibuffer rather than mimicking one..."

Therefore I think the characterization of a minibuffer-controlled search
as a "kudge" is not balanced. One could as well criticize the Isearch
since it does not use the minibuffer and deviates from the behavior of
other Emacs commands.

>> There exists the ctrlf package on MELPA which also uses the minibuffer,
>> but it feels hardly justified to install an extra package only to get a
>> minibuffer-controlled search mode. I also don't want to replace such a
>> tightly integrated component like Isearch with an external package. If a
>> minibuffer mode can be added to Isearch with small effort and in a
>> reasonably clean way, why not do that?
> 
> See above.  It would be anything but clean, given the clash between the
> way the minibuffer works and the way incremental search works.
> Augusto's original patch was ~500 lines long, which scarcely suggests
> "reasonably clean".

I agree that 500 lines is long but the current version only adds ~160
lines. I am not sure at which point you consider this a clean patch.

> You seem to be asking for an Emacs internal mechanism (the minnibuffer)
> to be used rather than for particular user visible effects to be seen.
> Why not concentrate on the latter, so that we can evaluate such
> suggestions and incorporate them into the current way isearch is
> implemented?

I want to use the `fundamental-mode` to edit the search string with all
its features. This cannot be achieved by adjusting something in the
current Isearch implementation. The only way to achieve this is by using
a separate buffer in a recursive editing session. There is already
-edit-string` which gives a minibuffer. But then one loses all the
incremental search functionality, which makes this uncomfortable to use.
From what I've seen, Augusto's patch mostly adjusts this command, which
limits the impact of the patch.

> I am worried that these suggestions for using the minibuffer will get
> implemented, and searching in Emacs will move from the delightfully
> lightweight feature we have at the moment to something awkward and
> sluggish, like most other programs' searching is.

I did not try the current version of the patch but the last time I tried
it, I quite liked the result. It didn't feel sluggish and felt natural
as long as one accepts that one is typing in the minibuffer.

Overall, I understand the resistance against the proposed changes. If
one wants to stay in any case within the paradigm of using the echo
area, there is no place for a minibuffer controlled Isearch.
Nevertheless I found it quite astonishing that Augusto managed to create
this relatively small patch (up to debate ;) which substitutes this
central part of the Isearch interaction.

Daniel

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Daniel Martín]

Daniel Mendler <daniel@mendler.net> writes:

>
> The echo area/minibuffer distinction comes up from time to time in
> discussions with new users. I know that I had been confused for a while
> with the Isearch behavior. The Isearch use of the echo area is
> unexpected. Users expect to enter a search string into a separate input
> form as is common in many other programs. In Emacs this input form is
> the minibuffer.

It's unexpected if you come from other applications, but I don't think
it's a bad UX.  Once you get used to how Isearch works, in my opinion
it's much more efficient than using the minibuffer.  For example, it's
very common to use incremental search to navigate to a particular place
in a buffer, and, once you are in the desired position, do something
like C-n, C-v, or C-p to move the point further and end the search at
the same time.  This use case wouldn't be as convenient if incremental
search used the minibuffer.  Try it in the CtrlF package, for example.

>
> I would welcome the changes by Augusto. The minibuffer-controlled
> Isearch makes entering the search string more robust with regards to
> various editing commands as mentioned before by Kévin Le Gouguec.
>

I wouldn't like them.  If you want to edit the search string, you can
just 'M-e' or click on the echo area.  You can also type 'C-M-d' to
delete individual characters, instead of using 'backspace'.

> There exists the ctrlf package on MELPA which also uses the minibuffer,
> but it feels hardly justified to install an extra package only to get a
> minibuffer-controlled search mode. I also don't want to replace such a
> tightly integrated component like Isearch with an external package. If a
> minibuffer mode can be added to Isearch with small effort and in a
> reasonably clean way, why not do that?
>

That's the problem.  Given the amount of subtle use cases currently
supported by Isearch, I think that even adding a separate option to use
the minibuffer would not be a simple implementation (for example, you
can perform an incremental search in the minibuffer itself, etc.).

To be fair, I see some good things about using the minibuffer (for
example, it'd be simpler to perform certain actions, like scrolling the
window, without exiting the search), but all the things that we'll lose
or will change don't quite justify the new feature, IMHO.

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Augusto Stoffel]

> See above.  It would be anything but clean, given the clash between the
> way the minibuffer works and the way incremental search works.
> Augusto's original patch was ~500 lines long, which scarcely suggests
> "reasonably clean".

My patch is ~200 additions, 50 deletions, and this also includes lazy
highlight and lazy count for the good old `isearch-edit-string'.

Alan, I am very much looking forward to your critique of my proposal,
but up to now I'm having a hard time to relate what you say with what's
actually done.  May I suggest you to try it out?  The standalone package
version is very easy to test, just load the .el file and activate
`isearch-mb-mode': https://github.com/astoff/isearch-mb/

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Daniel Mendler]

On 5/13/21 6:16 PM, Daniel Martín wrote:
> It's unexpected if you come from other applications, but I don't think
> it's a bad UX.  Once you get used to how Isearch works, in my opinion
> it's much more efficient than using the minibuffer.  For example, it's
> very common to use incremental search to navigate to a particular place
> in a buffer, and, once you are in the desired position, do something
> like C-n, C-v, or C-p to move the point further and end the search at
> the same time.  This use case wouldn't be as convenient if incremental
> search used the minibuffer.  Try it in the CtrlF package, for example.

Yes, of course. But this is where the preferences may differ. Some
people prefer to navigate the search string, others may prefer to
navigate the buffer and quit the transient Isearch keymap in that case.
The patch by Augusto does not remove the current Isearch mode. The
default would stay as is.

>> There exists the ctrlf package on MELPA which also uses the minibuffer,
>> but it feels hardly justified to install an extra package only to get a
>> minibuffer-controlled search mode. I also don't want to replace such a
>> tightly integrated component like Isearch with an external package. If a
>> minibuffer mode can be added to Isearch with small effort and in a
>> reasonably clean way, why not do that?
>
> That's the problem.  Given the amount of subtle use cases currently
> supported by Isearch, I think that even adding a separate option to use
> the minibuffer would not be a simple implementation (for example, you
> can perform an incremental search in the minibuffer itself, etc.).

The incremental search in the minibuffer is a feature I use rarely. It
is okay if this feature is not available if the minibuffer is used
itself to control the search.

This is not up to me to tell, it seemed the patch by Augusto providing
the minibuffer-controlled search is "full featured", such that it works
as one would except from Isearch, as long as one accepts that the
minibuffer is used for controlling the search.

What other subtle edge cases do you have in mind?

> To be fair, I see some good things about using the minibuffer (for
> example, it'd be simpler to perform certain actions, like scrolling the
> window, without exiting the search), but all the things that we'll lose
> or will change don't quite justify the new feature, IMHO.

Nothing will be lost, except some simplicity. The current Isearch will
stay as is. Only the command `isearch-edit-string` will be made more
incremental with live updating results. From what I've seen the question
is if the "loss in simplicity/purity" is justified since Isearch will
get an additional interaction mode, which deviates from the currently
existing interaction mode.

Daniel Mendler

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Eli Zaretskii]

> Date: Thu, 13 May 2021 15:24:23 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>  "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
>  "kevin.legouguec@gmail.com" <kevin.legouguec@gmail.com>,
>  Eli Zaretskii <eliz@gnu.org>, "arstoffel@gmail.com" <arstoffel@gmail.com>,
>  Drew Adams <drew.adams@oracle.com>
> 
> > The echo area/minibuffer distinction comes up from time to time in
> > discussions with new users. I know that I had been confused for a while
> > with the Isearch behavior. The Isearch use of the echo area is
> > unexpected. Users expect to enter a search string into a separate input
> > form as is common in many other programs. In Emacs this input form is
> > the minibuffer.
> 
> That's a rather misleading way of portraying it.  Users used to other
> programs tend not to be familiar with incremental search, where point is
> not in "a separate input form" but in the buffer they're searching
> through.  There is no "separate input form".

That was true some years ago, but no longer is.  Many other editors
and browsers support incremental search nowadays, and at least some of
them, mostly browsers, indeed expect you to type into a special input
widget.

> I am worried that these suggestions for using the minibuffer will get
> implemented, and searching in Emacs will move from the delightfully
> lightweight feature we have at the moment to something awkward and
> sluggish, like most other programs' searching is.

This alternative UI might indeed be added some day, but only as one
option, and most probably not the default.  So don't you worry.

RE: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Drew Adams]

It seems that this thread has been knee-jerk
hijacked by those intent on pushing a proposal to
base Isearch on the minibuffer.

That's NOT the intention of this thread.
There's another thread for that - please go there
for that.

This thread is about the current (longstanding)
design of Isearch, which is NOT minibuffer-based.

And it's also about the echo area and minibuffer
(independently of any concern with Isearch).

Minibuffer, echo area, and Isearch pattern share
the same screen area.  This thread is about
helping users more easily distinguish the current
state of that area.

[Those insistent on a minibuffer-based Isearch
have been the first to clamor about how confusing
it can be, especially for newbies, that Isearch
doesn't use the minibuffer but it uses the same
screen area.  Where are your voices on this other,
very different question about trying to prevent
or reduce such confusion?]

And of course this feature would be _optional_.
So comments like this one are irrelevant in this
context:

 > Personally, I would not like to use such a
 > colorful "subtle" indication in the echo area. 

That user Jane or Jim might not want any help with
this problem isn't a problem for anyone - they just
wouldn't turn it on.

This isn't about what _you_ might like as a user.
It's about how we might help other users - users in
general.

So far, alas, that comment is the only contribution
to this thread that's been (somewhat) on-topic.  The
rest has all been noise about why we should base
Isearch on the minibuffer.  And Eli has already said
that if _that_ were to be offered it would anyway be
optional for users.  So this problem remains for
Isearch as we've come to know and love it.

How about some ideas for making the state of this
shared screen area more clear to users?

All I've suggested in that regard is that I think a
visual, continuing indication, right there, _in that
area_ is what's called for.  (As opposed to some
ephemeral message, ding, or flash.)

That's my suggestion on the blue-sky whiteboard.
Anyone else have a suggestion?

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Daniel Mendler]

On 5/13/21 7:41 PM, Drew Adams wrote:
> It seems that this thread has been knee-jerk
> hijacked by those intent on pushing a proposal to
> base Isearch on the minibuffer.
> 
> That's NOT the intention of this thread.
> There's another thread for that - please go there
> for that.
> 
> This thread is about the current (longstanding)
> design of Isearch, which is NOT minibuffer-based.
> 
> And it's also about the echo area and minibuffer
> (independently of any concern with Isearch).

Of course, my intention was to hijack "your" thread.

Just to make it clear - my mail is related to your colorful
echo/minibuffer proposal as follows: If Isearch would not use the echo
area as it currently does, there would not even exist a need for an
indicator to make anything more clear.

But please tell me about the different indication modes you have
implemented in your packages. You have a color for the minibuffer and a
color if Isearch is active? Then you change color based on the recursion
level. Are there indicators for other states?

I have written a tiny package, which displays a "recursion indicator" in
the mode line: https://github.com/minad/recursion-indicator. Currently
it displays an arrow per recursion level and a special symbol if a
recursive minibuffer session is active. It makes sense to extend this
with more states, like Isearch. For Isearch I am using a separate
indicator in the mode line:

~~~
(defvar isearch-indicator
  (concat (propertize "Isearch" 'face 'isearch)))
(add-hook 'isearch-mode-hook
          (lambda ()
            (push isearch-indicator mode-line-misc-info)))
(add-hook 'isearch-mode-end-hook
          (lambda ()
            (setq mode-line-misc-info
                  (delq isearch-indicator mode-line-misc-info))))
~~~

Daniel

RE: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Drew Adams]

> > This thread is about the current (longstanding)
> > design of Isearch, which is NOT minibuffer-based.
> >
> > And it's also about the echo area and minibuffer
> > (independently of any concern with Isearch).
> 
> Of course, my intention was to hijack "your" thread.

No, of course not.  But the fact is that there was
a flood of immediate responses that had nothing to
do with the question this thread posed.  Those
contributions are welcome elsewhere.

> Just to make it clear - my mail is related to your colorful
> echo/minibuffer proposal as follows: If Isearch would not use the echo
> area as it currently does, there would not even exist a need for an
> indicator to make anything more clear.

Isearch does use the echo area.  That's the point.
There's a separate thread about a proposal to not
have it do so, as a user choice.  But given that it
does, and it will (at least as a user choice), any
ideas?

And no, there's still the same need to distinguish
the double use of the same area for echo/output and
minibuffer/input.

Users have been at least as confused about those two
sharing the same area as they have been about Isearch
sharing it.  We have some hacks (`minibuffer-message'
for example) that try to finesse that problem.  The
problem exists independently of Isearch.

> But please tell me about the different indication modes you have
> implemented in your packages. You have a color for the minibuffer and a
> color if Isearch is active? Then you change color based on the
> recursion level. Are there indicators for other states?

I described what I do, and I mentioned that it's used
with a standalone minibuffer frame.  I mentioned the
possibility of changing the background in some way
only as one way to indicate state change in the area
itself; that's all.

But what I do or don't do is irrelevant.  I posed an
open question: how might we make more clear to users
which state that area is in, to help them?  That
question is what's raised in this thread.  Ideas?

> I have written a tiny package, which displays a 
> "recursion indicator" in the mode line...

Great!  Welcome.

> Currently it displays an arrow per recursion level and a
> special symbol if a recursive minibuffer session is active.

I mentioned what I have that helps wrt recursive
edit levels (library rec-edit.el) - there's no need
to repeat that description.

And I mentioned what I use to distinguish recursive
minibuffer levels - with a standalone minibuffer
frame.

I suggested that Emacs might do something similar in
that screen area somehow (without a standalone frame).
I specifically asked for other suggestions.  I'm not
aware that the problem has been posed or considered
directly before.

> It makes sense to extend this with more states, like Isearch.
> For Isearch I am using a separate indicator in the mode line:
> ...

That's relevant to this discussion.  I gave some
reasons why I think it's better to put an indication
in the area itself, rather than the mode-line.  But
your suggestion is appropriate.

We of course already have an Isearch indicator in
the mode-line.  But it's relatively simple (just a
minor-mode lighter).

For the particular _state_ of Isearch (not just the
fact that Isearch is in progress, which I think is
better shown somehow in the area itself), and FWIW,
I change the mode-line lighter and parts of the
prompt in various ways to show that too:

* Case-sensitivity is indicated by the lighter changing
  between all uppercase (insensitive) and capitalized
  (sensitive).  For non-regexp search that's `ISEARCH'
  versus `Isearch'.

* Whether search is literal or regexp is also indicated
  with the lighter.  `R*SEARCH' versus `R*search', for
  regexp search (instead of `ISEARCH' versus `Isearch').
  (`R*' to suggest regexp by `*'.  Only 1 char more.)

* Wraparound is indicated by the lighter changing face:
  faces `isearchp-wrapped' and `isearchp-overwrapped'.

  By default the wrapped face just adds a blue overline,
  and the overwrapped face uses a red overline and
  underline, the latter being wavy.  (The same faces are
  used in the prompt.)

* Multi-search is indicated by face `isearchp-multi' in
  the prompt.

(Different pieces of the search prompt get different
faces.  E.g. `failing', `pending', `over', `wrapped',
`regexp', `multi'.)

None of those mode-line indications is super prominent.
They're more there as a reminder, if you bother to look
at the mode-line to see the state.

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Juri Linkov]

> For Isearch I am using a separate indicator in the mode line:
>
> ~~~
> (defvar isearch-indicator
>   (concat (propertize "Isearch" 'face 'isearch)))
> (add-hook 'isearch-mode-hook
>           (lambda ()
>             (push isearch-indicator mode-line-misc-info)))
> (add-hook 'isearch-mode-end-hook
>           (lambda ()
>             (setq mode-line-misc-info
>                   (delq isearch-indicator mode-line-misc-info))))
> ~~~

This displays two isearch indicators.  Wouldn't it be simpler to modify
the existing indicator:

#+begin_src emacs-lisp
(add-hook 'isearch-mode-hook
          (lambda ()
            (put 'isearch-mode 'risky-local-variable t)
            (setq isearch-mode (propertize " Isearch" 'face 'isearch))))
#+end_src

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[John Yates]

Drew,

This is just an idea.  I am prototyping it but do not
have a fully working implementation yet.

I use a separate minibuffer frame.  The idea is to
have a one pixel frame inner border.  The border
changes from matching the background to some
contrasting color when the minibuffer is active.

I am not sure what the analog to the inner border
should be for the non-separate minibuffer frame
scenario.

/john

RE: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Drew Adams]

> Drew,
> 
> This is just an idea.  I am prototyping it but do not
> have a fully working implementation yet.
> 
> I use a separate minibuffer frame.  The idea is to
> have a one pixel frame inner border.  The border
> changes from matching the background to some
> contrasting color when the minibuffer is active.
> 
> I am not sure what the analog to the inner border
> should be for the non-separate minibuffer frame
> scenario.

Sounds good.  And that should be useful also for
distinguishing Isearch.

But it would be hard to use it to show different
recursive-edit levels.  One pixel is not much, when
it comes to feeling/noticing a difference.  But it's
worth experimenting.

As for trying to apply something like that to an
ordinary minibuffer window (not in a separate frame):

There are frame parameters with "border" in their name.
And there is a `tool-bar-border' variable.  But I don't
think there is anything concerning windows with "border"
in the name.

On the other hand, windows have dividers:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Window-Dividers.html

But it looks like they only apply to the window above
or to the left of a given window.  For the minibuffer
window it sounds like you'd have to apply it to the
window above.  Doesn't sound too easy.

Maybe someone else has an idea about this.

Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[martin rudalics]

 > I use a separate minibuffer frame.  The idea is to
 > have a one pixel frame inner border.  The border
 > changes from matching the background to some
 > contrasting color when the minibuffer is active.
 >
 > I am not sure what the analog to the inner border
 > should be for the non-separate minibuffer frame
 > scenario.

There is none.  The best solution I can think of is to tune the
minibuffer window's background.

martin

RE: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]

[Drew Adams]

>  > I use a separate minibuffer frame.  The idea is to
>  > have a one pixel frame inner border.  The border
>  > changes from matching the background to some
>  > contrasting color when the minibuffer is active.
>  >
>  > I am not sure what the analog to the inner border
>  > should be for the non-separate minibuffer frame
>  > scenario.
> 
> There is none.  The best solution I can think of 
> is to tune the minibuffer window's background.

That was my guess also.  But it will be interesting
to see if others come up with some interesting ideas.