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

[Daniel Mendler <daniel@mendler.net>]

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