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

[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 14:41:08 +0000



I think we must, because font-lock is run by the display engine, and if font-lock makes redisplay significantly slower, it's part of the same problem.


I disagree. It's not the redisplay part that make font-lock slower, but how it parses the buffer. So it's a different problem.


Oh, we agree here: it's definitely way better. I'm just saying that a complete solution cannot force users to make such sacrifices.


Users can reasonably expect and understand that in exceptional circumstances a non-essential editing feature is, by default, turned off, if the purpose of doing that is to maintain responsiveness. If you load a very big file in a browser (or for that matter in any application), it will become sluggish. Try to open the 1GB hugedictionay.json file with vim, nano, VS Code, Atom, and try opening it with the patched Emacs.

(Atom is the only one that displays a warning: "Atom will be unresponsive during the loading of very large files. Do you still want to load this file?" If you proceed, Atom becomes unuseable.)


Why is 'recenter' at all relevant, btw? It isn't called by the display code, AFAIR, so why do we have to disable it?


Because commands in auto-narrow-widen-automatically might call "recenter" for aesthetic purposes. One example is end-of-buffer. Which means that what you have is (progn (widen) (recenter)), which takes a few seconds without fundamentally changing what is on display.


I think there's a misunderstanding here: what these Lisp programs don't expect is to find narrowing that is different from what the user sees or expects top have. Narrowing is largely a user-level feature, so using it for internal purposes is problematic at best.


Sorry, I don't get what you mean. Do you have a concrete example of a problematic function?

A Lisp program that takes into account the possibility that the user uses narrowing and that needs to have access to the whole buffer will use (save-restriction (widen) ...). A Lisp program that requires the user to narrow the buffer to work properly will still work, because explicit narrowing can still be used with auto-narrow mode. What are the remaining possibilities?





reply via email to

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