From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: hw <hw@adminart.net> Newsgroups: gmane.emacs.help Subject: Re: What should I use to unrestrict a buffer? Date: Thu, 08 Feb 2024 06:38:15 +0100 Message-ID: <6566e11c1b329e777c4e9dd7f62e662d6c484829.camel@adminart.net> References: <4df85194384c642c3cda3289cd1ac1a20ee42bcc.camel@adminart.net> <86r0i5dgvh.fsf@gnu.org> <cdec1d74bb1c3570eb30f3152d30ebbb09740402.camel@adminart.net> <86y1cdb5h6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40010"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 08 06:39:08 2024 Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org> Envelope-to: geh-help-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 <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>) id 1rXx7r-000A9m-TU for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 08 Feb 2024 06:39:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <help-gnu-emacs-bounces@gnu.org>) id 1rXx7A-0006Lp-Sr; Thu, 08 Feb 2024 00:38:24 -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 <hw@adminart.net>) id 1rXx78-0006JI-V8 for help-gnu-emacs@gnu.org; Thu, 08 Feb 2024 00:38:22 -0500 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.218]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <hw@adminart.net>) id 1rXx76-0003bD-Qq for help-gnu-emacs@gnu.org; Thu, 08 Feb 2024 00:38:22 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1707370695; cv=none; d=strato.com; s=strato-dkim-0002; b=enUbW+Borc76zxWoxqKSEeGuf+cVUCzQ3XSEX9dhTJxIxq1qelC9IYE5bEjE6m17BJ hVxpgFpNepP2h7i4iD8Y3bUOJD9wIkXuaA3k90TtT45KKqWk7pU1FeUHSpYxTqcMvIey 6/mtUkKcvo8cq3CZLVgpxMJXLSrCngE38cmudxMZq0ezY6WKAv5bhR52BQzPESvJlK3e 46HPyjQ9vVuvrJwWjmyjAOilsyyh6fID6zeVvpHILyt+G8LsBFk2oQnyJZetrsj95ge8 3R+AfRV/kiQZDJ+lski5KsTmHImaLtvSHPmTUhprVBBt/cgm6oWFmdgtH3lcPUVd7vXx KU4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1707370695; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Date:To:From:Subject:Message-ID:Cc:Date:From: Subject:Sender; bh=WhUSkw9ytWpAnCgc3aBonM3Wl/1wBLkhYpacQH/bhe8=; b=ES4guIFuxpTuALSc2am8qoWePOIFK0AMIzeQKDFDVGxq7te2WaV0OTPV0KikMORJFp XCHXKrj9T/njZo4MjIUHFBed7+248WAWoymdC/RHVdOG9uUMPhmIPPqhgbM/9f48iuFM rgIXrJS7Ok5690r3RZYjDX+TrdVl5Myhrbfp2K0KkTCq7Bxb7XN/ugVa2T9vt2SA8XAr RONAYVm9IhMNZii9YBgkOprfHu7UqkLld8K4H9kzF007hB24nOKhIMdA1zzjo3QPdX8M IghZs1oYSdn9jylst/sf110E1yuJvhlQmX5xiGYVIW0nskDH4+bi9mwEGJBxPcyAJxUi pPIg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1707370695; s=strato-dkim-0002; d=adminart.net; h=References:In-Reply-To:Date:To:From:Subject:Message-ID:Cc:Date:From: Subject:Sender; bh=WhUSkw9ytWpAnCgc3aBonM3Wl/1wBLkhYpacQH/bhe8=; b=gYOqjahinjMLQ/FOPQNlWwXCTo/y8rEwjDey6cW7ip9VmlqXUwEznoUmnRB51/ilNW X3qzKFlots4CQRLN0EbcMpPShxgsScoX1Ocj2VOGdIch3dog8IsPaIoFKZwVS4zNBMGT vYo27ms/qeNsEQZCJUAzUlpLi8/TYuJlHSy7eB0DnEsdOVraXVsGBe5wnx863JNKBhj1 0M9heGAqUbgx9ShBqC07uwx7rqTSYaEKm6R1LpC3PxToVAMsdzK/BconwgKJ/Ot3y1S9 drZFqSWHeYgpvcyIpA9VgFb1fzTkDjnobIz/DEhlLTzkjjokivdT4TQPFvGJA36mKMVb c3lg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1707370695; s=strato-dkim-0003; d=adminart.net; h=References:In-Reply-To:Date:To:From:Subject:Message-ID:Cc:Date:From: Subject:Sender; bh=WhUSkw9ytWpAnCgc3aBonM3Wl/1wBLkhYpacQH/bhe8=; b=7kxwzbCcqAwKRIYQOUWvXRh5hGtZu1wVr3myKovu1pMKND2Qz5Iyuzc/UQLAx821sy heUbo6MgrgX+gUQ5bGDQ== X-RZG-AUTH: ":O2kGeEG7b/pS1Ey9Rna9iAZFrfz26y6zbtmqiE/f0+UVPWzfkhbRoUzSCTTNnjIupuXQshKqSmhSDVvony6i1weUKtlbj4WMF+E=" Original-Received: from [IPv6:2a09:8e40:377f:1c00:1:ff:ff:f] by smtp.strato.de (RZmta 49.11.2 AUTH) with ESMTPSA id U7e39f0185cFr1g (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for <help-gnu-emacs@gnu.org>; Thu, 8 Feb 2024 06:38:15 +0100 (CET) In-Reply-To: <86y1cdb5h6.fsf@gnu.org> Received-SPF: none client-ip=81.169.146.218; envelope-from=hw@adminart.net; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-gnu-emacs>, <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/help-gnu-emacs> List-Post: <mailto:help-gnu-emacs@gnu.org> List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-gnu-emacs>, <mailto:help-gnu-emacs-request@gnu.org?subject=subscribe> Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145888 Archived-At: <http://permalink.gmane.org/gmane.emacs.help/145888> On Thu, 2024-01-25 at 21:03 +0200, Eli Zaretskii wrote: > > From: hw <hw@adminart.net> > > Date: Thu, 25 Jan 2024 19:30:17 +0100 > >=20 > > On Thu, 2024-01-25 at 09:14 +0200, Eli Zaretskii wrote: > > > > From: hw <hw@adminart.net> > > > > Date: Wed, 24 Jan 2024 21:12:56 +0100 > > > >=20 > > > > Also, I don't want possible restrictions to be restored, like > > > > (without-restriction) would do. > > >=20 > > > Why not? After you do whatever you need to do with the widened > > > buffer, you are supposed to return the restrictions to their previous > > > state, and that includes restoring the restrictions present before th= e > > > widening. Why would you need to avoid restoring them, and thus chang= e > > > the restrictions behind some other Lisp program which doesn't expect > > > its restrictions to be lifted? > >=20 > > I want to behold the whole buffer after the operation was performed to > > see if the outcome looks ok. And if the external program has found an > > error, it puts a message into the first line of its output (the > > buffer) which I'm unlikely to be able to see when the buffer is > > restricted. > >=20 > > Keeping or restoring restrictions wouldn't be useful. >=20 > The restrictions that cannot be lifted via a call to 'widen' aren't > supposed to be lifted. IOW, a Lisp program that calls 'widen' is not > allowed to look beyond those restrictions that 'widen' cannot remove. > So what you want to do is not supposed to be done, and this is a > protocol of using restrictions in Emacs. >=20 > The problem is not serious, btw, since it is a very rare situation to > see such restrictions in practice. So you can simply disregard that > possibility. I can't just disregard the problem because disregarding it means that many hours of work which may have been done over many years could get lost in an instance just because some buffer restriction has been overlooked. Is there a way to find out if any restrictions are in effect so that the function may refuse to replace the buffer contents when restrictions could lead to loosing those contents, or parts of them? Otherwise it's an accident waiting to happen, and it basically makes all functionality to pipe buffer contents through external programs and updating the buffer with the result, if not useless, at least a bad security risk.