bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements


From: Gregory Heytings
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]