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: Major modes using `widen' is a good, even essential, programming practice. Date: Tue, 23 Aug 2022 02:59:35 +0300 Message-ID: References: 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="35784"; 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, Gregory Heytings To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 23 02:26:44 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 1oQHkh-0009EP-LY for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 02:26:43 +0200 Original-Received: from localhost ([::1]:53218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQHkg-0000Ug-Cy for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Aug 2022 20:26:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQHKh-00086G-QY for emacs-devel@gnu.org; Mon, 22 Aug 2022 19:59:51 -0400 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:43749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQHKf-0002q6-Mu for emacs-devel@gnu.org; Mon, 22 Aug 2022 19:59:51 -0400 Original-Received: by mail-wr1-x435.google.com with SMTP id n4so15044330wrp.10 for ; Mon, 22 Aug 2022 16:59:39 -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=aJwR7vqB1QWUN2ytXYEumRUoKnV1NRzTObRjG1aBmXI=; b=QYYgHORBYyIUzxkFnFY1+qw5WbmhCd76N+eQQiWF1Nc2TpvBCeksfbwQDTx7sL9AWw wLGbRxlNFRNzsV7CoFW7fp29pt7WDgxYTvRBiShLJWHcXmzQcrb7x3ZMWwNbYCqVdx5Y zigpPtvpsuQwDFvG08vS7KaQPdZWHEgs/+425t7tiQyc1osxdqEF0m3uaZIL1q13bn2v jElPnp3vmkC2ESTSg1yC35tHHFs8RCxVF3abRopvIXuMsUg3o7pPcPXDNOBmwtg1XqcS lr3qFKi5P0/99PNu06qrmR6BqwYYrqom0SFcOGdGKW9k9vGWaYbBu6JzOAoqdNA4V2i1 9MIQ== 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=aJwR7vqB1QWUN2ytXYEumRUoKnV1NRzTObRjG1aBmXI=; b=UDupp6022iTwh07+Jy6skVpr0M4Ru8mnQgaFKJOHyOxgIsKbwRwcb/2lck5qOF+oiq G+WbxxmdYKTuUVkzk08E2erDmmyVN/CfWR0sYHeNunh7KaBdK3LdLTMOzz0E69KpbJfT vbTO/1aRC96/OiK1nTksWC03fbMxSR7ufhOKMyUDS+VdYMZ3jf69Jz6jJjiBJqRuFGBQ 4fDVwdU7QrkPm9UpYCk4Rtw6XRHbaSYkfCHGFhblWwRZP/a1q1+Q5yfEEFI+9YVWKzRP RVxuqisn/gxprl2+Ff92bctWdnynl9ayO3mzeu48c8oTgxaRMy9JXy0jcFAKW79OJJsg E1GQ== X-Gm-Message-State: ACgBeo1hCGFMZCVxQLNMisdAhlCiUb2G8AL3j75Pnb7DeksQdPG7+qHC GNso7TUNhI+TpI9oWm0gXIM= X-Google-Smtp-Source: AA6agR5r5jjkijOj7m15wn95KVwIeGI16mbdP5trBAGLYxsBaB8+MTHytfNje27DiX6DnOEsrfZHmQ== X-Received: by 2002:adf:f391:0:b0:225:2f0b:59d1 with SMTP id m17-20020adff391000000b002252f0b59d1mr12151108wro.31.1661212778557; Mon, 22 Aug 2022 16:59:38 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i26-20020a1c541a000000b003a64f684704sm9080884wmb.40.2022.08.22.16.59.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Aug 2022 16:59:37 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=raaahh@gmail.com; helo=mail-wr1-x435.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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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:293818 Archived-At: Hi Alan, On 22.08.2022 14:26, Alan Mackenzie wrote: > A bit late, but .... Not at all. > On Sun, Aug 07, 2022 at 20:57:59 +0300, Dmitry Gutov wrote: >> On 06.08.2022 23:13, Alan Mackenzie wrote: >>> Narrowing is primarily a user feature. Users can arbitrarily narrow a >>> buffer to ANY contiguous region of text. So when a major mode needs to >>> examine text even slightly distant from point, it MUST widen, to be sure >>> that the text to be examined is within the visible region. > >> Now wouldn't it have been nice if user-level narrowing didn't create an >> *actual* narrowing but only some visual perception of it? IIRC there is >> a third-party package which implements this approach. > > I'm not convinced, given how well narrowing currently works. I don't > think it's useful to debate how things _would_ have been, when they are > currently very different. I admit the migration path looks murky. >> From what I've seen of feature requests related to narrowing in my >> packages, it's always along the lines of "please add (save-restriction >> (widen) ...) around the whole implementation". > >> Are there actually user-level commands which should not ignore >> narrowing? > > Yes, lots and lots of them. goto-char, isearch, occur, and many others. > It might be easier to answer the question which user-level commands are > not restricted by narrowing. You might want to take a look at the patch I posted in https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00644.html It handles a bunch of commands OOTB (namely, simple navigation and editing), and Isearch support took about 2 lines of code. Occur should require attention, one way or the other (it's not obvious to me that Occur should limit itself to accessible region, but if not, navigation to inaccessible parts should undo soft-narrowing), but the implementation should likewise be trivial. The work in choosing the desired behavior for various commands should take the most part of the effort. >> If not, it would be better if user-level narrowing was implemented as >> something else (e.g. two invisible overlays). Then all other code >> wouldn't have to bother with undoing it. > > But "all" other code would instead have to take account of the invisible > overlays instead. I don't think this would be better. It would involve > a _lot_ of work to implement and we'd be left with some other > inconveniences instead of the currently perceived ones. Some of the code would be handled automagically. A lot of the code doesn't want to obey user-level narrowing anyway. And the rest, yes, would need to be updated.