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: Sun, 31 Jul 2022 09:16:43 +0300 Message-ID: <83tu6x4xis.fsf@gnu.org> References: <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> <83h73183r7.fsf@gnu.org> <136c4fe0fc0fceb0d752@heytings.org> <838roc8ka7.fsf@gnu.org> <83tu706obt.fsf@gnu.org> <83h7306ifa.fsf@gnu.org> <83edy37pul.fsf@gnu.org> <83pmhn55sk.fsf@gnu.org> <65cb7c73fdc753518d35@heytings.org> <83fsii68o3.fsf@gnu.org> <65cb7c73fdf6704d19d5@heytings.org> <835yje62vz.fsf@gnu.org> <65cb7c73fd159efe32af@heytings.org> <83zggq4fgb.fsf@gnu.org> <65cb7c73fd6ca16565e1@heytings.org> <83y1wa4e6q.fsf@gnu.org> <65cb7c73fdbf1de53ea7@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30987"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.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 Sun Jul 31 08:18:21 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 1oI2HM-0007tr-GW for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 08:18:20 +0200 Original-Received: from localhost ([::1]:53592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oI2HK-0007Rq-L8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 02:18:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI2H5-0007RX-Bi for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 02:18:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46540) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oI2H5-0006jE-0B for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 02:18:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oI2H4-0002tK-E1 for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 02:18: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: Sun, 31 Jul 2022 06:18: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.165924822711045 (code B ref 56682); Sun, 31 Jul 2022 06:18:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 31 Jul 2022 06:17:07 +0000 Original-Received: from localhost ([127.0.0.1]:36289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI2GA-0002s4-Vd for submit@debbugs.gnu.org; Sun, 31 Jul 2022 02:17:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI2G7-0002rW-VV for 56682@debbugs.gnu.org; Sun, 31 Jul 2022 02:17:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50730) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI2G2-0006fs-BV; Sun, 31 Jul 2022 02:16:58 -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=4DkArPgSTbh68sRac9gjVR9e6f41MKQ0EXVQI/y5svI=; b=L1D5C75leUyP DRCqNtj0uO2tOKomxsI077gidMEEJoG0REs8Kz8wTtRbYPHoQTwoeA5/dNM3TrTliYW8HYCmpRA5x j+vvhTYT7/fPswCrHSubtv4Um8uITR9ZyRZFLpN7dMCrcgNufpt75Vk6uhLfocLCHkhDjANsc+M+i T2ca4UrRnHnHXFn4L6+OGW8q9kAN+T7UpctO7p9NIcudKNZPiaMpegqNgfuW533BTHZfhqv/w17TL P8dvbiS5Y8df4kX7JX/uM9Au+s7MRw9ltkjHX2dpsvWJdbFpV7IjO9wnzKSNIKgqvlR9XzLT37/RO UkFLmwCUAq5llfbsqRbrSA==; Original-Received: from [87.69.77.57] (port=3430 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 1oI2G1-0000sh-Sw; Sun, 31 Jul 2022 02:16:58 -0400 In-Reply-To: <65cb7c73fdbf1de53ea7@heytings.org> (message from Gregory Heytings on Sat, 30 Jul 2022 19:11:57 +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:238316 Archived-At: > Date: Sat, 30 Jul 2022 19:11:57 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > > >> jit-lock--antiblink-post-command > > > > OK, but is it TRT to "punish" every one of these hooks for the "crimes" > > of the few? Maybe we should instead handle the problematic ones > > locally, by exposing the long_line_optimizations_p flag to Lisp (through > > an accessor), and then modifying those that misbehave to "behave"? > > It's the same problem than with fontification-functions. We cannot know > what all these hooks that are installed by major and minor modes will do, > we cannot hope to fix them one by one, so it seems to me that with > long_line_optimizations_p, which is an unusual case anyway, it makes sense > to "punish" them all in the same way. It sounds...too drastic. Lars, WDYT? I don't find it problematic to have to fix any such hooks in the core that we discover as misbehaving with long lines. How many of those could we have? And those in 3rd party packages can follow suit if they want (and if the respective modes are relevant to files with long lines, I expect to see pressure on their developers to do so). Once again, IME it is impossible to fix such problems only in low-level C infrastructure. There will always be left-overs and fallouts that should be fixed locally in Lisp where they happen. There's no problem here, and I don't expect us to be able to fix everything by a small number of quick fixes, and declare a victory once and for all. > Agreed. My point was only that Emacs now behaves a bit better when > editing a single-line very large file compared to a multi-line very large > file. Well, WDYT about a similar feature for very large files? IOW, when the buffer's size is above some threshold, turn on the long_line_optimizations_p flag (which should perhaps be renamed to better reflect its purpose) even if no long lines are seen?