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: Wed, 03 Aug 2022 18:42:03 -0400 Message-ID: References: <8c7321f2f388e5343475@heytings.org> <6ea376f6-d503-06d8-6d83-50c52b695394@yandex.ru> <8c7321f2f3ac52bfee4b@heytings.org> <8c7321f2f3ec1ef81af9@heytings.org> <02e83b0e-1b5c-fe75-6e59-1f8ddff82d37@yandex.ru> <96f28fd8-6744-1925-0631-0095099362dd@yandex.ru> <74ddc877f1e81f399eea@heytings.org> <74ddc877f14320d7852f@heytings.org> <5f6988c781f1253541e3@heytings.org> <5f6988c781a5686a88d1@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="40798"; 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 , Dmitry Gutov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 04 00:43: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 1oJN55-000AOl-18 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 00:43:11 +0200 Original-Received: from localhost ([::1]:47332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJN53-0005Wx-Pe for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Aug 2022 18:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJN4w-0005Wo-V8 for bug-gnu-emacs@gnu.org; Wed, 03 Aug 2022 18:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60520) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJN4w-0004cz-MW for bug-gnu-emacs@gnu.org; Wed, 03 Aug 2022 18:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJN4w-0008OP-Ck for bug-gnu-emacs@gnu.org; Wed, 03 Aug 2022 18:43: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: Wed, 03 Aug 2022 22:43: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.165956655132217 (code B ref 56682); Wed, 03 Aug 2022 22:43:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 3 Aug 2022 22:42:31 +0000 Original-Received: from localhost ([127.0.0.1]:50269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJN4P-0008NX-Jy for submit@debbugs.gnu.org; Wed, 03 Aug 2022 18:42:31 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJN49-0008N4-Pk for 56682@debbugs.gnu.org; Wed, 03 Aug 2022 18:42:28 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1FCC3100189; Wed, 3 Aug 2022 18:42:08 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 908A71000F3; Wed, 3 Aug 2022 18:42:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659566526; bh=joPV32P4TDfgUgzuuZ0m8YpUK+LpFVOVb3w4t649Wu0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hTnHW1TQJ6YaHS4ajwpfayDMdio/poIc74KPDXwqCl4Lfv1qlle/phGKGMbaX798z ri6I4eC3T0VRqi7ldWAD4rjzcx/xE9b0PAqqOrIzzC0KwhB6fCKXx4WBJ+5W+ogXfW +540o9dj2/nVtK/+0M7A/WJP2XmJkQjrnmUc/d7mBKePUQFvjwc6WuE0sLJv66EU5t iwagsJemc2husn/xs31aaKL2JUBDIYYeG7+5uLw+vk80+NNbtcdpbbPnWwVx5qbV1+ 5+GbWJxGaVnlj1bIsNwk90Tt9V5+d1+mGU+H/l+jX8pxnf2UJw/TI8nftbQT95GOl6 ++Iqd9jJLrlxg== Original-Received: from milanesa (unknown [46.44.221.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9D27E12020D; Wed, 3 Aug 2022 18:42:05 -0400 (EDT) In-Reply-To: <5f6988c781a5686a88d1@heytings.org> (Gregory Heytings's message of "Wed, 03 Aug 2022 21:37:39 +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:238656 Archived-At: >> - when they get a bug report with a locked narrowing because of long >> lines, using `widen-unlock` naively is likely to lead to an immediate >> performance problem, so it's unlikely they'll use it. > When I read this, I thought you had a point, but there's a fallacy in your > reasoning: using widen-unlock is in fact not likely to lead to an immediate > performance problem. The long-line-threshold limit is sufficiently high to > never be reached in "normal" files, but nothing would happen if you cross > that limit by a small amount, and nothing would even happen at twice or even > thrice that limit. That's a valid point. A bit like Alan's bug report, where he gets a regression for 10K-long lines where the performance would be tolerable. > If a mode author gets a bug report that is caused by locked narrowing, there > is something wrong in the way the mode fontifies the buffer. There is no > reason to require access the whole buffer to fontify a small chunk of that > buffer. IOW, using widen-unlock there is nearly always wrong (I add > "nearly" to leave open the possibility that there might be an exception). As I explained already, it's basically always wrong for a major mode's font-lock rules to widen, regardless if the narrowing is due to something like LLT or MMM-mode. > This is becoming so litigious (you're now telling me that you're offended) > that I start to believe that the right thing might in fact be to completely > disable font locking in such buffers. Would "no highlighting" be better > than "occasional mis-highlighting" from your point of view? I don't care about the mishighlighting and find the current behavior perfectly acceptable from an end-user point of view. I only care about the extra enforcement done in C code without providing any mechanism to circumvent it. Especially since this discussion seems to suggest that if I were to propose a patch that makes this locking a bit more "soft", it might be rejected on the grounds that it opens the door to abuse, so not only I strongly dislike this design but I can't even try and improve it. Stefan