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

[Augusto Stoffel]

On Wed, 12 May 2021 at 08:44, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> 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,
>
> [ Sorry I haven't followed this thread very closely, so just a comment
>   from the sidelines: ]
>
> I don't know what this `M-s` thingy refers to, but I for one would very
> much welcome lazy highlighting during the `M-e` minibuffer editing.

The `M-s' thingy would be a prefix keymap including `isearch-occur'
`isearch-highlight-regexp' and what not.

>
>> and (2) adding the entirely optional minibuffer-controlled UI which
>> only takes a dozen of extra lines to implement.
>
> 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 (which doesn't necessary mean
> it'd be a good idea either, just that it would have some benefits and
> that the downsides were not as immediately apparent ;-).

So far, the biggest hurdle I can see concerns the handling of commands
that end the search and read from the minibuffer afterwards, such as
`isearch-query-replace'.  This is tricky because one has to somehow
unwind the `isearch-edit-string' minibuffer without relinquishing
control to its caller.

The first patch I sent in this thread used throw/catch of a continuation
function for this.  The second does the following in a pre-command hook,
which seems to work:

  (when (member this-command isearch-edit--quitting-commands)
    (run-with-timer 0 nil 'command-execute this-command)
    (exit-minibuffer))

I can't think of any simpler alternatives (and I still prefer the
throw/catch solution).

>
>
>         Stefan