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

From: Gregory Heytings <[email-masked]>
Date: Sun, 21 Aug 2022 12:42:05 +0000

>
> 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).

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

Given how the "outermost" narrowing is calculated (perhaps "outermost" is 
not the best name, I did not find a better one), yes, I think so.  The 
outermost narrowing is the narrowing before locked narrowing is entered.

>> 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.

>
> 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, and it will happen only in "too large" buffers anyway.  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.