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 20:26:01 +0300

> Date: Tue, 26 Jul 2022 13:25:30 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org
> 
> >> 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).
> 
> Wouldn't it be easier to get useful user feedback if that automatic 
> disabling was present on master?  If it's absent, what kind of user 
> feedback can we expect to decide what is better for Emacs 29?

My feeling is that we didn't yet exhaust the potential for speedups by
ways other than by turning off features.  So the feedback I'd like to
get is more use cases where the current speedups are still not enough,
so that we could identify additional ones.  Once we get to the point
where either there's no more significant feedback or we see no way of
solving the reported issues by measures like those we took till now,
we will have to consider which features to give up and in what
situations.

The font-lock effect is a good case in point: if we were to decide to
turn it off when there are long lines, we'd have missed the speedup
you just installed.  I think there are more opportunities like that,
or at least there could be.

> It does indeed, but alas the fact that displaying such buffers is 
> noticeably slower with truncate-lines remains.  I could perhaps take a 
> look (after finalizing and merging the current branch), but I'm not really 
> sure it's worth the price.

We already display such buffers faster on the branch than on master,
and, the Isearch issue aside (I will describe what I found in a
minute), there could be more speedup opportunities for that.
truncate-lines is an important feature (we just heard someone
explaining one such use case), so I'd like to make it as performant as
we can before we decide whether it's really necessary to turn it off.

Previous Next

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