GNU bug report logs - #57207
29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 57207 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)
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.

Previous Next

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