From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing. Date: Wed, 01 Feb 2023 20:55:09 +0200 Message-ID: <83bkmdz04y.fsf@gnu.org> References: <166939872890.18950.12581667269687468681@vcs2.savannah.gnu.org> <20221125175209.51166C004B6@vcs2.savannah.gnu.org> <6c9d91cffc1bfd801530@heytings.org> <6c9d91cffc394613f58a@heytings.org> <83eds0ksev.fsf@gnu.org> <8aadf0ddd54c85c8144a@heytings.org> <831qnhg3d9.fsf@gnu.org> <9757fbea37611e9c44b9@heytings.org> <83cz6yacxt.fsf@gnu.org> <6943e04e30e5a02a52e6@heytings.org> <838rhk5fy1.fsf@gnu.org> <6943e04e30a40824e107@heytings.org> <83k0143q37.fsf@gnu.org> <94821a0ef100102ac9e0@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 01 19:56:10 2023 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 1pNIHB-0006n9-TY for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Feb 2023 19:56:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNIH6-0004rc-A3; Wed, 01 Feb 2023 13:56:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNIH4-0004kH-Ek for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2023 13:56:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pNIH4-0003iM-69 for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2023 13:56:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pNIH3-0007QR-Oi for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2023 13:56:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Feb 2023 18:56:01 +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.167527772928494 (code B ref 56682); Wed, 01 Feb 2023 18:56:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 1 Feb 2023 18:55:29 +0000 Original-Received: from localhost ([127.0.0.1]:59871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNIGX-0007PW-0e for submit@debbugs.gnu.org; Wed, 01 Feb 2023 13:55:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNIGT-0007PA-4Y for 56682@debbugs.gnu.org; Wed, 01 Feb 2023 13:55:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNIGN-0003Y1-1G; Wed, 01 Feb 2023 13:55:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6V1O4UaMxh23p+mwVV6u+HA64EuUpWu00lXcQEB8t3I=; b=PHJFpfGbPUsM AFTt4S7udj/ehYLC41NaS4xDh5+tHPDGoWIDesUeZYF7OyrmhwV+jFH1kIElflCEYtRGj1fPoswf9 e1VFqnKs3klRcGSQRnU6q11nZE7C3k6gtlpRzl+46AHJhZOBonMEmBO/O04r073TC2UrKNUpJcIR8 ZMZxWW7TSPxbwsY52GuyoCbBf5AibUA4tL3H7HMF+5pTgu3Vljx7KemTxn39eqq7A9kMWhqpGr8co weVk04t1X034tlhE42nntpDLrGE/RY0UDFDCJva7kgpfY+ykmu0U6NZAW3nEUH6cxAcfg4pRd6ybg rQ3tp/L8szYRbeUWSJAXeg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNIGE-0008PE-17; Wed, 01 Feb 2023 13:55:15 -0500 In-Reply-To: <94821a0ef100102ac9e0@heytings.org> (message from Gregory Heytings on Tue, 31 Jan 2023 15:14:14 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254601 Archived-At: > Date: Tue, 31 Jan 2023 15:14:14 +0000 > From: Gregory Heytings > cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca > > > So we are removing all the stuff that prevented font-lock from slowing > > down redisplay when long lines are in the buffer? IOW, something which > > we have for several months, and which so far brought up only one > > complaint? Frankly, this makes no sense to me, unless we delay the > > pretest for another half year or so. It's too late for such changes. > > > > Or am I missing something? > > I looked with a critical eye at the code I wrote, and concluded that the > cure is worse than the disease. > > It's true that some slowdowns caused by font-locking are prevented by > locked narrowing, but: > > 1. The slowdowns caused by font-locking were not the major cause of > slowdowns in buffers with long lines. They were the "last step" to make > editing operations in such buffers as fast as possible, and my opinion now > is that that last step was a step too far. Efficiency issues in font > locking routines are the responsibility of mode authors. Efficiency > issues in the redisplay routines are the responsibility of Emacs, and have > been dealt with. > > 2. Locked narrowing does not prevent all slowdowns caused by font-locking. > > 3. Locked narrowing can create slowdowns (e.g. infinite loops) that do not > exist when it is not present. > > 4. Mode authors who do care about efficiency will update their modes to > deal with problematic buffers, and do not need to be incited by locked > narrowing to do so. > > 5. Mode authors who do not care about such problematic buffers will simply > replace calls to "(widen)" by "(narrowing-unlock 'fontification-functions) > (widen)" in their code, and the situation will not have improved. I must admit that it's very strange to hear this from you. Those very opinions were voiced by several other people over the last year, and you always disagreed with these very arguments in the strongest terms, citing various use cases and data points, with several relevant files and modes. I wonder what have happened that you now see in the code what you didn't see then, even when others told you they saw it. Anyway, after thinking about this, I cannot agree to removing what we now have on emacs-29. It's too late for that, and I'm not prepared to delay the pretest for any significant time. So we will go into the pretest with what we have, and decide what to do with it in Emacs 29.2 and 30.1 according to how the chips will fall. I guess by suggesting to remove the code you were also telling me that you won't be fixing those documentation issues, which you promised to work on a month ago? If so, I guess this is one more buck that stops with me...