Re: how to force auto-save of buffers not visiting files, right now?

[hw]

On Sat, 2022-03-19 at 02:18 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > When you use perltidy only right before you want to run and test your
> > program, you still want to have a backup from before you used perltidy
> > so that, if you need to, can try the version that wasn't altered by
> > perltidy to see if that makes a difference.  Of course you can save
> > backups manually, but it's nicer to have that automated.
> 
> But why isn't your code located in a buffer visiting a file?

It is.  The output of perltidy replaces it.  So I can either manually have
perltidy save the output to a (temporary) file, mark and delete the source
code in the buffer visiting the file, visit the temporary file, mark the
altered source code, copy it, paste it into the buffer visiting the file,
save it and finally delete the temporary file.

That would be quite unwieldy, and I won't have a backup.

I guess I could have perltidy overwrite the file that is being visited.  In
that case, I would have to revert the buffer and the unmodified version is
lost, so I still won't have a backup.  I'm not sure if and how well undo
would work in these cases.  I may be wrong, but I'm assuming there is a limit
to how much undo information is kept.

A simple case like the power going out will destroy all undo information and
the unaltered version of the file.  I have seen (cheap, but APC) UPSs causing
power outages more often than the power went out simply by perferming a self
test, and there is no guarantee that more expensive ones may not have the
same issue.

> > I can't possibly list all things that can go wrong.  Maybe you have never
> > experienced that a computer or software doesn't work as it should or that
> > things can go wrong.  If you want to find out, you might use wayland with
> > sway [...]
> 
> X crashes often enough, sometimes including the kernel.  That's good
> enough for me.
> 

Hm, I haven't had that in a very long time.  It almost never happens.

> > Why would you expect that perltidy will never ever damage your source code
> > so that you do not need to keep a copy of what you used it on?  That would
> > be unreasonable.
> 
> That's what I don't understand: if it's your source code, why is your
> question about "how to force auto-save of buffers not visiting files,
> right now?"?

Because I was trying to find out how to do that.  If you look at the function I
wrote and\or try it out and see what it does, you'll understand.  How would you
do what the function does?

I found some functions like it on the emacs wiki and on github.  I didn't like
the ones on the wiki and was unsure about the one on github.  So I decided to
write my own.

It doesn't even matter if you use perltidy or any other program to alter and
replace the contents of the current buffer, or if you don't alter them at all
(or alter them yourself) and just make transient copies.  Being able to make
transient copies on the fly can be a useful feature in itself.