[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56393: Actually fix the long lines display bug
From: |
Gregory Heytings |
Subject: |
bug#56393: Actually fix the long lines display bug |
Date: |
Wed, 06 Jul 2022 16:57:22 +0000 |
How is it different from the code in the display engine that calls
next-single-char-property-change or remove-text-properties, or loops
over all the overlays at certain position calling overlay-get? In Emacs
nowadays font-lock is almost always called as part of redisplay, so I
don't see how we can separate them and say that this is a different
problem.
Again, I don't know (my understanding of the font-lock machinery is very
limited). I only observe that turning font lock mode off makes things
significantly better. And that turning highlighting off in such files is
what other editors do, too. So at this point I don't see why it wouldn't
be a reasonable thing to do.
I invite you to look at this from a different aspect angle. Your idea
is basically to present to the display engine a small portion of the
buffer, whose size is 30K characters. If you actually cut 30K
characters from any of the files we are using for this work, do you see
Emacs choking on any of them if you don't turn off font-lock and leave
'recenter' as it behaves on master? If not, then why doesn't the same
work with auto-narrow-mode?
That's something I already did, and yes, I do see Emacs choking. Try to
navigate in the attached 30K file. Then try again after turning font-lock
mode off.
(But I do not understand what you mean by "leave 'recenter' as it behaves
on master".)
For example, why not use 2 window-fulls before and after the window
(assuming that gives us a smaller chunk)?
That would mean to compute the dimensions of the window in a command-hook.
I tried to make that hook as efficient as possible, so it is on purpose
that I used a constant there, with something that seemed a reasonable
default, instead of computing it again and again.
The point is that we should try to squeeze the most out of this
narrowing idea, before we start disabling up features. Because
disabling features is a kind of retreat, an indication that we turned
every stone and couldn't make Emacs fast enough, so we are kinda giving
up. And it's too early to give up, IMO.
I agree with that idea/direction, but again I think that at least now
Emacs doesn't do worse than all other editors out there, and in fact it
does way better. If all editors turn off highlighting in such cases, that
must surely be for a good reason. Highlighting means parsing, and parsing
is infinitely more expensive than not parsing.
And to me this means that you see an example of a problem I mentioned
earlier: code from the display engine is used in commands that basically
have nothing to do with redisplay per se, and your current
implementation doesn't take care of those calls into the display code by
commands like recenter, C-v, C-n, etc. I think sooner or later we will
need to present a narrowed buffer to them as well.
You mean, a widened buffer? Yes, that's a question for which I still
don't have a clear answer: is it better to "whitelist" commands that will
always work correctly with a narrowed buffer or to "whitelist" commands
that may require a widened buffer? I tend to think that the latter is
better.
What kind of example do you want to see? What do you mean by
"problematic" in this context?
I mean, an actual example of "Lisp code that expects to have access to the
entire buffer when it has no reason to expect narrowing", that is, Lisp
code that expects to have access to the entire buffer without using
(save-restriction (widen) ...).
Which is why I'm saying that it is better to restrict the display code
via some other means, and leave the narrowing alone. After all, it is
our code that deliberately references BEGV and ZV in the display engine,
so using some other values shouldn't be that difficult, I think.
Yes, I've understood that you want to do something else.
long-line-excerpt.xml
Description: XML document
- bug#56393: Actually fix the long lines display bug, (continued)
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Lars Ingebrigtsen, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Gregory Heytings, 2022/07/05
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/06
- 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/06
- 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/06
- 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/06
- bug#56393: Actually fix the long lines display bug,
Gregory Heytings <=
- bug#56393: Actually fix the long lines display bug, Eli Zaretskii, 2022/07/06
- bug#56393: Actually fix the long lines display bug, Ihor Radchenko, 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/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