bug#56393: Actually fix the long lines display bug

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 09 Jul 2022 08:56:16 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> > . init_iterator is also called to display strings, and I'm not sure I 
> > understand what you intended to do in that case, since BEGV/ZV are not 
> > relevant to strings.
> 
> I guess moving the calculation of the restriction into start_display 
> should fix that problem.  Then it->narrowed_begv will be 0 for strings.

OK.  It wasn't celar to me what you intended to do, because
find_automatic_composition can be also invoked on strings.

> > . The WITH_NARROWED_BEGV macro is IMO awkward and not very convenient to 
> > use in C.  For starters, it cannot accommodate multi-line code, except 
> > via the 'do { ... } while(0);' kludge, which I think will make the code 
> > less readable.  It also should set up an unwind-protect handler, so that 
> > any non-local exit from the code will restore BEGV/ZV.  So I think it 
> > will be better to have two separate functions (and a third one to 
> > unwind).
> >
> 
> Hmmm...  I'll see what I can do.  (But I don't understand why you write 
> that it cannot accomodate multi-line code: you can write 
> "WITH_NARROWED_BEGV (frobnicate (foo); frobnicate (bar));".)

What if the multi-line code includes an if clause or a for loop with
just one line in their bodies?

> > . You currently only apply the "restriction" in a few places where the 
> > code calls functions like find_newline_no_quit.  What about the rest of 
> > display code -- are you saying that it doesn't need to be "restricted"? 
> > or do you intend to add that in the future?
> 
> Yes, that's what I'm saying.  You asked me to make sure that the 
> restriction would have the least possible impact, which I did.

If this is enough, then it's great.  I'm just asking myself how come
font-lock, for example, no longer slows things down as it did before?
Do you understand why?