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: locked narrowing Date: Tue, 29 Nov 2022 17:10:27 +0000 Message-ID: References: <831qtgff78.fsf@gnu.org> <83zgg4dw4y.fsf@gnu.org> <83r11gdrr4.fsf@gnu.org> <83edxfds7s.fsf@gnu.org> <83r11fc80o.fsf@gnu.org> <83o7wjc6o2.fsf@gnu.org> <83lernc5gu.fsf@gnu.org> <83k076dd7d.fsf@gnu.org> <83czcyd8jf.fsf@gnu.org> <83a682d66r.fsf@gnu.org> <837d36ceno.fsf@gnu.org> <37dd2827f54f8bbda5e3@heytings.org> <735c1d5b-0d64-a8e1-3aaa-91fc0248abd3@yandex.ru> 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="9823"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 29 18:11:18 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 1p048a-0002Jx-TG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Nov 2022 18:11:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p048P-0008Fx-E6; Tue, 29 Nov 2022 12:11:05 -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 1p048O-0008Fo-7S for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 12:11:04 -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 1p048N-0002h7-4f for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 12:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p048M-0004i1-GS for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 12:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2022 17:11: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.166974183618094 (code B ref 56682); Tue, 29 Nov 2022 17:11:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 29 Nov 2022 17:10:36 +0000 Original-Received: from localhost ([127.0.0.1]:55236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p047v-0004hm-VB for submit@debbugs.gnu.org; Tue, 29 Nov 2022 12:10:36 -0500 Original-Received: from heytings.org ([95.142.160.155]:36436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p047q-0004hg-DE for 56682@debbugs.gnu.org; Tue, 29 Nov 2022 12:10:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1669741827; bh=7BLAzv7v24bhouMuINcfS5Tf3PiHmhXGG6uzgz2sDRk=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=zxzb2A4XlgRt736DinQzZhuV9/wAR4yx02C8w9GOSwFkK+TkFcuGNcAc06xzqN15A YPPfiB8IrWzvV/4S06r8B8Qcb/xx66Sjcfp83wvlSTR5hOEp77jhXjmfFxgU+FEvXF 939sbuWBUosxldy3KvUTqiiL7Wog9z5O8/87dW93gvemvtM2FZlY/0y5n3oavrVrg7 RptGISJ/eUOb3Er9WTcvGcpXy5AlekqiX6WjpiIj0hZlssL7N+761GE8zMAVSkMQDY bND13U1XXsj02BaOtiTEUmIR79YqQ/q5Hyl2Tit7JXQqw/P5VYYCAn8jjyyYBli4HD 8/oopgPLg8NxQ== 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249418 Archived-At: > > But I tried to see the effects of this new variable > (long-line-locked-narrowing-region-size), and it was a little puzzling. > > With the default value (500000) I open dictionary.json and start hitting > PgDn a lot. Syntax highlighting starts to look broken at the buffer > position that's around half that: at my last attempt it was at point > 259999. > > Looking at the code, there is indeed some halving going on, so maybe it > would be more easier to understand if the variable was called > locked-narrowing-radius, and used as such -- without division. > I considered naming it with "radius", but decided not to do it. This is an implementation detail. And the docstring says "region around point", from which an attentive reader can infer that half of the region will be before and half of it will be after point. It does not seem worth the price to introduce separate cases for point at or near BOB and point at or near EOB. > > Another thing that bothered me when testing: going from eob to bob in > dictionary.json took ~4 seconds every time, independent of buffer being > edited or not. And that delay didn't show up anywhere in the profiler. > (setq bidi-inhibit-bpa nil) didn't help at all, but (setq > bidi-display-reordering nil) eliminated that delay. > Your analysis is not correct: the delay you see is due to show-paren-mode. Turn it off, and you'll see that going from EOB to BOB is instantaneous. > > And we'll probably come back to this question sometime later, but here's > something that looks like a regression. Editing dictionary.json is > snappier than dictionary-pp.json (same file but pretty-printed so > without long lines). > Unless I misunderstand what you mean, this cannot be a regression: editing dictionary.json was not possible with Emacs 28, editing dictionary-pp.json was. Even if the former were now snappier than the latter, that would not be a problem in itself. > > Even with with common setup (and emacs -Q): > > 1. (setq long-line-locked-narrowing-region-size 50000) > 2. (setq bidi-display-reordering nil) > 3. Toggle show-paren-mode off, just in case. > 4. electric-pair-mode off, same. > > typing in the latter file exhibits random pauses in redisplay up to 0.5s > (and sometimes 1s+). I haven't managed to catch the exact source of > those pauses (and they're longer with my personal config), but even > regular editing is slower: evaluating > > (benchmark 1 '(progn (insert " ") (redisplay t))) > > in dictionary.json reports something like 0.038906s, but in > dictionary-pp.json it prints ~0.136387s. > I cannot reproduce that. With emacs -Q, with dictionary-pp.json and with show-paren-mode disabled, type C-s aan zich RET. Now type some text: in both cases the effect is near instantaneous here, and I do not see any random pauses. With your benchmark and with dictionary-pp.json: - on current master, after C-s eman RET, I see ~100 ms, and after C-s aan zich RET, I see ~100 ms - at ff57f30bee (30 July), after C-s eman RET, I see ~20 ms, and after C-s aan zich RET, I see ~2700 (!) ms - at c59b8dfefa (30 Jun), after C-s eman RET, I see ~20 ms, and after C-s aan zich RET, I see ~2700 (!) ms - with Emacs 28, after C-s eman RET, I see ~20 ms, and after C-s aan zich RET, I see ~3000 (!) ms With your benchmark and with dictionary.json: - with current master, after C-s eman RET, I see ~70 ms, and after C-s aan zich RET, I see ~70 ms So there is no regression as far as I can see.