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: Tue, 02 Aug 2022 08:22:45 +0000 Message-ID: <74ddc877f128e46733c1@heytings.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6996"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 02 10:52:01 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 1oIndA-0001Vn-Bc for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 10:52:00 +0200 Original-Received: from localhost ([::1]:37438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oInd9-0006hk-E5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 04:51:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oInB9-0007kl-NU for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 04:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52494) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oInB8-0002zP-J6 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 04:23:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oInB8-0003Y5-Et for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 04:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Aug 2022 08:23: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.165942857113613 (code B ref 56682); Tue, 02 Aug 2022 08:23:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 08:22:51 +0000 Original-Received: from localhost ([127.0.0.1]:42243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oInAx-0003XV-34 for submit@debbugs.gnu.org; Tue, 02 Aug 2022 04:22:51 -0400 Original-Received: from heytings.org ([95.142.160.155]:35104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oInAt-0003XL-MG for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 04:22:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659428566; bh=wFifj7R919p7VJyRA+y+c/qyWMeGSlCz2mF3/lJ0J9g=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=7eKMduHBvMbydwoh3NtKISBESeLdKqCq7VVT7KxXZ4JjIa5K9uq4q4auh3UXRT8uP 79CAbXNlwT/AwIHlJHf5T7fA46QJgX3LEOltVQYoTsefPvl4Rf4J5bfRYMwMBMxO0G CRGhBUPyfOsdVwHYQflyH2y2RGRlEY6DQBLaSamFkQpt5SOq6g9Soeb9r5HlbzBmhW 00utcpJfVHGpWezzpXxFCEvwOtAU+U7qoG70/OHGvqjzE9A36LVQ7G8thjqSyPEZLM o4BpaNkxhhOUk88m+43Z/d6EeyYL8OgjIb9Zi24YKfaJumywfkRq3PNKnd8EUy1pZM i1JG0Y8LG7QIA== In-Reply-To: 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:238496 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. > > 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. How would such a user option be different from (setq long-line-threshold nil)? Do you mean that we should make it possible for users to fine-tune each and every aspect of the optimizations, with a bunch of user configurable options? > > 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. > 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.