From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Tue, 02 Aug 2022 04:10:12 -0400 Message-ID: References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.org> <83v8rf5894.fsf@gnu.org> <65cb7c73fd4a999cca00@heytings.org> <8c7321f2f3400a5db9be@heytings.org> <8c7321f2f388e5343475@heytings.org> <8c7321f2f36494299e61@heytings.org> <83v8rc2n1h.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20624"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56682@debbugs.gnu.org, gregory@heytings.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 02 11:27:48 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 1oIoBo-0005DZ-10 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 11:27:48 +0200 Original-Received: from localhost ([::1]:40128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIoBn-00064I-49 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 05:27:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oImzX-0004xJ-HZ for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 04:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52463) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oImzW-0007Ox-Ks for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 04:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oImzW-0003FD-Gc for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 04:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Aug 2022 08:11: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.165942782712428 (code B ref 56682); Tue, 02 Aug 2022 08:11:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 08:10:27 +0000 Original-Received: from localhost ([127.0.0.1]:42212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oImyx-0003EO-18 for submit@debbugs.gnu.org; Tue, 02 Aug 2022 04:10:27 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oImyu-0003E2-GZ for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 04:10:25 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 47B4E8071D; Tue, 2 Aug 2022 04:10:18 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AC52E80011; Tue, 2 Aug 2022 04:10:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659427816; bh=UI6y3Lr/Lwgu4DzIhvL5qDwYMmQl8o3ni+Hd4o2OcgM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cWEqoFpdva3Iid/RbYicMlA40MI7HW1eUJXfnTKRqlq/7FsUEklIYceb/zpOpx5x3 yXefgUjJtMuyxMOBerwDCl5nobUnDG1P1hD5pv/z5vNC3Xm24mQLHJD84sUxhKAnAQ y5EG3XKCTv98rYmQd3LpJHmBu+Naufj0w10xxl5hEYl7uPguCfI+I1Fh2lbz/OrCCq 7N+XjZ0YO5mtVfCmbzWIrfdZNccIlg2XA16E2mWgucT5574dU4PwSvVSXFtalREbls ZGcRXjvXmUSQIDTD0hOT++IHuwWbVk4NAzG/yZTWV5NKqbiTtDNh862o1rGdkxa0Oc Tb/wrwBXyQf8w== Original-Received: from milanesa (dyn.144-85-176-027.dsl.vtx.ch [144.85.176.27]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DDDA212016F; Tue, 2 Aug 2022 04:10:15 -0400 (EDT) In-Reply-To: <83v8rc2n1h.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 01 Aug 2022 14:58:18 +0300") 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:238499 Archived-At: > Given this situation, it sounds reasonable to start by restricting > font-lock. I fully agree. The current behavior is the right default. > As I wrote elsewhere, I'm okay with extending 'widen' so that it could > "unlock" the locked narrowing, which could then be used in major modes > that convince us their performance is adequate (or clearly announce in > their docs that they don't care about files with long lines ;-). `post-command-hook` also has been abused in all kinds of ways that suck for the user if they have too-large buffers, or too many buffers, or too many frames, or ... That has never prompted calls to ban it completely. So, I think it's important to provide this option to "unlock the widening". Even for purely philosophical reasons. We can even add a user-option to "re-lock" the widening which would prevent the "unlock the widening" from working, so that users can override a poorly-thought-out use of widening which makes their large file unusable (tho I'd argue that you can get the same result with an `advice-add`). Also, let's not forget that the speed impact of large buffers is not limited to the redisplay, so trying to work extra-hard to eliminate all possible cases of the redisplay spending too much time in large buffers won't prevent "apparent lockups" where the time is spent in the command (or some hook run at that occasion) rather than in the redisplay itself. Stefan