Re: [External] : Re: [WIP PATCH] Controlling Isearch from the minibuffer

[Augusto Stoffel]

On Tue, 11 May 2021 at 15:34, Drew Adams <drew.adams@oracle.com> wrote:

>> The question is whether it makes sense to provide an
>> alternative UI for Isearch where editing the search
>> string is not a special maneuver.
>
> Really?  Is that what this is all about?

Yes.

>
> Just what is the giant inconvenience you find with
> Isearch's `M-e' for editing the search string?

To give one reason, M-e currently has no lazy highlight/count, so it's
not of much help to write a mildly complex regexp.

> [...]

> For 40 years Isearch has won the world by NOT using
> the minibuffer (except for one-off, on-demand pattern
> editing).  Zillions of search UIs have adopted the
> incremental searching that Isearch pioneered.  (The
> "i" in "isearch" is for "incremental".)

If it were called OK-search, where OK stands for overriding keymap, then
I would understand the talk of throwing out babies.

However, my proposal in no way diminishes the incremental aspect of
I-search.

> [...]
>
> But though this was pitched as just adding an
> "alternative" behavior, the code changes seem deep
> and wide-ranging,

You can think of my patch as (1) adding lazy highlight/count and an M-s
prefix to the good old M-e, which is indeed a bit of work, and (2)
adding the entirely optional minibuffer-controlled UI which only takes a
dozen of extra lines to implement.

If you have a technical argument as to why there shouldn't be lazy
highlight/count in the good old M-e, it won't be hard to persuade me.

> and IIUC, there was even talk of
> the "alternative" arrangement being just temporary,
> i.e., that Isearch would eventually always follow
> your "alternative" implementation and behavior.

Where?

>
> Why so?