bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated

[Eli Zaretskii]

> Date: Tue, 26 Jul 2022 12:50:51 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, andreyorst@gmail.com, 56683@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.