Re: Simple isearch concerns

[Augusto Stoffel <arstoffel@gmail.com>]

On Mon,  3 May 2021 at 01:18, Juri Linkov <juri@linkov.net> wrote:

>> 1. Since you probably want to remove the ugly `with-isearch-suspended'
>>    eventually, the local mode will not only be on by default, it will be
>>    the only alternative.  Should then `isearch-buffer-local' be
>>    double-dashed, so it too can be removed?
>
> It could be removed in later releases, indeed.  But OTOH, until
> it's removed, naming a user option with double-dashes is not allowed.
>
>> 2. In edit mode, when I delete a character, the search doesn't backtrack
>>    to the barrier.  It's the same undesirable behavior described in
>>    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46469.  In isearch-mb,
>>    the post-command-hook contains
>>
>>        (goto-char isearch-barrier)
>>        (setq isearch-adjusted t isearch-success t)
>>
>>    for to fix that.
>
> Thanks, this should be added to the patch.
>
>> 3. The after change hook should call `isearch-update' instead of
>>    `isearch-search-and-update' after `previous-history-element' and few
>>    other commands.  In isearch-mb I use a symbol property to keep track
>>    of this.
>
> Thanks, it seems many solutions could be taken from isearch-mb to
> isearch.el.

Actually, since I thought this thing through already, I would be happy
to provide a patch implementing the minibuffer-controlled isearch.

May I suggest that you merge just the `isearch-buffer-local' change at
this point, and then wait for my patch doing the minibuffer part?

>
>> 4. Every time one types a character in the minibuffer, there is a
>>    visible flicker in the cursor.  In isearch-mb I've let-bound
>>    `inhibit-redisplay' to t in a couple of places and it solved this
>>    problem.  I wonder if there's a better solution.
>
> Maybe a flicker is caused by isearch-message?

That's not it, since isearch-mb overrides `isearch-message' completely,
and still requires inhibiting the redisplay.  It seems to be related to
selecting a different window.

>
>> 5. The command `isearch-forward-exit-minibuffer' should eventually be
>>    removed, and instead `isearch-repeat-forward' should work in both
>>    cases (this will probably be implemented with the help of a new
>>    macro).  The reason for this is that there is at least a dozen other
>>    Isearch commands that make sense in the minibuffer map as well
>>    (toggling modes, quitting and entering query-replace, and so on), and
>>    it would be annoying to write a minibuffer variant for each of them.
>
> This is the part where I don't yet have an idea how to handle
> all isearch commands from the minibuffer without using a macro
> to implement their duplicates to be callable from the minibuffer.

I don't think there's another way.  Do you see this as a big problem?

>
>> 6. Why is there the option to specify an `isearch-new-message' in
>>    `with-isearch-suspended'?  I've never seen any valid value other than
>>    `(mapconcat 'isearch-text-char-description isearch-string "")', which,
>>    by the way, repeats at several places in isearch.el
>
> This is just to handle existing uses of with-isearch-suspended that
> currently set isearch-new-message, i.e. this could be changed later.

Actually, in the patch attached to
https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg01359.html
(which by the way, do you think we can merge it?) I added an
`isearch-set-string' function to encapsulate this.

This function would be useful to implement the minibuffer-controlled
mode, as well as for third-party packages and user tweaks.

>
>>> And here is a patch for updating the search from the minibuffer. This allows
>>> to implement https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00447.html
>>> to control the search from the minibuffer.  But I'm not sure if the same option
>>> isearch-buffer-local should enable this mode:
>>
>> I still don't understand why Isearch has to be so stringent about
>> backward compatibility of key sequences.  But I don't care about the
>> edit mode per se.  I only care about an alternative mode where `C-s'
>> immediately goes to the minibuffer, and exiting the minibuffer ends the
>> search.
>
> In such a new mode isearch-edit-string could be called at the end of
> isearch-mode.

True.  `RET' and `C-g', among a few other things, should behave
differently in the two cases, but that's a detail.