emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [WIP PATCH] Controlling Isearch from the minibuffer


From: Juri Linkov
Subject: Re: [WIP PATCH] Controlling Isearch from the minibuffer
Date: Tue, 11 May 2021 00:17:09 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)

>> 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?

> 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.

Why not enable these incompatible changes only when isearch-from-minibuffer is 
t?

> 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.

> 3. <right> and C-f are unbound.

Removing <right> and C-f is a very good thing, indeed.

>> 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.

Why not return control to the caller with `exit-minibuffer'?
When still necessary, you could try `exit-recursive-edit'.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]