From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sat, 6 Aug 2022 01:38:05 +0300 Message-ID: References: <8c7321f2f388e5343475@heytings.org> <8c7321f2f36494299e61@heytings.org> <8c7321f2f336523624e3@heytings.org> <83r1202meh.fsf@gnu.org> <6020ffaf-9069-0070-76cf-a13379ef01b5@yandex.ru> <83les71ilg.fsf@gnu.org> <06c5560d-3009-e5a5-3d33-fe5d2ec32d6b@yandex.ru> <74ddc877f17a06d8f120@heytings.org> <100d08b3-c25b-683f-6def-39052107ab59@yandex.ru> <83h72r16g1.fsf@gnu.org> <640c2e07-98e1-96d6-bb02-19f5f03f637f@yandex.ru> <834jyq29o1.fsf@gnu.org> <92da07bd028e3ede61a6@heytings.org> <47894c57-dd8b-5778-240a-3fa6540e4d37@yandex.ru> <92da07bd02941d5537e9@heytings.org> <5308e3b5-a160-17d7-77ee-b1d00acfa20d@yandex.ru> <92da07bd02a6cc861e1a@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27911"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: 56682@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 06 00:39:30 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 1oK5yb-00071z-B7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Aug 2022 00:39:29 +0200 Original-Received: from localhost ([::1]:59760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oK5yZ-0001ZX-UK for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Aug 2022 18:39:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oK5yB-0001ZB-6L for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 18:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42703) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oK5yA-0001Uz-Oi for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 18:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oK5yA-0004Ns-Fu for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 18:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Aug 2022 22:39: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.165973909516797 (code B ref 56682); Fri, 05 Aug 2022 22:39:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 5 Aug 2022 22:38:15 +0000 Original-Received: from localhost ([127.0.0.1]:60685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oK5xP-0004Mr-5w for submit@debbugs.gnu.org; Fri, 05 Aug 2022 18:38:15 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:41857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oK5xN-0004Md-8r for 56682@debbugs.gnu.org; Fri, 05 Aug 2022 18:38:14 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id m16-20020a05600c3b1000b003a529a99858so132588wms.0 for <56682@debbugs.gnu.org>; Fri, 05 Aug 2022 15:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=9lp8mL3yDuqSX+/TDpJ+V9tPC7b0qycdQD5Nk+zHOMQ=; b=Bl/hljQwU0VEHOfrIV4Dv9a5iUkLGVOg0LfieTUj809fhqxOa4jCGpwKsCykNtltv+ OeLBFzA0kguakulBFqbBZq0Pb6QL94aNvy0IUp6W2IeCJaziTkHjJTxJOSsK9FX8riD6 g34VXFPMcFaLh4Ac6MTni7ywFnAGIXhbyTRpcYuBu1yjWlHj72HHlWJ7J/YcUWAFBV6C yw5lJ+KuC/Fn0ogHhkXH/trjgZSTCIkrtOZGn3q6z8xtx54AwYpK8gU3beF1qceZHeOG e/kXKh6ZTrm5zyfVL0/f5nws1PsbqHZKUmCjBjbh8S1fOita9G5WJ/j8846YivZjZYS4 VGXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=9lp8mL3yDuqSX+/TDpJ+V9tPC7b0qycdQD5Nk+zHOMQ=; b=oywQnyE8DAjUVUGyUm06Hvsf1iAXi/c+rTVwS7l9MaNyP+4OPp8Zv8YF1SfKzdC7U4 4saulyR/I5Ll6k8GA9GJP8F3WpISFuP4VYzWtVhlIk5th957El3+gE13sY05clmF5w7E S/tQtg47oYxlAfsclO+zl9X6bdNow8Z1k8NwgIy9ZxQgn6iuFnT6qrtRZHU5YZFRNRSl 2J8UONTHX9m34uKxFLDMSOpU8ebLW9Xy52oC/mrKocm6ctvVkMnkM6DEojPoWKzshz6Q dGsCL5PX/ilD52FpRM5ZnIPqwTZxN2RwXT7wZhVK7mFO3OYwc/6TWl6ro1Xa8M/YTYpB 0UhA== X-Gm-Message-State: ACgBeo2sppl8w1jHXicmpFzYpP6lRGwX+wJqdOTRoWIQWE0tDFzAKG7T AZgUERVQIkTwLHJbfIYo5po= X-Google-Smtp-Source: AA6agR6iyAayfF523mijI+aRFwPjzdscOPXf7QNIyVK9f9ZMZ5hj5W7OtUya+3G6e9tKQtbCZEcG5Q== X-Received: by 2002:a05:600c:1d94:b0:3a4:ffd9:bb4a with SMTP id p20-20020a05600c1d9400b003a4ffd9bb4amr5742565wms.8.1659739087133; Fri, 05 Aug 2022 15:38:07 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id a18-20020a05600c069200b003a2cf1ba9e2sm5371168wmn.6.2022.08.05.15.38.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Aug 2022 15:38:06 -0700 (PDT) Content-Language: en-US In-Reply-To: <92da07bd02a6cc861e1a@heytings.org> 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:238945 Archived-At: On 05.08.2022 17:09, Gregory Heytings wrote: > >>> But if you're so annoyed by mis-fontification, why don't you just >>> turn font-lock mode off? >> >> "If you're annoyed by Emacs's performance with large files, why don't >> you just never open them?" >> > > That's just wrong: in one case we're talking about your personal > feelings/preferences, in the other one about Emacs' capabilities for all > its users. Being able to edit a medium-size file with correct syntax highlighting without redisplay-related stuttering is also a capability. >> I like font-lock and the visual cues that come with it. Only >> font-locking the first 1 MB of a large file seems like a good >> compromise: show correct highlighting where we can with reasonable >> performance, and omit it in the rest of the file. >> > > So what you prefer IIUC would be to call fontification-functions with a > locked narrowing to 1 MB if point is before that threshold, and to not > call fontification-functions at all after that threshold?  That might be > another doable approach. If we have to support huge files with max responsiveness, then that would be my preference, yes. I don't see the point of using a "locked" narrowing for this, though. Maybe not even a narrowing at all: just avoid calling fontification-functions with START > value_of(large_file_fontification_max). Or even implement that limitation in font-lock itself (in Lisp). Not sure which place is better. Depends on how we want 'font-lock-fontify-region' to behave: would it still fontify a region when asked, or would it abort when BEG is too high. I'd prefer the former approach since it gives more power to programmers, if we don't find any significant pitfalls with it. >>> Also, why did you not protest vehemently when Stefan added >>> syntax-wholeline-max, which also causes occasional mis-fontification? >> >> I have replied to this exact question in an earlier email. We can >> continue this line of inquiry in that subthread. >> > > Sorry, I missed that part of your earlier post: > >> >> syntax-wholelines-max indeed can potentially cause problems too, but >> in a much narrow range of situations (and only with major modes which >> have non-trivial syntax-propertize-function). >> > > You forget to metion that syntax-wholelines-max can in fact make things > much worse, see the recipes I sent you a few days ago.  So it doesn't > seem like it's the right approach. These recipes, I guess: > emacs -Q > M-: (setq long-line-threshold nil syntax-wholeline-max most-positive- > fixnum) RET > C-x C-f dictionary.json RET y ;; takes 160 seconds > C-e ;; takes 200 seconds > > emacs -Q > M-: (setq long-line-threshold nil) RET > C-x C-f dictionary.json RET y ;; immediate > C-e ;; not finished after 1200 seconds (20 minutes), I killed Emacs I get what you're saying, but the approach does seem "right" to me because it works, letting me view and edit dictionary.json with good performance and behavior. And because it fits the overall font-lock/syntax-propertize/syntax-ppss scheme. I'm not considering it without the improvements that are enabled with non-nil long-line-threshold, though. As you show it above, Emacs is simply not usable with those numbers. 200 seconds might as well be "never finished". It took like 10-20 seconds on my machine (and with the latest patch I sent to this thread), but that's still a lot. Hadn't managed to see the second scenario finish either. Why the default value of syntax-wholeline-max makes things worse in this scenario, is a good question, but is it a useful one? Perhaps if you could show a similar comparison with a non-nil value of long-line-threshold (so that Emacs actually works rather than grind to a halt), we could debug it and produce the answer. Or, if the scenario requires long-line-threshold to be nil, I guess the example file needs to be smaller so that the second scenario can finish in a bearable amount of time, and Emacs is still usable. Either way, I believe the change is at the right level of abstraction, and if it has bugs, they should be solvable without major redesign.