GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#56682: locked narrowing
Date: Wed, 30 Nov 2022 18:34:15 +0200

To be able to fix bug#56815 I started to test the locked narrowing,
and everything works smoothly with:

  (setq treesit-max-buffer-size 1200000000)
  (push '(js-json-mode . json-ts-mode) major-mode-remap-alist)
  (add-hook 'find-file-hook 'toggle-truncate-lines)

Navigating 1 GB hugedictionary.json exhibits no delays
(the recipe uses treesit to get the correct highlighting).

However, 2 problems encountered:

1. after 'M-g TAB' (move-to-column) to 214748364 or more,
   the display is not updated anymore: moving point to the left
   from this position shows the cursor, moving point to the right
   has no visible effect.  Is it a hard limit in the display engine?
   Its hex value is #xccccccc.

2. after starting Isearch at a large column number,
   Emacs hangs up indefinitely, e.g. with
   'M-g TAB 10000000 RET C-s' then even C-g doesn't get out.
   Debugging shows that the problem is in 'isearch-update'
   where the call to 'pos-visible-in-window-group-p' doesn't return.
   When this call is removed, the search is instantaneous.
   (Optimizing lazy-highlight is a separate problem in bug#56815.)

PS: it seems these problems are not related to the locked narrowing,
rather the locked narrowing helped to expose them, so maybe they
should be reported in a new separate bug report?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.