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 12:04:21 +0300 Message-ID: <83k07t4pre.fsf@gnu.org> References: <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> <83tu6x4xis.fsf@gnu.org> <8c7321f2f3859b5ee60b@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13639"; 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 11:06:06 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 1oI4th-0003PI-AF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 11:06:05 +0200 Original-Received: from localhost ([::1]:53178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oI4tg-00032B-1i for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 05:06:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI4sj-00031y-Cm for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 05:05:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46637) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oI4sg-0003ej-0W for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 05:05:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oI4sf-0007Fg-NO for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 05:05: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: Sun, 31 Jul 2022 09:05:01 +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.165925828727853 (code B ref 56682); Sun, 31 Jul 2022 09:05:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 31 Jul 2022 09:04:47 +0000 Original-Received: from localhost ([127.0.0.1]:36386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI4sQ-0007FB-W9 for submit@debbugs.gnu.org; Sun, 31 Jul 2022 05:04:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI4sL-0007Eu-HA for 56682@debbugs.gnu.org; Sun, 31 Jul 2022 05:04:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52646) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI4sF-0003dj-Vi; Sun, 31 Jul 2022 05:04:36 -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=c1jBoAIwdCadDew3D2+a+ePsjbPHyfifj9ki0Jtn5LQ=; b=Dc1q8NolDIvt kYttv8y9KP6jN88+NxVQJGm8OiGza+LJF6wKKdrNen/vocHP6i6iEz3gwd6U+98tY1WG74SCEbCo8 g4C2dfs0RblsWO4IwEXG1M1q8Ygy4YbZANiWolfHxPOkaGe/1j1GWWZIFOrKFxhwYDga9q5Wm83wx 553sGYnrczWXLsHmL/rDEBA/nmk4wNNYAAA8e7BR3YPc5BJfSe43fibZxfoNgyhDNVAddIwkHt9Jo J5v0rsL0F2dFGnxhCL2/cpmVi2iQksQHDE0F+jb/jE8Ipm3KPhzow5xSYEvA0XLDOciPwAAnAvA9J BaAVKiG0aLOXsqskCu+guw==; Original-Received: from [87.69.77.57] (port=1974 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 1oI4sF-00063f-FM; Sun, 31 Jul 2022 05:04:35 -0400 In-Reply-To: <8c7321f2f3859b5ee60b@heytings.org> (message from Gregory Heytings on Sun, 31 Jul 2022 08:30:14 +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:238330 Archived-At: > Date: Sun, 31 Jul 2022 08:30:14 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > > > It sounds...too drastic. > > Are you sure? The docstring already says "It is a bad idea to use this > hook for expensive processing." And Emacs already removes a function from > the hook when it misbhaves. Adding something like "In a too large buffer > or in a buffer with long lines, the functions in this hook will only have > access to a small portion of the buffer" seems coherent, at least to me. But that assumes these hooks will _always_ be "too expensive" in such buffers. Which is not necessarily true: I can think of many things a hook can do in a long-line buffer without being expensive. And since we already remove expensive hook functions, maybe that is enough? Or maybe we should use a different threshold for "expensive" in buffers with long lines? > > 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. > > I both agree and disagree with that. It is true that it is, strictly > speaking, impossible to fix _all_ such problems _only_ in low-level C > intrastructure, and that there will always be left-overs. But it is > possible to fix _most_ of these problems only in low-level C > infrastructure, and we should do so, just like an operating system kernel > in which everything is done to avoid crashing the system/leaving it in an > unusable state (which includes killing a mis-behaving process when > necessary). And we should do so even more when the amount of code to do > so in the low-level C infrastructure remains small. I think we are in agreement: my point was that solving such problems locally is not unthinkable. > > 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? > > > > I was thinking about such a feature indeed. But it would be separate from > the long_line_optimizations_p one, because the optimizations to activate > in both cases are different, and their thresholds are different, too. Different thresholds are easy to reconcile: the optimizations should be turned on if either of the two thresholds is exceeded. But why do you say the optimizations will be different? what's wrong with using the same optimizations, i.e. restrict the display code from accessing the entire buffer?