bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)

[Eli Zaretskii]

> Date: Sat, 20 Aug 2022 23:22:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com
> 
> 
> Actually, that bug is a symptom of a problem that happens everywhere in 
> decode_mode_spec: whenever BEGV and ZV are used, their values could be 
> wrong if the calculation happens when locked narrowing is in effect.

That's true, but only if redisplay is triggered while the narrowing is
in effect.  This is why the strategy of using narrowing as little as
possible should be adhered to as meticulously as possible.

Narrowing inside redisplay itself is okay, provided that it's undone
before we call redisplay_mode_lines.

Hooks and timer functions are especially problematic because they can
run any arbitrary Lisp, and they can (and do) trigger redisplay as
part of their code.

> One thing I don't understand there is that in some places we use BEGV and 
> ZV (namely, case 'i' and case 'I'), and everywhere else we use BUF_BEGV 
> (b) and BUF_ZV (b).  These should be equivalent given that b is set to 
> current_buffer, but perhaps I'm missing something.

If you can be sure that b is the current buffer, then yes.

> Is it also guaranteed that XBUFFER (w->contents) == current_buffer?

No, not in general.  Not even everywhere in redisplay_window, as I
recently learned.  But it is true in the low levels of the display
code, the ones that use the iterator object and functions that
manipulate iterators.