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 05:25:09 -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> <74ddc877f128e46733c1@heytings.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="14474"; 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, Eli Zaretskii To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 02 11:26:20 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 1oIoAN-0003YZ-LP for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 11:26:19 +0200 Original-Received: from localhost ([::1]:37514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIoAM-0004Fi-HK for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 05:26:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55072) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIoA6-0004DP-UR for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 05:26:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52577) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIoA6-0002nt-L9 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 05:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIoA6-0005AM-HG for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 05:26: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 09:26: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.165943232219807 (code B ref 56682); Tue, 02 Aug 2022 09:26:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 09:25:22 +0000 Original-Received: from localhost ([127.0.0.1]:42326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIo9S-00059O-5w for submit@debbugs.gnu.org; Tue, 02 Aug 2022 05:25:22 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIo9P-000599-SU for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 05:25:21 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 79B118071D; Tue, 2 Aug 2022 05:25:14 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 15D258043C; Tue, 2 Aug 2022 05:25:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659432313; bh=ruPh+IY7msGRxSc4yA8cmLOtY7n7yd25gZq4rXaDO6Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OXyaRSXPNkTRunpGfZDuoab52aFaGPI/3iroYqwzyqfkMadzCLRLL7shZxFr2lVfp yeG9U8/auC2uXTgBQ+XgXMjuAaCxNpsVRXOUKHlseFrptzTmyln0t7/BOU6RZiu0Eh wem0/3VgUiG5RtFLPx2lE9qbSxuU6Gkmmynt+fsgwa8HOHij9y3EKIv60R9KDtNrC3 OVEGYT5kTJRsZvc7VBRXLkmx5Iwr8iJk2lqBVB8+m6L0P8+RBBKzIQgrjr2wdIAsbw 2uVkwjCgoLwpltuMkCxuZlkviQGTtIl5TkKHb/z/43N1AHq0rDN3YEsFtIDGQ7l8UR KnHlZ8I5MMTZg== 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 481CD12046D; Tue, 2 Aug 2022 05:25:12 -0400 (EDT) In-Reply-To: <74ddc877f128e46733c1@heytings.org> (Gregory Heytings's message of "Tue, 02 Aug 2022 08:22:45 +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:238498 Archived-At: >> `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 ... > Indeed. Which is why you'll see on the feature branch that in buffers with > long lines post-command-hook is now also subjected to a locked narrowing. But the problems can also affect buffers without long lines (just with many lines). Or the case of having a thousand buffers opened. Or ... >> 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`). > I don't understand what you have in mind here. If the major mode overrides the locked narrowing which causes the users experience to be unbearable in long buffers, the users could set this variable to override the override (while sending a bug report to the major mode's maintainers and waiting for the bug to be fixed). > It is not limited to redisplay only, but by far the largest fraction of the > speed impact is (or rather was) in redisplay, and asymptotically > so. Commands that used to take minutes on a reasonably recent computer now > take a fraction of a second, only because redisplay is now faster. Yes, your work is *really* appreciated in this area. I'm just pointing out that there's no point trying to make it technically *impossible* for users to shoot themselves in the foot making redisplay too slow, because there are still plenty of other ways they can shoot themselves in the foot, and because every time we make something undesirable impossible, we *also* make it impossible to do some desirable things (even if we can't yet imagine what those might be). Stefan