Re: [WIP PATCH] Controlling Isearch from the minibuffer

[Augusto Stoffel]

On Sun,  9 May 2021 at 22:05, Juri Linkov <juri@linkov.net> wrote:

>> - Does the approach taken here seem sufficiently robust?  Note in
>>   particular the `with-isearch-window' macro, which is now needed around
>>   several functions,
>
> You can avoid the with-isearch-window macro by checking
> in isearch-pre-command-hook if the current buffer is the minibuffer,
> then switch to the original buffer, and let the isearch command to
> do what it normally does, then switch back to the minibuffer
> in isearch-post-command-hook.

That's an interesting idea, thanks.  This indeed makes the changes more
localized, which seems desirable.  (On the other hand, it spreads the
logic currently contained in `with-isearch-window' across various
hooks.)

>
>>   as well as the somewhat hacky `run-with-idle-timer'
>>   call inside the `isearch-mode' function.
>
> You can avoid the timer hack by adding a guard to
> isearch-post-command-hook: when at the end of the isearch command,
> point is not in the minibuffer, activate the minibuffer
> (assuming that isearch-from-minibuffer is t).

That didn't work well, because when canceling a command called from the
post-command hook one gets an ugly error message.

>
>> - Are the slightly backwards incompatible keybinding changes in
>>   `isearch-edit-string' acceptable?
>
> Only when isearch-from-minibuffer is t.

I hope this is a guideline rather than an axiom, so let me describe what
the *slight* incompatible changes are:

1. The user is forced to see lazy highlight and lazy count while editing
   the search string via M-e, as long as these options are already
   enabled globally.
2. A M-s prefix is added to minibuffer-local-isearch-map, as well as a
   few extra commands (M->, M-<, etc.)
3. <right> and C-f are unbound.

>
>> - I don't like the `with-isearch-window-quitting-edit' macro, but I
>>   don't see a different way of achieving the necessary effect.
>
> The with-isearch-window-quitting-edit macro can be avoided the same way
> as the with-isearch-window macro.

I'm not sure this is possible.  Is there a way to get rid of the
minibuffer without returning control to the caller of
`read-from-minibuffer'?  I couldn't find a way to do this, hence the
throw/catch of a continuation function in the current version of the
patch.