Re: isearch highlighting

[Juri Linkov <juri@jurta.org>]

Richard Stallman <rms@gnu.org> writes:
> I just installed the code for while-no-input.  I think you should
> use that.

I will see how well it works with isearch lazy highlighting timer.

>     This could be fixed in `isearch-lazy-highlight-update' by selecting
>     the window where isearch was activated.
>
> That seems reasonable, but if the idea is to call the
> isearch-lazy-highlight code from query-replace as well, please verify
> that this fix is correct for that case too.  I have no specific reason
> to think it is wrong, I'm just asking you to double-check.

When I proposed this fix, one of the reasons was to make it work
with query-replace too, where the minibuffer is often activated.
So yes, it works with query-replace.

>     3. While typing a sequence of a multi-character input method in the
>     isearch minibuffer, the first part of the isearch string is
>     highlighted in `minibuffer-prompt' face, because it is used as the
>     part of the prompt.  Instead, it could be inserted into the minibuffer
>     as initial-contents.
>
> I suppose you've tested that patch; but I wonder, does this lead
> to a danger of being able to edit that initial contents?

No danger because input method functions don't allow to delete
more previous characters than typed after invocation of the
current input method.

There is also another `read-string' in `isearch-process-search-multibyte-characters'.
but I haven't added `isearch-message' as an initial contents for it,
because I think that no more than one character can be entered
with keyboard-coding-system, and this one character is pushed to
unread-command-events, so `read-string' exits immediately after
starting, and users will not see an incomplete search string
in the minibuffer.

-- 
Juri Linkov
http://www.jurta.org/emacs/