help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs freezes again when I try to open a file including only one ver


From: Hongyi Zhao
Subject: Re: Emacs freezes again when I try to open a file including only one very long line.
Date: Tue, 28 Jun 2022 21:56:58 +0800

On Tue, Jun 28, 2022 at 9:20 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date: Tue, 28 Jun 2022 20:56:56 +0800
> >
> > > > In scratch buffer, `C-x C-e` the following setting:
> > > >
> > > > (setq max-redisplay-ticks 3000000000000000)
> > > >
> > > > `C-x C-f` to open the file discussed here. If I drag the scroll bar on
> > > > the right side of the window with the mouse, Emacs will lose response,
> > > > as shown in the attached file.
> > >
> > > Why did you set the variable to such a large value?  That effectively
> > > disables the feature.  I told you what value I recommend; why didn't
> > > you use that?  What were you trying to accomplish by using the value
> > > 3000000000000000?
> >
> > It's picked from the following relevant discussion:
> >
> > https://mail.gnu.org/archive/html/bug-gnu-emacs/2022-06/msg01690.html
>
> Why did you think that value was relevant?
>
> This variable is documented, and its documentation tells you how to
> use it.  Please follow the documentation instead of some random
> discussion on the bug list.
>
> > Anyway, I tried with your suggested configuration:
> >
> > (setq max-redisplay-ticks 250000)
> >
> > But the problem remains, as shown in the attached file.
>
> Which problem "remains"?  Don't you see that message at the bottom,
> telling you
>
>   Window showing buffer __tmp.symbols takes too long to redisplay
>
> ?  It is clearly seen in the screenshot you posted.
>
> If you now type "C-x b RET" or "M-x", doesn't Emacs respond normally,
> not after a very long time?
>
> 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.

Regards,
Hongsheng

Attachment: image.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]