From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sat, 30 Jul 2022 19:11:57 +0000 Message-ID: <65cb7c73fdbf1de53ea7@heytings.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="eTPdbAL2tu" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8065"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 21:13:12 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 1oHrtf-0001wW-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 21:13:11 +0200 Original-Received: from localhost ([::1]:60964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHrte-00084d-3V for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 15:13:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHrtW-00084D-1r for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 15:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHrtV-0001LG-PT for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 15:13:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHrtV-0001Eh-KG for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 15:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jul 2022 19:13: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.16592083244673 (code B ref 56682); Sat, 30 Jul 2022 19:13:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 19:12:04 +0000 Original-Received: from localhost ([127.0.0.1]:35775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHrsa-0001DJ-0V for submit@debbugs.gnu.org; Sat, 30 Jul 2022 15:12:04 -0400 Original-Received: from heytings.org ([95.142.160.155]:59592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHrsV-0001Cq-20 for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 15:12:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659208318; bh=VgtipaP2k5Mm9clRhyJiPf4OA10DpPu53z8umsFrQlY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=hnxbzxMPwIaapkLd8/O60c3gL6G0Wgr1sVXs4pk2ra7tiZXvuppOi1lD/okm1mSlV HjziRLAu3MtRFTilmGm/s8l+2JZUvGcmuFe3HMXVMLxHuacoB86E2ePr1uyhMudwjr 5YywZP5USkssHLjtUfiI1nQPRyhthJ5nK9uf/DuETPAGRyK18SHxzalRNbRF7UhkNh yVJCgAMMI41vOhK831R/hbEURm9Nn17j9xf+hz1p3y5iRB8KXLlPt6FrjLx3Qo+UmK FqY+lMIZXoHlMP8Auv+tJUuRlub8BOMvYkPFpp/6pKx7lHreugk+NmEYTaaM3Fx/8O /ckm7sbzMoCvw== In-Reply-To: <83y1wa4e6q.fsf@gnu.org> 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:238310 Archived-At: --eTPdbAL2tu Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >>>> Wouldn't it make sense to also limit the portion of the buffer to=20 >>>> which pre-/post-command-hook have access (see below)? >>> >>> Those generally don't belong to the display department, so I'd=20 >>> hesitate doing so. Which pre-/post-command-hook functions did you=20 >>> find that cause slowdown because of long lines. >> >> jit-lock--antiblink-post-command > > OK, but is it TRT to "punish" every one of these hooks for the "crimes"= =20 > of the few? Maybe we should instead handle the problematic ones=20 > locally, by exposing the long_line_optimizations_p flag to Lisp (through= =20 > an accessor), and then modifying those that misbehave to "behave"? > It's the same problem than with fontification-functions. We cannot know=20 what all these hooks that are installed by major and minor modes will do,= =20 we cannot hope to fix them one by one, so it seems to me that with=20 long_line_optimizations_p, which is an unusual case anyway, it makes sense= =20 to "punish" them all in the same way. >> That's theory, isn't it? With 64-bit builds we are limited to files=20 >> that are less than 2047 Po. No computer on this planet has that much=20 >> RAM. > > You forget that we are talking about VM. > > But let's not restart that argument, okay? > Hmmm... okay =F0=9F=98=89 > > If JS mode wants to access the entire buffer for fontifications, then=20 > IMO the problem is in JS mode, and should be fixed there.=20 > narrow-to-region is available to Lisp programs as well ;-) > > IOW, it isn't an infrastructure problem that needs to be fixed in=20 > display code. (It is even possible that tree-sitter integration will=20 > fix this, or at least alleviate it, as a side effect.) > Agreed. My point was only that Emacs now behaves a bit better when=20 editing a single-line very large file compared to a multi-line very large= =20 file. --eTPdbAL2tu--