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: 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Tue, 05 Jul 2022 19:34:31 +0300

> Date: Tue, 05 Jul 2022 16:21:57 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 56393 <at> debbugs.gnu.org
> 
> 
> >> 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).

with-current-buffer can be legitimately called to insert stuff into a
buffer that is displayed.  The macro doesn't know.

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

It means I think the idea is good, but the main part of the
implementation should be on a different level, not using narrowing,
which has a too global effect.

But I'd like to hear more opinions, including from Gerd.  I didn't
think about this long enough to be sure I'm right.

Previous Next

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