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