Re: What should I use to unrestrict a buffer?

[hw <hw@adminart.net>]

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
> > 
> > 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
> > > > 
> > > > Also, I don't want possible restrictions to be restored, like
> > > > (without-restriction) would do.
> > > 
> > > 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 the
> > > widening.  Why would you need to avoid restoring them, and thus change
> > > the restrictions behind some other Lisp program which doesn't expect
> > > its restrictions to be lifted?
> > 
> > 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.
> > 
> > Keeping or restoring restrictions wouldn't be useful.
> 
> 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.
> 
> 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.