bug#56682: locked narrowing

[Dmitry Gutov]

On 29/11/2022 19:10, Gregory Heytings wrote:

> > 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.
>
> I considered naming it with "radius", but decided not to do it.  This is 
> an implementation detail.  And the docstring says "region around point", 
> from which an attentive reader can infer that half of the region will be 
> before and half of it will be after point.  It does not seem worth the 
> price to introduce separate cases for point at or near BOB and point at 
> or near EOB.

All right. It would have been easier for me to understand, but it's 
nothing critical.

> > 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.
>
> Your analysis is not correct: the delay you see is due to 
> show-paren-mode. Turn it off, and you'll see that going from EOB to BOB 
> is instantaneous.

show-paren-mode does seem to have a tiny effect here, but nothing 
comparable. And when it's on, it seems to blink red (the "mismatch" 
face), indicating that its scan probably stops earlier before it reaches 
the EOB.

Anyway, I'll let you know with more details when I see this again. 
Previously, I would see this effect (multi-second delays) every time I 
test the feature, now it is just gone. Maybe 'make bootstrap' helped.

> > 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).
>
> Unless I misunderstand what you mean, this cannot be a regression: 
> editing dictionary.json was not possible with Emacs 28, editing 
> dictionary-pp.json was.  Even if the former were now snappier than the 
> latter, that would not be a problem in itself.

I'm mostly talking about how editing dictionary-pp.json became slower.

The fact that editing dictionary.json is now faster than that is, while 
counter-intuitive, definitely not something to complain about by itself.

> > 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.
>
> I cannot reproduce that.  With emacs -Q, with dictionary-pp.json and 
> with show-paren-mode disabled, type C-s aan zich RET.  Now type some 
> text: in both cases the effect is near instantaneous here, and I do not 
> see any random pauses.

Right. "aan zich" is not far from EOB.

My scenarios are all near BOB.

> With your benchmark and with dictionary-pp.json:
>
> - on current master, after C-s eman RET, I see ~100 ms, and after C-s 

Note the 100 ms.

> aan zich RET, I see ~100 ms

"eman" is near BOB for you as well, right?

> - at ff57f30bee (30 July), after C-s eman RET, I see ~20 ms, and after 
> C-s aan zich RET, I see ~2700 (!) ms
>
> - at c59b8dfefa (30 Jun), after C-s eman RET, I see ~20 ms, and after 
> C-s aan zich RET, I see ~2700 (!) ms

Note the 20 ms.

> - with Emacs 28, after C-s eman RET, I see ~20 ms, and after C-s aan 
> zich RET, I see ~3000 (!) ms

Yup, the long delays near EOB are expected, I fixed them in js.el not 
too long ago (one in font-lock rules, and anothing by creating 
js-json-mode).

> With your benchmark and with dictionary.json:
>
> - with current master, after C-s eman RET, I see ~70 ms, and after C-s 
> aan zich RET, I see ~70 ms
>
> So there is no regression as far as I can see.

Your observations seem to match mine.

Look at the timings for dictionary-pp.json. After C-s eman:

master: ~100 ms
ff57f30bee, or c59b8dfefa, or Emacs 28: ~20 ms

That's the regression.

But like Eli said, it might be unrelated your code, it just seems to 
belong to the same general area. If my guess was wrong, I apologize.