bug#56682: locked narrowing

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Gregory,

On 26/11/2022 16:14, Gregory Heytings wrote:

> I pushed another change to the feature/improved-locked-narrowing branch, 
> which makes the locked narrowing around low-level hooks (and therefore 
> around fontification-functions) configurable.  I hope that addresses 
> your concerns.

Thank you, this looks like a step in the right direction.

But I tried to see the effects of this new variable 
(long-line-locked-narrowing-region-size), and it was a little puzzling.

With the default value (500000) I open dictionary.json and start hitting 
PgDn a lot. Syntax highlighting starts to look broken at the buffer 
position that's around half that: at my last attempt it was at point 259999.

Looking at the code, there is indeed some halving going on, so maybe it 
would be more easier to understand if the variable was called 
locked-narrowing-radius, and used as such -- without division.

Either way, though, if I set the var to a very large value, the syntax 
highlighting looks okay.

Another thing that bothered me when testing: going from eob to bob in 
dictionary.json took ~4 seconds every time, independent of buffer being 
edited or not. And that delay didn't show up anywhere in the profiler. 
(setq bidi-inhibit-bpa nil) didn't help at all, but (setq 
bidi-display-reordering nil) eliminated that delay. So I'm still kind of 
puzzled why we bother to restrict font-lock, but didn't do that with 
this significantly more costly computation. The value of 
long-line-locked-narrowing-region-size (big or small) has no effect on it.

Going back higher level, I wanted to repeat that don't understand why we 
apply narrowing around font-lock in buffers with long lines, but not in 
large buffers without long lines. Or vice versa.

And we'll probably come back to this question sometime later, but here's 
something that looks like a regression. Editing dictionary.json is 
snappier than dictionary-pp.json (same file but pretty-printed so 
without long lines).

Even with with common setup (and emacs -Q):

1. (setq long-line-locked-narrowing-region-size 50000)
2. (setq bidi-display-reordering nil)
3. Toggle show-paren-mode off, just in case.
4. electric-pair-mode off, same.

typing in the latter file exhibits random pauses in redisplay up to 0.5s 
(and sometimes 1s+). I haven't managed to catch the exact source of 
those pauses (and they're longer with my personal config), but even 
regular editing is slower: evaluating

   (benchmark 1 '(progn (insert " ") (redisplay t)))

in dictionary.json reports something like 0.038906s, but in 
dictionary-pp.json it prints ~0.136387s.

Commit 89a10ffc (before the last merge) behaves the same, but going 
further back, this commit from July behaves differently: b283e36cf19.

Emacs built from that version reports ~0.033022s in dictionary-pp.json 
and 0.114781s at bob in dictionary.json (scrolling to the end 
predictably freezes that Emacs build).