From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: locked narrowing in ELisp Date: Wed, 17 Aug 2022 04:00:28 +0300 Message-ID: <79484704-f981-5c12-e000-333b75499520@yandex.ru> References: <2d4a8d8f-d17d-6f84-cd45-586db2f9728c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11626"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 03:01:43 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oO7RG-0002qr-LG for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 03:01:42 +0200 Original-Received: from localhost ([::1]:53758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oO7RF-0001gJ-9Z for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 21:01:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO7QL-0000uS-0a for emacs-devel@gnu.org; Tue, 16 Aug 2022 21:00:45 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:34552) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oO7QJ-0004Wi-0Q for emacs-devel@gnu.org; Tue, 16 Aug 2022 21:00:44 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id a4so2770023wrq.1 for ; Tue, 16 Aug 2022 18:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=wV01G08ix2T96SCqXB0Ck7GhcKsWHarbt8N7yyxvgGc=; b=dNXldrtK5/wxYrCGtuJ0l5lOrDCPIMK+H17urlQq/LgKXjIrm/jwzNRrFpyMtpV/wP 2joBvme+zHsSx+rnOKdnIj8kPWwiPfyyX2LQpElhWaoDpVYDuGRgo7UELjrROiqz7W5w 0MSbptMuxiwiW0RoWZ7Lklu+rUcjBaKdBcG9oB8aD+SwuLhv1z9jD2jPD/abF6QMbk+d spR3Vg6v3IjkHrD2eqne+ChJCDOWOqr0KcTL3DwL6cq0cQXd8nySSvVW+XBWOFthbKdO NESW4VuzObwC5d/41qqCF0deNTpD+TE9GTRUzFTJYglmsdJIOy8nocLXC5AKB+rdnhh4 Fj0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=wV01G08ix2T96SCqXB0Ck7GhcKsWHarbt8N7yyxvgGc=; b=w/FcGDGdu7DtfYGHq4UX8fMshvQCx9F+VzzMl2G1ignPVMT2BMzpCKedymfdPpThwK O8o6HxbDBQj2/X1LiC+muhqRpGP1PoLH9e+cL8LzqCmS7L8alQw5KbAee9tj682ycyXs 76QFoJgjYXCmNqlCC++RV/yCUVVSZ0YQcHY1wibHM+wpn5GgKf6w17/qfY6TJ+zs9ut1 LRahRfgzfwPfOvDPBFzhXBFn0KNnA7OCsLZ5S2IujTKnLPuOeP0EupTumAZ2hJBZCQVT ggp98iVPu0ljKYCxqWcbokoWsF4g5vs2nwrsW2rJeKgWklsfciq7l+SK2ieHHi6Ix4zp ihRw== X-Gm-Message-State: ACgBeo3VQ9AVQNKFAYK5uBkmr1TiI/iJvD7Uos15Z1IG4DQxe7vwcsKC tIKPXQMeTN5aLTj/67e0yDk= X-Google-Smtp-Source: AA6agR40YkqMsUQMVUBXO9u0v75Ec+5cPMcHutixWprmNA7ne9xHsiBKPO8i+TclXLRFpvXC6cDl2w== X-Received: by 2002:adf:f909:0:b0:225:c35:8242 with SMTP id b9-20020adff909000000b002250c358242mr5733560wrr.550.1660698032898; Tue, 16 Aug 2022 18:00:32 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j20-20020a05600c191400b003a5c1e916c8sm5450674wmq.1.2022.08.16.18.00.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 18:00:32 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=raaahh@gmail.com; helo=mail-wr1-x430.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293524 Archived-At: On 17.08.2022 03:55, Stefan Monnier wrote: >> Have you given any thought to the "soft widen" alternative >> I voiced recently? >> >> https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00291.html >> >> If the user-level narrow/widen commands didn't use _actual_ narrowing, but >> display engine tricks or whatever (example: >> https://github.com/Malabarba/fancy-narrow/), "other parts of the major mode" >> wouldn't have to do the usual (save-restriction (widen) ...) dance, which >> a lot of code is littered with. >> >> Then there would be no need for "hard" or "locked" narrowing to restrict >> those calls to 'widen', because there wouldn't be any. The >> 'narrow-to-region' and 'widen' would be restricted to lower-level uses, like >> mmm-mode, Info-mode, and the display engine long-line wrangling magic. >> >> The migration path seems difficult, but the result might be worth it. > > Such a display-only narrowing might be a good alternative for many uses > of narrowing, but narrowing is also used quite commonly (either by the > end-user or in ELisp code) in order to restrict the effect of an > operation (like search&replace) to a particular region. Certain operations could look up the "soft narrowing" bounds and act accordingly, if it's implemented in the core and appropriately documented. To my understanding, there are more commands and facilities that want to ignore user-level narrowing, rather than the ones that want to obey it. Also a lot of "undecided" ones, waiting for someone to report that they should, in fact, ignore narrowing.