GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Sat, 09 Jul 2022 12:20:38 +0300

> Date: Sat, 09 Jul 2022 08:56:16 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.