From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <834jz3dbva.fsf@gnu.org> References: <87h73ab8bo.fsf@gmail.com> <83zgh2kzlo.fsf@gnu.org> <83y1wlllnc.fsf@gnu.org> <83mtd1li6o.fsf@gnu.org> <835yjpl5vm.fsf@gnu.org> <83y1wljmkn.fsf@gnu.org> <83r12djjvm.fsf@gnu.org> <8a3eaeef01b9a103450a@heytings.org> <835yjkdrrk.fsf@gnu.org> <83r128cane.fsf@gnu.org> <83h734c8wx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20320"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, andreyorst@gmail.com, 56683@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 26 19:28:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGOLu-00056k-JW for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Jul 2022 19:28:14 +0200 Original-Received: from localhost ([::1]:40842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGOLt-000826-M4 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Jul 2022 13:28:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGOKk-0005yD-Rp for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 13:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36333) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGOKk-0000sc-3R for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 13:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oGOKj-0000eG-Nj for bug-gnu-emacs@gnu.org; Tue, 26 Jul 2022 13:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Jul 2022 17:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56683 X-GNU-PR-Package: emacs Original-Received: via spool by 56683-submit@debbugs.gnu.org id=B56683.16588563682413 (code B ref 56683); Tue, 26 Jul 2022 17:27:01 +0000 Original-Received: (at 56683) by debbugs.gnu.org; 26 Jul 2022 17:26:08 +0000 Original-Received: from localhost ([127.0.0.1]:54315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGOJs-0000cq-91 for submit@debbugs.gnu.org; Tue, 26 Jul 2022 13:26:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGOJn-0000cG-9U for 56683@debbugs.gnu.org; Tue, 26 Jul 2022 13:26:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42870) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGOJh-0000k7-NV; Tue, 26 Jul 2022 13:25:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5NjZ8R80j6Z2Djuph2jUFm9JPoZNhoh/SAN+Rjt8JPE=; b=LsFvQYO0OlZg KFyKUE9wKCOBjCV19HaE/eOdIBnCAuMo+vFEBxpdmstZ2TLzOjJcGQ0/+Nz+sPihrGIUiIG33ORmA IZHESGyUboxD3hWuBGusl8bF6XOp5IO4m8/U5R0vXiqYv7bhyA0uPDKcY91nJM728ozaXrRmZMW/y r1DuwESi2aRNsS4wt8cyJ9+MTCE3/t5gWRYaIwbjp+fK8xqOv4bBFt4/vqpJ8CvBxsCpMTeF303Sh 2/CqP+HVUIwx/ycQ7W9O1sqVW3WEMll7AuvcB/P1x/CAY9gH/TJfGuu7hcWQ2oo5apQhUQ5wynTgi wFCNFEUXqbv9miQSTsZ6yA==; Original-Received: from [87.69.77.57] (port=3938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGOJh-0003RI-7L; Tue, 26 Jul 2022 13:25:57 -0400 In-Reply-To: (message from Gregory Heytings on Tue, 26 Jul 2022 13:25:30 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237980 Archived-At: > Date: Tue, 26 Jul 2022 13:25:30 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, andreyorst@gmail.com, 56683@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.