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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 21 Aug 2022 11:43:41 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com
> 
> > Narrowing inside redisplay itself is okay, provided that it's undone 
> > before we call redisplay_mode_lines.
> 
> I pushed a potential fix to the feature branch.  Does that look correct to 
> you?  It seems to me (but I could very well be wrong) that if we use the 
> actual narrowing bounds inside decode_mode_spec, the mode line will 
> contain the correct information.

Is locked narrowing intended to be used only for pre- and post-command
hooks and similar stuff?  That is, is it not intended for use from any
other Lisp program?

Also, do we know for sure that only the "outermost" narrowing is
supposed to be reflected on the mode line?

> Another way to do it would be to unset and reset the locked
> narrowing for each buffer in the loop inside redisplay_mode_lines, I
> think.

Why not in redisplay_internal?

TBH, I'm extremely nervous about forced narrowing in pre- and
post-command hooks.  Those hooks can run arbitrary Lisp and assume
they can access the buffer without any unexpected restrictions.  I
think applying narrowing here runs afoul of the principle of enforcing
the narrowing in as few places as possible, which IMO is the only way
this technique can avoid breaking too many things.  If some package
puts on these hooks stuff that could run awry when long lines are
present, I'd rather we fixed those packages and/or applied narrowing
"by hand" in their hook functions.  Since long-line-optimizations-p is
not exposed to Lisp, there should be no difficulty in doing that.