On Tue, Jun 28, 2022 at 10:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Tue, 28 Jun 2022 21:56:58 +0800
> > Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >
> > > This is what this feature does: it interrupts a too-long redisplay and
> > > lets you use Emacs regardless -- you can switch to another buffer, or
> > > kill the problematic buffer, or do something else to remedy the
> > > unexpected slowness, instead of having to wait forever for any
> > > response to any Emacs command, which basically makes the session
> > > unusable.
> >
> > Thank you for your explanation, but I find that in this case, the
> > incremental search doesn't work as expected, as shown in the attached
> > file.
>
> "Doesn't work" in what way?

I mean: When I'm typing the searching keyword in the minibuffer,
highlighting the keyword's occurrence in the file, as shown in the
vscode for the same file.

> I think your expectations from what this does are incorrect.  This new
> variable's purpose is to prevent Emacs from becoming frozen and
> unusable because you happened to visit a problematic file.  It doesn't
> make problematic files non-problematic, it just prevents such a file
> from making the session hopelessly frozen without any way to recover.
>
> In your case, you can kill the buffer and then visit it literally, or
> make the file shorter and re-visit it, or decide that this file cannot
> be reasonably edited with Emacs, or something else.  And your Emacs
> session will still be usable and will not freeze -- which was your
> complaint, see the Subject.
>
> IOW, it sounds like your complaint is now something else, not that
> "Emacs freezes again".

Yes. But new problem appears :-(

Best,
Hongsheng