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

Previous Next

Full log

View this message in rfc822 format

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: bug#56393: Actually fix the long lines display bug
Date: Wed, 06 Jul 2022 13:56:06 +0000

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

I don't know.  I only observe that it's often unable to cope with such 
cases.  And this is outside of the scope of the long line display bug, 
it's (possibly) a font-lock bug (or an inherent limitation of font-lock). 
I can try to tackle that bug next, if you want.

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

Okay.  My opinion is that being able to edit a file normally without nice 
colors on its characters is way better than being unable to edit a file. 
But let's agree to disagree.

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

It's never a no-op when it is used as a command.  It can become a no-op 
when it is used internally by a 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.
>

Narrowing has been in Emacs since about forever, so as far as I can tell 
functions that were written without taking the possibility that the buffer 
on display is narrowed into account, and that do not work anymore when the 
buffer is narrowed, have a bug.

Previous Next

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