bug#56682: locked narrowing

[Dmitry Gutov]

On 29/11/2022 22:11, Gregory Heytings wrote:

> > > - 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).
>
> So what?  We had in that file 20 ms at BOB and 3000 ms at EOB, which 
> means an average of 1500 ms (in that file).  Now we have 100 ms at BOB 
> and EOB, which means an average of 100 ms (in that file).  How can that 
> be a regression?

But the improvement near EOB in this scenario down from 1500 ms is not 
necessarily from the long-lines feature.

Like Eli pointed out, try (setq long-line-threshold nil).

The result will be that the benchmark will report ~30ms both near BOB 
and near EOB. So the long-lines-threshold thingy adds a regression here.

Again, not trying to criticize or anything, but a 100ms is usually 
considered as something that brings an operation from appearing 
"instantaneous" down to "noticeable delay". Since we're trying to make 
editing large files easier and snappier, that seems worth fixing.

Not to mention that the user might have other features enabled that can 
add a multiplier on top of this delay -- which is apparently the case in 
my personal configuration.