GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

Message #86 received at 56393 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Wed, 06 Jul 2022 13:01:39 +0000

>
> 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?

Previous Next

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