[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56393: Actually fix the long lines display bug
From: |
Eli Zaretskii |
Subject: |
bug#56393: Actually fix the long lines display bug |
Date: |
Sat, 09 Jul 2022 12:13:35 +0300 |
> Date: Sat, 09 Jul 2022 08:24:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, Gerd Möllmann <gerd.moellmann@gmail.com>,
> 56393@debbugs.gnu.org
> > I see that you decided to produce the "restriction" in init_iterator,
> > which would, of course, work, but IMO it has a disadvantage:
> > init_iterator is called a lot, so computing the "restriction" in it
> > should be very fast. Your current implementation _is_ fast, but AFAIU
> > its result is that we _always_ restrict the display code from seeing the
> > entire buffer, even if there are no long lines in it, which I think is
> > unnecessary. The original implementation only did that when it detected
> > a long line, and I think we should keep it that way, because the
> > "restriction" will inevitably have some negative effects, however minor,
> > on what we display.
>
> I don't think we can detect long lines reliably enough. The problem of
> the original implementation is what Gerd mentioned: "What happens when
> evaluating an expression in *scratch* that returns a really large result?
That problem doesn't exist when you run the detection code at the
beginning of redisplay (either in redisplay_window or in start_display
or in init_iterator), because by the time redisplay runs the buffer
text was already updated by the insertion that is the result of the
evaluation.
> Or maybe in a Shell buffer some large output?" and similar cases, like
> inserting the result of a shell command in the buffer. Detecting long
> lines in insert-file-contents is not enough to make sure that Emacs will
> always continue to behave normally when a long line is on display.
I agree, but doing this in insert-file-contents was not what I had in
mind.
> Note that we the current implementation does not always restrict display
> code from seeing the entire buffer, it does so in a few well-chosen
> places, everywhere else the display code sees the entire buffer.
And this is enough to make Emacs responsive? If yes, that's great.
- bug#56393: Actually fix the long lines display bug, (continued)
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/07
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/07
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/07
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/07
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/09
- bug#56393: Actually fix the long lines display bug,
Eli Zaretskii <=
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/09
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/09