Re: Simple isearch concerns

[Juri Linkov]

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

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

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

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

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