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

Previous Next

Full log

Message #131 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 14:41:08 +0000

>
> I think we must, because font-lock is run by the display engine, and if 
> font-lock makes redisplay significantly slower, it's part of the same 
> problem.
>

I disagree.  It's not the redisplay part that make font-lock slower, but 
how it parses the buffer.  So it's a different problem.

>
> Oh, we agree here: it's definitely way better.  I'm just saying that a 
> complete solution cannot force users to make such sacrifices.
>

Users can reasonably expect and understand that in exceptional 
circumstances a non-essential editing feature is, by default, turned off, 
if the purpose of doing that is to maintain responsiveness.  If you load a 
very big file in a browser (or for that matter in any application), it 
will become sluggish.  Try to open the 1GB hugedictionay.json file with 
vim, nano, VS Code, Atom, and try opening it with the patched Emacs.

(Atom is the only one that displays a warning: "Atom will be unresponsive 
during the loading of very large files. Do you still want to load this 
file?"  If you proceed, Atom becomes unuseable.)

>
> Why is 'recenter' at all relevant, btw?  It isn't called by the display 
> code, AFAIR, so why do we have to disable it?
>

Because commands in auto-narrow-widen-automatically might call "recenter" 
for aesthetic purposes.  One example is end-of-buffer.  Which means that 
what you have is (progn (widen) (recenter)), which takes a few seconds 
without fundamentally changing what is on display.

>
> I think there's a misunderstanding here: what these Lisp programs don't 
> expect is to find narrowing that is different from what the user sees or 
> expects top have.  Narrowing is largely a user-level feature, so using 
> it for internal purposes is problematic at best.
>

Sorry, I don't get what you mean.  Do you have a concrete example of a 
problematic function?

A Lisp program that takes into account the possibility that the user uses 
narrowing and that needs to have access to the whole buffer will use 
(save-restriction (widen) ...).  A Lisp program that requires the user to 
narrow the buffer to work properly will still work, because explicit 
narrowing can still be used with auto-narrow mode.  What are the remaining 
possibilities?

Previous Next

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