Re: isearch highlighting

[Juri Linkov]

>> The reason is that while-no-input doesn't work with
>> immediate_quit.
>>
>> Does this patch make it work well?
>
> No.  The first key ends the execution of body.  This part is fixed,
> right.  But during reading the next key (when control returns to the
> top command loop) it goes into an infinite loop in
> wait_reading_process_output not interruptible even with C-g.

`while-no-input' is more reliable now, but once I managed to put
it to an infinite loop in wait_reading_process_output.  I can't repeat
this anymore.  Whereas I can look at it more, I want to note that
using `while-no-input' in `isearch-lazy-highlight-update' instead of
`with-local-quit' will require major changes in `isearch-lazy-highlight-update'.

`with-local-quit' was added for very rare cases where search functions
go into an infinite loop and so interrupting them with C-g and leaving
the rest of matches unhighlighted is much better than killing Emacs.
Trying to continue highlighting of other matches in this case will
likely put Emacs into another infinite loop.

But `while-no-input', where any normal key (including most frequent
C-s repeating the search) can quit the `isearch-lazy-highlight-update',
requires significant changes: after quitting it should restart the
timer and restore everything (global variables and overlays) to the
initial state.  This is the only way I see to avoid incomplete states.

Is it worth doing this now considering that the default value of
lazy-highlight-max-at-a-time (20) already provides quite good
responsiveness of isearch to key presses.

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