From: Hongyi Zhao <hongyi.zhao@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
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 [thread overview]
Message-ID: <CAGP6PO+eCyxQccveh75GVgJzA99FQgh-VSxZaavq=aqt3FY+0g@mail.gmail.com> (raw)
In-Reply-To: <83leth6iga.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]
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 #2: image.png --]
[-- Type: image/png, Size: 294309 bytes --]
next prev parent reply other threads:[~2022-06-28 13:56 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 0:51 Emacs freezes again when I try to open a file including only one very long line Hongyi Zhao
2022-06-27 1:58 ` Emanuel Berg
2022-06-27 2:29 ` Eli Zaretskii
2022-06-27 2:36 ` Hongyi Zhao
2022-06-27 11:02 ` Eli Zaretskii
2022-06-27 11:22 ` Hongyi Zhao
[not found] ` <CAGP6POKVBGL+gKOLAcqPxgFKzAC9bObW-Hzz-pWCj6mpxtCnAg@mail.gmail.com>
[not found] ` <83tu856ny2.fsf@gnu.org>
2022-06-28 12:56 ` Hongyi Zhao
2022-06-28 13:11 ` Eli Zaretskii
2022-06-28 13:56 ` Hongyi Zhao [this message]
2022-06-28 14:18 ` Eli Zaretskii
2022-06-28 14:38 ` Hongyi Zhao
2022-06-28 15:53 ` Eli Zaretskii
2022-06-29 1:05 ` Hongyi Zhao
2022-06-29 1:35 ` Emanuel Berg
2022-06-29 2:36 ` Eli Zaretskii
2022-06-29 2:48 ` Hongyi Zhao
2022-06-29 11:16 ` Eli Zaretskii
2022-06-29 11:25 ` Hongyi Zhao
2022-06-29 11:37 ` Eli Zaretskii
2022-06-29 12:22 ` Hongyi Zhao
2022-06-29 14:11 ` Eli Zaretskii
2022-06-29 14:30 ` Hongyi Zhao
2022-06-29 16:03 ` Eli Zaretskii
2022-06-30 0:38 ` Hongyi Zhao
2022-06-30 5:41 ` Hongyi Zhao
2022-06-30 12:09 ` Michael Heerdegen
2022-06-30 12:52 ` Michael Heerdegen
2022-06-30 13:56 ` Eli Zaretskii
2022-06-30 14:16 ` Michael Heerdegen
2022-06-30 14:22 ` Eli Zaretskii
2022-06-30 14:32 ` Michael Heerdegen
2022-06-30 15:54 ` Eli Zaretskii
2022-06-30 14:36 ` Michael Heerdegen
2022-06-30 16:04 ` Eli Zaretskii
2022-07-01 11:17 ` Michael Heerdegen
2022-06-29 6:44 ` Manuel Giraud
2022-06-29 11:20 ` Eli Zaretskii
2022-06-30 8:29 ` Manuel Giraud
2022-06-30 12:02 ` Manuel Giraud
2022-06-30 12:43 ` Emanuel Berg
2022-06-30 12:53 ` Emanuel Berg
2022-06-30 13:35 ` Manuel Giraud
2022-06-30 13:36 ` Hongyi Zhao
2022-06-30 13:40 ` Eli Zaretskii
2022-06-28 15:06 ` Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGP6PO+eCyxQccveh75GVgJzA99FQgh-VSxZaavq=aqt3FY+0g@mail.gmail.com' \
--to=hongyi.zhao@gmail.com \
--cc=eliz@gnu.org \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).