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: Thu, 09 Feb 2023 19:02:39 +0200 Message-ID: <83k00qlqkw.fsf@gnu.org> References: <166939872890.18950.12581667269687468681@vcs2.savannah.gnu.org> <6c9d91cffc1bfd801530@heytings.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17575"; 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 Thu Feb 09 18:04:27 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 1pQALT-0004NS-9H for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Feb 2023 18:04:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQALI-0002Fy-Ha; Thu, 09 Feb 2023 12:04:16 -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 1pQALB-0002FA-G0 for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 12:04:09 -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 1pQAL4-0004kY-HS for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 12:04:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pQAL3-0007U4-VP for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 12:04:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Feb 2023 17:04: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.167596218728702 (code B ref 56682); Thu, 09 Feb 2023 17:04:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 9 Feb 2023 17:03:07 +0000 Original-Received: from localhost ([127.0.0.1]:33552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQAKA-0007Sr-TL for submit@debbugs.gnu.org; Thu, 09 Feb 2023 12:03:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQAK9-0007SL-4S for 56682@debbugs.gnu.org; Thu, 09 Feb 2023 12:03:05 -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 1pQAK1-0004c6-JT; Thu, 09 Feb 2023 12:02:57 -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=yzAHvnnTbmDTSfNz+e1rI5ByUdOM2YHlrvnlOhGMvXM=; b=rjXpsXOpyuuQ bv9kDpxfgvwkFL0/oCU60azlHRgdQMUM55xYvBR5xenQJ4fxX5TjWdh/y+NjiA2EBolNHG5oqwu6Z b0jSNkXNzTJRcy0ClKR5nR41mTH3O1xAn8CjVRDSleUNJEW39BM+D/9HtxeixVkWbrpfwv/83vkSB Vq6SEuPTdgeSI7W9N0ZxlYbezQn9Ubx0zWe3RkzYXhp6Whq/ZAtTOZPyZR3FMsNez8R454Jd6aCuR 29T87bX5UFIDTb/6BqvRI0J/nVemkaBJOKdoIK3DcIrEq/u79tO5KZ+eAGbev7YFIQpoQg7xsNuhr v8z70ABTC7EJojK50CNgsg==; 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 1pQAK0-0003DJ-MF; Thu, 09 Feb 2023 12:02:57 -0500 In-Reply-To: (message from Gregory Heytings on Thu, 09 Feb 2023 16:11:36 +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:255238 Archived-At: > Date: Thu, 09 Feb 2023 16:11:36 +0000 > From: Gregory Heytings > cc: akrl@sdf.org, monnier@iro.umontreal.ca, 56682@debbugs.gnu.org > > >> (save-restriction (widen) (buffer-narrowed-p)) > > > > We should add it and document it, but I'm surprised that there's no > > easier way. One problem with the above is that it could cause a more > > thorough redisplay because it fiddles with buffer restrictions. > > > > If necessary, a specific function which does not widen could be added to > do that, using narrowing_lock_peek_tag: > > DEFUN ("...", ...) (void) > { > if (NILP (narrowing_lock_peek_tag (Fcurrent_buffer ()))) > return Qnil; > else > return Qt; > } I don't see how we can get away without doing something like that. And I think it should return the tag itself, not just a boolean flag. > > Also, this doesn't return the label itself. > > > > Indeed, but returning the label would defeat the purpose of the tool. If > a program can by itself determine that it is in a labeled narrowing and > get its label, it can escape that narrowing without much ado. 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? I don't want to assume malice on behalf of Lisp programs, I want to give well-meaning programs reasonable means to adapt their behaviors to these narrowings. If and when we see these facilities abused, we can take whatever actions are necessary at that time. But leaving legitimate programs limited because we fear less legitimate programs will abuse them is not TRT in my book. > (Note that I'm writing the above to "defend" a feature that I still > believe should better be removed from Emacs.) I'm not sure what to do with this remark. I'm not accusing you of anything, so you don't need to justify or defend yourself. We are discussing what should this feature include assuming that it will be in Emacs.