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

Previous Next

Full log

Message #47 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: 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Tue, 05 Jul 2022 16:21:57 +0000

>> As I said, if that's the case, it's easy to add a "(let 
>> ((auto-narrow-long-line-threshold nil))" around the code, in this case 
>> either in the with-temp-buffer macro or in the code above.
>
> These macros are called a lot, and I don't think it's a good idea to 
> tell all their callers to make such changes.
>

As I said, this can also be done inside the with-temp-buffer macro.  A 
(very quick) review of calls to insert-file-contents in Emacs core and 
ELPA tells me that that the majority of these calls are inside a 
with-temp-buffer or with-current-buffer (with a temporary buffer).

>
> I think we should try to work out a solution that only affects the C 
> code in the display engine, such that any Lisp called from the various 
> hooks and places in display code is not affected, and neither are 
> pre-command-hook and post-command-hook.  That should have almost the 
> same effect, performance-wise, but be much safer than the automatic 
> narrowing that affects everything in Emacs as long as the narrowing is 
> in effect.
>
> IOW, replace all BEGV and ZV in display code with a couple of new 
> macros, which effectively "narrow" the buffer, as far as the display 
> engine is concerned.  Then set the limits of this restriction in 
> redisplay_window, and remove it when the window's redisplay is done. Or 
> something along these lines.
>

I guess this means, in essence, to throw away the patch?  Or do I 
interpret what you wrote too negatively?

Previous Next

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