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.devel Subject: Re: locked narrowing in ELisp Date: Wed, 17 Aug 2022 14:44:52 +0300 Message-ID: <83a683drgr.fsf@gnu.org> References: <2d4a8d8f-d17d-6f84-cd45-586db2f9728c@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37881"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 13:52:19 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 1oOHas-0009iS-Ip for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 13:52:18 +0200 Original-Received: from localhost ([::1]:60068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOHaq-0005bR-TV for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 07:52:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37246) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOHTr-00025t-Gp for emacs-devel@gnu.org; Wed, 17 Aug 2022 07:45:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOHTr-0000oh-3t; Wed, 17 Aug 2022 07:45:03 -0400 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=TwIG1OdWdKv1IY/aMlNG/Q7Rna1zC/yBY2NA6nmtJzI=; b=hnVAOEvt2She Mg3ALYR2dOp8nhQkroUKw8DEgvxWrZd2tzarMr5lBU2y1+s0cfEGb23+RMbcJ7foomDQZAAgecWNJ sh3YVmJgk6w4LFUvWuAV+93szcFbvksWHVk1cnVQqeXrpD2Z3zTHN6U0wrIRmBmrGWAsRLmhXjHKW LH3Ew40GokpctzPFSlP6aUZ8WGxSWV/yXX2Avrj/3GS4560sa4UWzAQPGVkUSQjPDtPLsObhdg3Ui wE4l+ZeyMUmfn7kDOU1NHjwBdVEUPSMHXA/upKH6j7Qmgwu3k+f/esOgq13ObEJhIoK7yRkzZlA7c 1Zei3fcxGrDAl67PlmSNFQ==; Original-Received: from [87.69.77.57] (port=4600 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 1oOHTo-0002PR-QQ; Wed, 17 Aug 2022 07:45:02 -0400 In-Reply-To: <2d4a8d8f-d17d-6f84-cd45-586db2f9728c@yandex.ru> (message from Dmitry Gutov on Wed, 17 Aug 2022 03:05:05 +0300) 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:293544 Archived-At: > Date: Wed, 17 Aug 2022 03:05:05 +0300 > From: Dmitry Gutov > > 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. I don't think this is reliable solution for a general problem such as this one. What that package does is prevent _some_ commands and APIs from escaping the "narrowing". But in the general case, once you get low enough into our infrastructure code, there's no way of knowing what is TRT wrt this "narrowing", because the intent of the caller is unknown, and quite a few places in our code will happily ignore it. So I think it is eventually unavoidable to have to define some property of the narrowing that every piece of Emacs will test in order to understand whether it should or shouldn't move outside of the narrowed region.