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#56682: Fix the long lines font locking related slowdowns Date: Thu, 28 Jul 2022 21:57:00 +0300 Message-ID: <83h73183r7.fsf@gnu.org> References: <837d46mjen.fsf@gnu.org> <174616cd5c33bfc14b1f@heytings.org> <837d44jr4p.fsf@gnu.org> <83bktghrn0.fsf@gnu.org> <8a3eaeef010995a5da8d@heytings.org> <837d40ds09.fsf@gnu.org> <83zggwcby5.fsf@gnu.org> <83o7xccagi.fsf@gnu.org> <831qu7daxb.fsf@gnu.org> <83sfmnb7yg.fsf@gnu.org> <837d3ybh5z.fsf@gnu.org> <136c4fe0fc74196714aa@heytings.org> <83pmhp89ov.fsf@gnu.org> <136c4fe0fc39573addc9@heytings.org> <83k07x8738.fsf@gnu.org> <136c4fe0fcdf00ef9a11@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26427"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 28 20:58: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 1oH8i4-0006eo-H9 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Jul 2022 20:58:12 +0200 Original-Received: from localhost ([::1]:36104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oH8i3-00009g-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Jul 2022 14:58:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42900) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oH8hv-00008B-US for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 14:58:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41423) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oH8hu-0006aT-Gu for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 14:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oH8hu-00073R-9s for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 14:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Jul 2022 18:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165903462227029 (code B ref 56682); Thu, 28 Jul 2022 18:58:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 28 Jul 2022 18:57:02 +0000 Original-Received: from localhost ([127.0.0.1]:59405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH8gv-00071n-EF for submit@debbugs.gnu.org; Thu, 28 Jul 2022 14:57:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH8gs-00071X-Rc for 56682@debbugs.gnu.org; Thu, 28 Jul 2022 14:56:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53772) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oH8gm-0006EI-Hc; Thu, 28 Jul 2022 14:56:52 -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=WzhWq+kOeuj9O7miBoufIj6GaZRs+icrwpaE/Lla5K8=; b=FeJlqrYGj20Z HtUpp7WkLTmI+GXYp0vNGiHkltJ55nPytGIpU4e9NQBttihcF/J9p2an6DsVnzVj5f1J4IDY/vXb+ MhvQOBwA1ekR2g7WRr5Ft/kxRSf8sxEIaSXR6CMdbUSAz5AjOFpYbTY5qsm76wScC/e/s7ysu9XJS HlNRk+5CSTtJKcQpFJ4D8AdYVtbAYn3sGuXQ5a3ksKesc2vcXnxcpJ1Jve0gxdL6bsutYR1aQ+NfU aWDi/3cKl16GEF5/RxIvKQvA41nl9CKHtq3Aff5NMLRoN+KxFCpO9wFMHlqqnN6mugsmjd7U1oBEr 2wsGwjCL0OdLQRHE6X6RBQ==; Original-Received: from [87.69.77.57] (port=3823 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 1oH8gl-0003TX-2i; Thu, 28 Jul 2022 14:56:52 -0400 In-Reply-To: <136c4fe0fcdf00ef9a11@heytings.org> (message from Gregory Heytings on Thu, 28 Jul 2022 18:40:26 +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:238130 Archived-At: > Date: Thu, 28 Jul 2022 18:40:26 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca > > > By multiplying a very long and truncated line enough times you can > > always make Emacs useless. The speedups I have in mind scale linearly > > with the number of such lines, so eventually, with enough such lines, > > Emacs will always become very slow at some point, especially if the > > window is hscrolled very far to the right. > > That's exactly my point: with long and truncated lines Emacs can become > unusable with a 20 MB file, with long lines Emacs does not become unusable > even with a 1 GB file. And what I (and everybody I guess) wants is a > "full and complete" solution. Feel free to want it and feel free to wait for it, or work on it. But that doesn't mean I or others cannot meanwhile install less "full and complete" solutions that improve some use cases. And any user can always turn off truncate-lines in such buffers, if some particular use case makes Emacs unusable for them, it's not like this possibility is taken from them. > > That's unrelated. The branch was created for your work on font-lock, > > and if you are done with that, feel free to land it on master. I can > > continue working on master, and/or will create a feature branch if I > > feel it's justified. > > It's not unrelated, at least not in my mind. The branch was initially > created to fix the remaining font-lock related issues, but this thread > discusses, and the branch contains, fixes to the other remaining issues. I worked on truncated-lines case on the branch because without the improvements you installed it was impossible to do anything with that: Emacs was too slow to allow reasonable debugging and measurements. That is the only relation between the two. I don't see any reason to delay landing the important improvements we have on the branch. It will allow more people to use those improvements, and thus will contribute both to their stability and to further progress in this direction. > I don't want to close this bug without a "full and complete" solution, and > currently someone who has (setq truncate-lines t) in their init file or > who presses C-x x t will see Emacs become unusable with a file with long > lines. The bug can be kept open, if you don't want to close it. I don't mind. > What about the following course of action: I add a "disable truncate-lines > in buffers with long lines" feature, and you remove it/disable it/make it > optional later if/when you consider that your fixes make Emacs fast enough > with long-and-truncated lines. No. Please stop pressuring me into making a decision I'm not yet ready to make. There's absolutely no rush. > And we can/should open a new bug report and branch to discuss these > long-and-truncated lines issues and solution attempts. Opening a new bug about that is fine by me.