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

Previous Next

Full log

Message #98 received at 56683 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#56683: 29.0.50; long lines fix doesn't work correctly when
 lines are truncated
Date: Tue, 26 Jul 2022 16:15:10 +0300

> Date: Tue, 26 Jul 2022 12:50:51 +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.
> 
> Do I understand correctly that it's okay to do that on the feature (and 
> later master) branch, and that it will be perhaps be revisited later?

I'd prefer not to do it just yet, and wait for more user feedback
(once the feature branch is merged, which I guess will be soon).

> > 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.
> 
> Sorry, I misunderstood what you said.  Now it's much clearer, indeed. 
> But still, as you say, that puts a limit at around 100 MB, which isn't 
> "that much" nowadays.

Yes, it's not a solution, just a band-aid.  But it costs almost
nothing, and we get to push the problematic situations farther.

Previous Next

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