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: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing. Date: Fri, 10 Feb 2023 23:05:07 +0000 Message-ID: <3a2c2404b0db131878c9@heytings.org> References: <166939872890.18950.12581667269687468681@vcs2.savannah.gnu.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> <83bkmdz04y.fsf@gnu.org> <43562d4dd9dffd81938f@heytings.org> <83357ozhx0.fsf@gnu.org> <83wn4zurit.fsf@gnu.org> <83bkmaueib.fsf@gnu.org> <83357fnwyy.fsf@gnu.org> <83v8kalxsc.fsf@gnu.org> <83r0uylu3z.fsf@gnu.org> <83k00qlqkw.fsf@gnu.org> <83cz6iklqm.fsf@gnu.org> 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="33623"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 11 00:06:24 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 1pQcTF-0008Wu-Om for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Feb 2023 00:06:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQcSx-0003ue-Sq; Fri, 10 Feb 2023 18:06:03 -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 1pQcSw-0003uL-9A for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2023 18:06: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 1pQcSw-0006IG-0m for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2023 18:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pQcSv-0002lJ-NC for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2023 18:06:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Feb 2023 23:06: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.167607031610553 (code B ref 56682); Fri, 10 Feb 2023 23:06:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 10 Feb 2023 23:05:16 +0000 Original-Received: from localhost ([127.0.0.1]:38291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQcSC-0002k3-1Q for submit@debbugs.gnu.org; Fri, 10 Feb 2023 18:05:16 -0500 Original-Received: from heytings.org ([95.142.160.155]:51538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQcS5-0002jn-Qb for 56682@debbugs.gnu.org; Fri, 10 Feb 2023 18:05:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676070308; bh=Srg00kv8RZC4acndeSqB1Q8mfZTvH3J9jJyj8jb0/D4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=vKPOweWlGevpHAV9aUT8RPKjlfTMqcvviEGZpw9K8rYwMkc4p0j3eOzJdKxOezhT4 NqEOD9h35bBrFUgIyViS4YR7oO5J536dCjF1p6yzaVUzgFeM3FEOWHhpqx4k8U4Daq gPobwaVlDWv/a/4SGRVMHSNt3wroSnZP9UBo38ItfDCOdjcA9c80Y5QAmGxkxZeHq1 6KyLDJNI+7u2hF2i1hFLl+9do5l/11vh/R1fkEW79OS5B1ElU3h87z93CedSLJN6C8 KQseWCXa22Z6FbNnfpup9UimRsPzogEhGHLW48xoVEPDzkXp2ezISoTrpwyz4QAXm6 /oug6RNRZ7LYQ== In-Reply-To: <83cz6iklqm.fsf@gnu.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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:255306 Archived-At: >> Why do you think it's not useful? It is meant to be used for example >> in a function that is called in fontification-functions to temporarily >> escape the narrowing set around fontification-functions, when its >> author has determined that it is safe to do that, like this: >> >> (without-narrowing >> :label long-line-optimizations-in-fontification-functions >> ... some code ...) > > I'm thinking about code that doesn't necessarily run only from > fontification-functions. If the code is low-level enough, it is quite > possible that it will be called in many different contexts by many > different callers. Think about stuff like forward-sexp, and imagine > some major mode where doing that needs for some reason to look far back > in the buffer, or start from the beginning of a line. Functions like > that cannot know where they are called, and if they want to modify their > behavior depending on the caller's context, they cannot do it without > knowing the label. > They cannot do that themselves, indeed, but the idea is/was not to do that in some low-level code, but around some portions of code at a higher level, e.g. around a portion of a fontification function that would need for some reason to access the whole buffer (e.g. to check what the first few characters of the buffer or of the current line are). If escaping such narrowings should be possible in some low-level code, it is not necessary or useful to return the label. Instead another macro, say 'without-any-narrowings', should be added. The reason is that narrowing locks can be nested, which means that using 'without-narrowing' with the label of the innermost such narrowing does not guarantee that the whole buffer will be accessible. > > From where I stand, the locked narrowing is there to prevent slowdown > due to Lisp programs that are either unaware of special long-line > handling, or are deliberately ignoring it. It is IMO okay for a Lisp > program that is aware of the issue to adapt its behavior by widening the > buffer; if it does so indiscriminately or in a way that hurts > performance, we can consider that a bug and expect the developers to fix > it. > Yes, that is what the without-narrowing macro is for. >> Don't worry, I don't feel accused at all. I was only expressing that >> I'm reasoning against my intuition here. > > It is trivially correct that removing some code removes also the need to > discuss it. This discussion would have not happened if we were to > decide to remove the narrowing in fontificiations and pre/post-command > hooks. > Just in case, so that you can study and try it, I created a scratch/remove-locked-narrowing branch, with four commits: commit 1 deactivates the two places where it is used, commit 2 removes the core functions in which it is implemented, commit 3 removes the other functions used by the core functions, and commit 4 updates the documentation. I also fixed another bug in the scratch/fix-locked-narrowing branch. Again these commits pass make bootstrap and make check, with and without native-compilation.