bug#56682: locked narrowing

[Eli Zaretskii]

> Date: Thu, 01 Dec 2022 21:36:03 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> 
> >> 1. M-: (let ((large-file-warning-threshold nil)) (find-file 
> >> "dictionary.json") (narrow-to-region 4000000 4004000)) RET
> >> 2. C-x n w
> >> 3. Kaboom!
> >
> > By "Kaboom!" you mean what? a crash?  Because it doesn't crash here. 
> > This is a build from the latest emacs-29 branch.
> >
> 
> I mean that Emacs is trapped in the long line problem again, don't you see 
> it?

No, not in particular.  Maybe you use a different file?

But anyway, what exactly does this prove, and how?  I asked why we need to
look beyond the narrowing, so how does the above answer that question? what
am I missing?

> > This is all beyond argument.  We do want the heuristic.  I just want it 
> > to be cheaper than it is now, especially for buffers without any long 
> > lines, where each time we run this loop we waste CPU cycles.  So I'm 
> > looking for ways of wasting less of them.
> 
> There are none, or at least none that I can see.  Your proposed heuristic 
> to limit the scan to some portion of the buffer around point cannot work, 
> precisely because the loop is not called during each redisplay cycle, but 
> only from time to time.  See the example above.  Again, we cannot know 
> what happened in the buffer between these two moments, which could be far 
> away in time. We can either use a heuristic on the whole buffer, or not 
> use a heuristic and scan only a portion of the buffer.  We cannot combine 
> both, and use a heuristic on a portion of the buffer.  It would simply be 
> too unsafe.

I give up.  I will probably try to find time to code this myself, since you
don't even want to try.