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: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing. Date: Fri, 30 Dec 2022 13:51:19 -0500 Message-ID: References: <166939872890.18950.12581667269687468681@vcs2.savannah.gnu.org> <20221125175209.51166C004B6@vcs2.savannah.gnu.org> <6c9d91cffc1bfd801530@heytings.org> <6c9d91cffc394613f58a@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="19464"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 56682@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 30 19:52:15 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 1pBKUI-0004rE-9D for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Dec 2022 19:52:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBKU9-0001ut-LF; Fri, 30 Dec 2022 13:52: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 1pBKU7-0001ul-64 for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2022 13:52:03 -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 1pBKU6-00028w-TC for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2022 13:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pBKU6-0007qp-Eq for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2022 13:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Dec 2022 18:52: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.167242629630147 (code B ref 56682); Fri, 30 Dec 2022 18:52:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Dec 2022 18:51:36 +0000 Original-Received: from localhost ([127.0.0.1]:36116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBKTg-0007qA-18 for submit@debbugs.gnu.org; Fri, 30 Dec 2022 13:51:36 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBKTe-0007pu-1d for 56682@debbugs.gnu.org; Fri, 30 Dec 2022 13:51:34 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DBE0D808B2; Fri, 30 Dec 2022 13:51:27 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 206C58024C; Fri, 30 Dec 2022 13:51:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1672426286; bh=T9xt2VMaUzGNXzQOunyDidPEX8cepEcjcCXTBymwpzc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LEEIWFfEvgbd1Vgt76peyiLmb5pojMiiY3isoqQ3WAFCyvyIxUGaQZTfkkUg0/hSB a+Ek/JhC3XQQBuQJU8TVaGLjMZqoMaJVnyBVzQKYerX1mA7lxjQkc7HOfmAZYYFT8c hIFucNWVOkqL+MFV/NtZTNSARx0qLIUSUPTQkrx7bmdLXuUx4c2FcGVedmHOjqf44L VtQQJjRj0tszc0Z8wl+iXJaXgAX6eGJSs0tVPyysYc0pvy2UmLhWeK6+qMVy+bDnRB 0lojvwn6v9HC+yjY4Apsrf4l2RObaaaybpPbbd8ee9B6Kl4FS7J1sQdXOLSL10e+LH 0Syna69WwsxAQ== Original-Received: from pastel (unknown [45.72.200.228]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA9F8120314; Fri, 30 Dec 2022 13:51:25 -0500 (EST) In-Reply-To: <6c9d91cffc394613f58a@heytings.org> (Gregory Heytings's message of "Fri, 30 Dec 2022 17:25: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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252150 Archived-At: > You have to know where your function is called and by which caller > a lock was placed. That doesn't seem sufficient, because you need to additionally find the name of the tag they used. AFAICT currently you can only find that out by looking at the code. I think the names should be documented somewhere else than just in the code itself. > Currently there are three such tags (and I don't expect more > tags in core): fontification-functions, pre-command-hook and > post-command-hook. These names seem wrong: I don't think the tag should say when/where the lock happened to be placed, but what caused it to be placed. IIUC all three cases up there share the same reason: overly long lines. So I think they should all use the same tag which could be something like `long-lines` or maybe they should use names such as `long-line-threshold` and `large-hscroll-threshold` to record precisely the cause for the lock. >> Looking more at the code, I have another question: why is >> `narrowing_locks` a global alist indexed by buffers, instead of being >> a buffer-local variable? > > For efficiency reasons. If it were a buffer-local variable, > reset_outermost_narrowings, which is called by redisplay_internal, would > have to consider all buffers, which would become unnecessarily slow with > many (say 1000) buffers. With a global alist, only the (few) buffers in > which narrowing locks are actually in effect are considered. Then I suggest you put a comment to that effect in the code. I also can't understand why we need `xdisp.c` to call `reset_outermost_narrowings`. I see you tried to explain it in the doc-comment of the function but I failed to understand the explanation. Maybe you could extend the comment by pointing to a very concrete example (or maybe a discussion on the mailing list)? Another problem I see with it is that it seems to presume a very particular use of locked narrowing (such as the one installed by the long-lines code), whereas other uses of locked narrowing might not want to be reset during redisplay. Similarly the doc-comment of `narrowing_lock_get_bound` talks about "bounds ... that are visible on display", but that function doesn't know what bounds are visible on display, actually. The interaction with what's visible on display completely depends on when/where it's called and when/where locks are installed. Could you try and clarify the doc-comment to say what the function actually does, and then separately explain how it *may* relate with "what's visible on display" and under which assumption this relation may hold? IIUC what the function does when OUTERMOST is true is return the narrowing that was in effect when the first lock was installed, right? Stefan