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

[Eli Zaretskii]

> Date: Sun, 21 Aug 2022 12:42:05 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 57207@debbugs.gnu.org, yantar92@gmail.com
> 
> > 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?
> 
> Stefan said (IIUC) that it could be useful for Lisp programs, so it is now 
> possible to use it anywhere (but the docstring says that it should be done 
> sparingly).

Which means that the code you installed on the branch will "undo" such
narrowing done from Lisp as well, doesn't it?  That might not be what
the Lisp program which did that wanted.

> >> 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?
> 
> In general I prefer to act on lower levels if possible.  But yes, indeed, 
> it could be moved above decode_mode_spec and redisplay_mode_lines, in 
> echo_area_display or redisplay_internal.

It is better to do that higher, because not only those places in
decode_mode_spec may wish to access BEGV and ZV.  Even in the
mode-line display there are :eval and :when.

> > 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 now exposed to 
> > Lisp, there should be no difficulty in doing that.
> 
> I don't know.  As far as I can see it doesn't seem to create many 
> problems

I fear this is just the tip of the iceberg.

> and it will happen only in "too large" buffers anyway.

Yes, but these hooks run stuff that doesn't necessarily access buffer
text or look far away of the viewport.

> IMO we should just give it a try, it will always be possible to step
> back if it transpires that the cost is higher than the benefit.

That's we are doing.  But we could also do it the other way around:
fix the places we know are problematic in Lisp, and then wait for
enough such problems to appear elsewhere.