Re: Making font-lock handle long lines better

[Ryan B]

for the record, i narrowed this down to the maven element of `compilation-error-regexp-alist'. if i remove that element, `compilation-mode' is fast on the minimal test case in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25682 .

it's evidently a somewhat known issue:
https://blog.danielgempesaw.com/post/129841682030/fixing-a-laggy-compilation-buffer
https://www.reddit.com/r/emacs/comments/2b2j5m/emacs_unresponsive_during_compilebuild/
http://comments.gmane.org/gmane.emacs.bugs/28783  (currently down)

On Sat, Feb 11, 2017 at 3:09 PM Anders Lindgren <address@hidden> wrote:

Since it's slow in Fundamental mode as well, it's unrelated to
font-lock, and thus to this thread.  Display of very long lines is
known to be slow in Emacs.

I believe this is a font-lock problem. If you disable global-font-lock-mode before you open the file, it opens in seconds. If global-font-lock-mode is active Emacs stops responding (I gave up after a few minutes).

A quick experiment suggested that the problem is the member `font-lock-extend-region-wholelines' of `font-lock-extend-region-functions' that ensures that whenever font-lock highlights keywords in a region, the full line is rehighlighted (in the case of the example, the full 18M). By removing it, font-locking the file is done in seconds. (I assume that only the visible parts of the buffer is highlighted.)

Clearly, simple dropping the function is not a good idea, as keyword fontification could start anywhere on the line, e.g. in the middle of identifiers. A better approach would be to extend the region to include 10KB in either direction, plus ensure that the region isn't split in the middle of identifiers.

   / Anders

Ps. In case anybody is interested in looking further into this, you can use the tool https://github.com/Lindydancer/highlight-refontification to get visual feedback on the font-lock refontification process.

--

https://snarfed.org/