bug#56682: locked narrowing

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 30 Nov 2022 10:11:17 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> > There's no need to search the whole buffer, that will cause delays in 
> > very large buffers for no good reason.
> >
> > We've talked about this a few months ago, and you said fixing this was 
> > part of your todo.  I think now is the time.
> >
> 
> Yes, it was and still is part of my todo.  At that point of time I was not 
> at all expecting that Emacs 29 would be released three months later. 
> What I had and still have in mind is too large a change for Emacs 29, so 
> at first glance I think for now we'll have to live with the current 
> solution.

I don't think I understand why it should be problematic or unsafe to limit
the same loop we have to a smaller region of the buffer.

> Note that, apart from Dmitry, nobody reported a problem with that 
> detection mechanism, and Dmitry's recipe with which he spotted that 
> problem does not reflect actual usage.  And note that with the patch I 
> just sent even Dmitry's recipe is fixed.

It should be clear that triggering such long searches should not be too
hard.  The search itself should scale better, similar to the general idea of
narrowing the display code, whose scaling is excellent, precisely because
the region doesn't grow with the buffer size.

> I'll see if I can design something smaller which would be suitable for 
> Emacs 29, however.

Well, I think what I proposed is safe enough already.  But maybe I'm missing
something.