GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #742 received at 56682 <at> debbugs.gnu.org (full text, mbox):
>
> I strongly disagree with the necessity to make re-widening technically
> impossible, I find it fundamentally incompatible with Emacs's philosophy
> and can't see any practical justification here.
>
As I said earlier, offering a way to escape the locked narrowing right
away simply means that the current solution isn't one anymore. Elisp
programmers would take the habit of using (widen-unlock) instead of
(widen) in their programs, and in a couple of years we'll see again bug
reports by users who cannot edit buffers with long lines.
>
> Just narrow and make sure jit-lock.el and font-lock.el don't
> accidentally widen it.
>
Now I'm lost. Isn't this what is happening right now: "narrow and make
sure jit-lock and font-lock don't accidentally widen it"? What am I
missing?
>
> Any other accidental widening should be considered as a bug anyway (and
> we could even easily cook up some ad-hoc advice to try and detect those
> cases for people like me who like to run their Emacs with lots of extra
> runtime debugging checks).
>
There are I fear too many bugs related to that problem (you just said that
half of the modes in core do use widen), and it does not seem reasonable
to hope that they will all be fixed anytime soon. If at some point they
are, the current solution will not be necessary anymore, and it will be
very easy to reset the default value of long-line-threshold to nil.
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.