GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
View this message in rfc822 format
>
> I think we should decide what kind of feature this one is supposed to
> be. Is this really the full and complete solution of the long-line
> display problems, or is this just a way to prevent Emacs from being
> sluggish/not responsive by any means deemed necessary?
>
As far as I can tell, it's a full and complete solution, which makes a few
compromises (as few as possible).
>
> If this is supposed to be the complete solution, such that we don't need
> any others, then it shouldn't interfere with editing and shouldn't
> disable useful features such as font-lock,
>
Font locking is as far as I can see the main reason why Emacs is still a
bit sluggish in such cases. Font locking is surely a useful feature, but
it's not essential to edit a file. And users who for some reason prefer
not to disable font locking can do so by removing turn-off-font-lock-mode
from the auto-narrow-mode hook.
>
> shouldn't make commands a no-op (as it does now with 'recenter'),
>
It's not no-op, it's no-op when if and only if it is called on a
temporarily widened buffer when auto-narrow-mode is on. So you can still
use C-l as usual everywhere.
>
> and shouldn't get in the way of Lisp code that expects to have access to
> the entire buffer when it has no reason to expect narrowing.
>
Lisp code that expects to have access to the entire buffer is typically
embedded in a (save-restriction (widen) ...) form, isn't it? Or IOW, Lisp
code that expects to have access to the entire buffer without being
embedded is such a form has a bug, isn't it?
This bug report was last modified 3 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.