Re: [WIP PATCH] Controlling Isearch from the minibuffer

[Juri Linkov]

>>>> 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.
>>
>> How do yo cancel such a command?
>
> C-g

Do you mean the global C-g bound to keyboard-quit,
isearch-mode's C-g bound to isearch-abort, or
minibuffer's C-g bound to minibuffer-keyboard-quit?
And what was the error message?

> To put it from another perspective: you said earlier that my patch could
> be boiled down to 10 lines.  Well, adding lazy highlight/count to
> `isearch-edit-string' is certainly more work than that.  But once this
> is in place, then yes, the minibuffer-controlled mode is a small
> addition.

Adding lazy highlight/count should not be more work.  It's simple to do
with a few lines by setting minibuffer-local isearch-message-function,
the same way like minibuffer-history-isearch-setup sets it to
minibuffer-history-isearch-message.

>>> 2. A M-s prefix is added to minibuffer-local-isearch-map, as well as a
>>>    few extra commands (M->, M-<, etc.)
>>
>> The users might want to use M-< M-> to go to the beginning/end of the
>> minibuffer.
>
> This seems way less useful than going to the first/last match in the
> search buffer, since in the minibuffer C-a and C-e are usually
> sufficient.
>
> By the way, what's the idea behind `minibuffer-beginning-of-buffer'?  It
> moves past the prompt, which is a useless point to go.

It's useful when minibuffer-beginning-of-buffer-movement is customized
to t.  I don't know why currently its default is nil.

> First of all, let me say that you suggestion to get rid of the
> `with-isearch-window' macro works fine.  The remaining problem is with
> commands that create a minibuffer, and therefore require that we quit
> the `isearch-edit-string' minibuffer first.  One example would be
> `isearch-query-replace'.
>
> So here's the the situation in more detail:
>
> - You are in an `isearch-edit-string' session
> - Then you press M-%
> - Now we are in the pre-command-hook. We check `this-command` and
>   see that it will need the minibuffer.
>
> From there, how can we get rid of the minibuffer and continue running
> this-command?  Calling `exit-minibuffer' now would return control to
> whoever called `isearch-edit-string', so `this-command' would never run.

This is an interesting problem.  Would it be possible after calling
exit-minibuffer to allow the caller of isearch-edit-string (mosy likely
the caller should be isearch-mode when isearch-from-minibuffer is t)
to call the right function after exiting from the minibuffer,
e.g. when this-command-keys was M-% then call isearch-query-replace
after isearch-edit-string at the end of isearch-mode.