GNU bug report logs - #56683
29.0.50; long lines fix doesn't work correctly when lines are truncated

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: gerd.moellmann <at> gmail.com, andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org
Subject: bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated
Date: Tue, 26 Jul 2022 15:37:41 +0300

> Date: Tue, 26 Jul 2022 12:17:33 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org
> 
> > Maybe optionally.  Or maybe displaying a message/warning suggesting 
> > that.  I don't like disabling truncate-lines unconditionally in such 
> > buffers, I prefer leaving that to the user.
> 
> The user would still have the choice to disable the automatic disabling by 
> setting long-line-threshold to nil.

Yes, I understand.  I still don't like it very much.  But if many
users will complain, we might change that before Emacs 29 is released.

> > And I think we should use INT_MAX instead of DISP_INFINITY, for the 
> > purpose of auto-hscroll.  (There are several other uses of that macro, 
> > but I didn't yet look at all of them to see if it would make sense to 
> > increase DISP_INFINITY itself.)
> 
> But you said earlier that this was undesirable because it would affect 
> performance?

No, I said making the type of the struct member current_x a ptrdiff_t
or intmax_t will affect performance.  The above doesn't propose any
such changes, it just enlarges the "infinity" value.  With that value,
lines up to (/ (expt 2 31) 20) => 107374182 (i.e. about 107 million
characters) per line will still display correctly with truncate-lines
when hscrolling is required.

Previous Next

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