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 17:40:51 -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> <74ddc877f12af40a651c@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="19104"; 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 23:42: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 1oIzeV-0004m0-Qi for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 23:42:12 +0200 Original-Received: from localhost ([::1]:57046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIzeU-0000gi-27 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 17:42:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIzeM-0000gV-Vr for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 17:42:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55491) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIzeM-0005tv-N2 for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 17:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIzeM-00030V-Gf for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 17:42: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 21:42: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.165947647111489 (code B ref 56682); Tue, 02 Aug 2022 21:42:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 21:41:11 +0000 Original-Received: from localhost ([127.0.0.1]:45240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIzdX-0002zF-Fa for submit@debbugs.gnu.org; Tue, 02 Aug 2022 17:41:11 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIzdS-0002yY-2x for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 17:41:09 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 53A37804FC; Tue, 2 Aug 2022 17:40:59 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AA5F780012; Tue, 2 Aug 2022 17:40:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659476457; bh=FZmSCgjUeADJsEFXIlgO04d4Ke+W19+t++hojgTklGo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=h4Y4ulpNsLmmQMByP1UIiGGA8cM6/3OTu3jzNb+W6agEZKojZrfbLTj4HguumXjWc p4XGVHAOZDfO+zFB9ORGa35I2SjzengbqMpb3tP5mzwV1g83vCVHd7Bs9wo94LdIYZ n8NCB7UdOXxhITXcCoOg9FP61iYC4xnnO7sWH1tRbTV/GoKH26ooENf+cLIptJB/OK /joGDHnYElBw2pCAmRiN7+vi88HPmR8L8Ii1Gj/EZYOGOgJvWg7L5sVUSoDGmydSJx XXAYO8wVYTLb7Yb2lwu8i7YxIaqpZD/C2Z6ztPjPxL5SkKQcwt2beUHuFLYwFOzuV6 BjtytexkX/kGw== Original-Received: from milanesa (unknown [46.44.221.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BA5B812030C; Tue, 2 Aug 2022 17:40:56 -0400 (EDT) In-Reply-To: <74ddc877f12af40a651c@heytings.org> (Gregory Heytings's message of "Tue, 02 Aug 2022 10:00:58 +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:238588 Archived-At: > 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. "Reasonable measures" is good. But once you step into "impossible to circumvent", you start going directly against the goals of Free Software (and Emacs) to empower the user. >> 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? We've had enough bug reports over the years (and I experienced such things many times as well), yes. Usually linked to bugs in some package, of course, but in many case it wasn't a clear-cut bug, just some bad interaction of various elements. > I'm curious again, because I cannot imagine what that could be either. I suffer from the same lack of imagination, as I sure many others here do. To make up for that, we've learned to follow a philosophy of empowering the users (and not imposing arbitrary limits just because we couldn't think of good reasons to go beyond them). > 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. :-) Stefan