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

[hw]

On Thu, 2022-03-17 at 23:07 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > Think it through: You can only undo when nothing goes wrong.  With
> > copies of buffers being autmatically saved to auto-save files, you
> > can recover from the auto-save files when something does go wrong.
> > When nothing goes wrong, these buffers and auto-save files automatically
> > go away.
> 
> What are these "something"s that make undo not work but have no effect
> on your auto-saving?  How do you check if "nothing goes wrong" and these
> auto-save files can be deleted?

Perltidy is a code formatter for perl, see [1].  It's not impossible that
perltidy messes up the code, and you might find out only later when testing
the program you're working on, which can be hours or days later, after you
have been programming and been using perltidy lots of times.  Your program
may not always in a state where you could test or even run it at the time
when you want to use perltidy.

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.

Swapping buffer contents removes the undo information.  Even if you have all
the undo information, how do you jump between different states of the contents
of the buffer, like to yesterday morning?  Undo goes only step by step, and
you probably do not want to undo hours of programming step by step until you
arrive at yesterday morning, save that state, try to run that version (which
may be unfinished and won't run) and then redo all the steps.

Undo wasn't made for that.  It's great to be able to go back a couple steps,
but not hundreds or thousands.

All kinds of other things can go wrong.  Emacs may crash, your computer may
feeze or crash, your graphics card or your display may fail and leave you
blind, or whatever.  When the version of your program that wasn't altered
by perltidy is lost due to things like that, you won't be able to undo that
when it wasn't saved.

The undo you have in mind only works when nothing goes wrong, and it goes
only so far.

> With only abstract "things that go wrong" and claiming auto save files
> solve all problems and undo none, without being more specific, I can't
> say much more.

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 and libreoffice because libreoffice loves to crash all the time then.
Or use thunderbird and try to open attachments --- you'll find that some
of them are garbled because thunderbird is currently buggy, while evolution
lets you open them just fine.  Other things have gone wrong in the past,
and it's not unreasonable to expect that other things or the same ones will
go wrong in the future.

In any case, I never said that auto-save files would solve all problems.

> If you want files and you feel safe with having them, nothing wrong with
> that.
> 
> And yes, Emacs could perform better with the information collected by
> undo.  "undo-tree.el" is one approach to achieve that.  AFAIR it now
> supports also saving undo histories.
> 
> In your scenario however I would expect that when "something goes wrong"
> you just hit undo and get the former buffer contents, and that's it.

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.

It's enough when you don't like the formatting it produces in some case and
want to undo it.  Without a copy, the undo you have in mind is at best pretty
unwieldy for giving you back what you had before.

My expectation is always that things can go wrong, and I never trust computers.
I do not expect that files saved somewhere will be there and undamaged, only
that they usually are and only because I don't see a better alternative.  A long
time ago I did experience that files got damaged when they were saved, and it
was quite a nightmare and turned out to be due to a broken disc controller.
Another time an xfs file system got damaged and I had to recover from the 
backup,
and I never really found out why and can only suspect that I used wrong settings
when mounting it.

Just expect things to go wrong; sooner or later they will, always.  Remember the
story about why bugs are called bugs, and that alone kinda tells you all about
things being able to go wrong.

The function I created makes it very easy for me to use perltidy and minimizes
the risk of things going wrong, and it has the side effect of giving me copies,
which can be useful.  If you have a better way, it'd be interesting to hear 
about
it.  A simple undo doesn't cut it, it only works when nothing goes wrong.