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 10:00:58 +0000 Message-ID: <74ddc877f12af40a651c@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> <74ddc877f128e46733c1@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27486"; 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 12:43:08 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 1oIpMh-0006zc-QJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 12:43:07 +0200 Original-Received: from localhost ([::1]:57284 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIpMg-0008Gf-Sg for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 06:43:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIoiw-0006Op-S9 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 06:02:14 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52625) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIoiw-0007HL-JR for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 06:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIoiw-0008HI-EW for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 06:02: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 10:02: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.165943446231739 (code B ref 56682); Tue, 02 Aug 2022 10:02:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 10:01:02 +0000 Original-Received: from localhost ([127.0.0.1]:42373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIohx-0008Ff-Ve for submit@debbugs.gnu.org; Tue, 02 Aug 2022 06:01:02 -0400 Original-Received: from heytings.org ([95.142.160.155]:35236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIohw-0008FJ-Mh for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 06:01:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659434459; bh=K5hnW/2FNQ+hcX7bwkOn5qn3jw8Gp7yo78dHeTtQwEQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=7IrSIe/ueH44+8AuOnwIbuDibIPjS3/t+vmISH0ZITsNUSF/dYBq9NQZZVqqF69AC TLMldYmsFEK0utr0va6sGV5bi8YZ8P91PU0RCclwRG3QzjRYrM1yZDDEuwXRkpItVb E72jwMapOgmiTnasx2BJkOZwVDnEm/hhDSQdkfW7hiAseDMk2J63N2md54WrZRL7Sz gPvhxrFnaQEqh5xhQKuLz5Hw6sSMLCd0sY7DECizutKSlBzf2jnW+xx9EuHjpXTfmR qdqBhRVwKi2T6vySmVxGRY75uYjtAGetiM5wiIZqGPMuNtSJoki7bYPZws1nZxpybV 1A9yJNz1mNVGA== 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:238511 Archived-At: > > But the problems can also affect buffers without long lines (just with > many lines). > Yes, and that's what sits next on my list: "too large" buffers. > > Or the case of having a thousand buffers opened. Or ... > I don't think the "too many buffers" case is worth investigating. Because it won't lock Emacs suddenly, like what we had. It could make Emacs gradually slower, in which case the user can take some appropriate measures. > > 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). > I see what you mean now. But I don't think it would work. What I want is to take reasonable measures to ensure that Emacs remains responsive "in spite of" mode maintainers. > > 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, > Yes, with that I agree. But as Eli said, it's not users who shoot themselves in the foot, it's innocent users that are shooted in the foot by syntax-ppss and/or by mode maintainers who are not careful enough. And as I said its not technically impossible for this to happen, users can freely unset long-line-threshold (although that's not recommended of course). > > because there are still plenty of other ways they can shoot themselves > in the foot, > I'm curious, are there other ways for a regular user (*not* an Elisp hacker!) to make Emacs completely unresponsive with regular editing commands, starting with emacs -Q? > > 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). > I'm curious again, because I cannot imagine what that could be either. Also note that you can blame yourself if you don't like the locked narrowing idea. See the following three lines which you added ten years ago in eval.c: /* Don't export this variable to Elisp, so no one can mess with it (Just imagine if someone makes it buffer-local). */ Funintern (Qinternal_interpreter_environment, Qnil); and which make it technically impossible to do something, incidentally without providing a way for Elisp hackers to escape that impossibility.