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

Previous Next

Full log

View this message in rfc822 format

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

> Date: Wed, 06 Jul 2022 13:01:39 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> > 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).

Depending on the compromise, that might or might not qualify as a full
and complete solution.  Font-lock is a very important feature, so
disabling it sounds like a heavy price to pay.  Especially since I
don't understand why: if the buffer is narrowed to 30K characters, why
should font-lock be unable to cope?

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

Well, I disagree it's non-essential.

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

I'm talking about the defaults here.  The defaults should allow
editing without sacrificing important features (and ideally without
sacrificing anything).  Otherwise, this isn't a solution, it's a
workaround.  Which is also fine, but we should recognize it as such.

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

It shouldn't be a no-op under any circumstances.  It's an important
command.

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

No, not necessarily.  Lisp code that doesn't expect to find narrowing
simply does nothing about narrowing.

Previous Next

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