From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing. Date: Fri, 10 Feb 2023 09:44:49 +0200 Message-ID: <83cz6iklqm.fsf@gnu.org> References: <166939872890.18950.12581667269687468681@vcs2.savannah.gnu.org> <6c9d91cffc394613f58a@heytings.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11008"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 10 08:46:29 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 1pQO71-0002eV-CG for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Feb 2023 08:46:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQO6u-0002zw-3J; Fri, 10 Feb 2023 02:46:20 -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 1pQO6c-0002vl-NW for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2023 02:46:10 -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 1pQO6c-00047B-EO for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2023 02:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pQO6c-0000HD-3b for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2023 02:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Feb 2023 07:46: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.16760151491042 (code B ref 56682); Fri, 10 Feb 2023 07:46:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 10 Feb 2023 07:45:49 +0000 Original-Received: from localhost ([127.0.0.1]:34241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQO6O-0000Gk-Eo for submit@debbugs.gnu.org; Fri, 10 Feb 2023 02:45:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQO6M-0000GV-8F for 56682@debbugs.gnu.org; Fri, 10 Feb 2023 02:45:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQO6F-00043n-5j; Fri, 10 Feb 2023 02:45:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Cx0Aj9YDSNcNNS21KrDR2p2MPU0d4o/Pcuc9F5+8KX4=; b=AGYtEMmr70+4 2a0PpBTVqVKKtBiDb/No2YnX0/W2jELrfFLcup0bmR+vmcf8y/Du9il7U5kGvB1N2kXiHfAmAEvoo +zsTLL3xoY5hi85zM7yZAH5OTsHhBfdwAVNTY8tiAjr1ujtEslgqZ1aVDQ/nIdcRMM50aZCLmVN4o kUlXyrRr9uvEdHOvT7oUVMxX3p2ZB2GBgdJbV2eNV7mS9KjCCil4zdKhWVzqja1zBgNYcOKpDo3f6 ljkY9s2Jp2hHR9z3BLbagM44UmfyZcNanJRfKBAqiZfu1RX0DUkwBRneX0ESYi5GNY8UDUY2ZnDf/ JbxlDbqlpopBxiF3A9Gmmg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQO5z-0003kV-Ez; Fri, 10 Feb 2023 02:45:36 -0500 In-Reply-To: (message from Gregory Heytings on Thu, 09 Feb 2023 20:47:11 +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:255280 Archived-At: > Date: Thu, 09 Feb 2023 20:47:11 +0000 > From: Gregory Heytings > cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org > > > We make a point of documenting these labeled narrowings in great detail, > > including the labels and their effects. It makes no sense to describe > > them and not let programs adapt their behaviors to these situations. > > Without access to the label, the without-narrowing macro is not useful, > > so why provide such a macro at all if we really don't want Lisp programs > > to use it? > > 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. > IMO, if it becomes possible to escape the narrowing programmatically (IOW, > without even checking where and why the narrowing has been set), the > exercise becomes even more pointless. >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. > (Also, in that case it seems to me that there is no reason anymore > to label these narrowings: their label serves no real purpose.) I think the label allows different methods of behavior adaptation. No one said that being called from fontification-functions calls for the same behavior adaptation as being called from, say, post-command-hook. > 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.