GNU bug report logs -
#57207
29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)
Previous Next
Reported by: Ihor Radchenko <yantar92 <at> gmail.com>
Date: Sun, 14 Aug 2022 15:55:01 UTC
Severity: normal
Found in version 29.0.50
Done: Gregory Heytings <gregory <at> heytings.org>
Bug is archived. No further changes may be made.
Full log
Message #245 received at 57207 <at> debbugs.gnu.org (full text, mbox):
>> 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.
>
I'm not sure I understand what you mean. What the modeline should display
is the state of the "user" narrowing, not of a narrowing decided by a Lisp
function. Changing the user narrowing from inside a hook function cannot
be guaranteed to work, as far as I understand, as any other later hook
function could change or undo that narrowing.
>
> 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.
>
Okay, I'll see what I can do.
>> 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.
>
Indeed. As I said, I don't know which path is better. My feeling (which
could again be wrong) is that the current one is safer from a "responsive
Emacs" viewpoint.
This bug report was last modified 2 years and 169 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.