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

[hw]

On Sat, 2022-03-19 at 04:47 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > > But why isn't your code located in a buffer visiting a file?
> > 
> > It is.  The output of perltidy replaces it.
> 
> Ok - but does it have to be auto-save?

No, it doesn't.  It only seemed to be an easy way to achieve what I
wanted.

> Why not just use normal backup files?

Because I would need to delete them eventually, and IIRC, tramp
doesn't necessarily delete them.  Some (remote) directories are not
writable by the user editing the file.

For example, I may edit a file '/usr/local/bin/example.pl' which is
owned by foo:foo because I made that so.  The directory
'/usr/local/bin/' is owned by root.  How do you expect emacs to create
a backup file there?  For remote files, I have set
tramp-auto-save-directory to a local directory, and I'm missing an
equivalent option for local files.

> You can explicitly force the creation of backup files.  And keep
> a lot of them around.

I can't (actually I don't want to, but you get the idea, and then
there is also NFS which would require me to go to lengths to force it,
depending ...) force the creation of backup files in non-writable
directories.

I don't want to keep a lot of backup files around in directories like
'/usr/local/bin/'.  Going through all the overhead of using git when
you have users waiting on you to fix a little problem isn't ideal when
you don't want to turn '/usr/local/bin/' into a git repo.  First fix
the problem so the users can keep working and then bring the git repo
up to date.

> See (info "(emacs) Backup")

Hm I keep forgetting that emacs makes only one backup file only once,
which makes them pretty useless.  And I can't be bothered to configure
emacs on all machines and for all users and keep the configurations up
to date.

Who can remember things like ‘C-u C-u C-u C-x C-s’ just to save a file?

> and (info "(emacs) Backup Deletion").

What happens when I edit the same file directly in instances of emacs
running locally in a session of tmux accessed through ssh and
indirectly in instances of emacs running remotely, visiting the file
through tramp?  Neither the versions of emacs, nor their
configurations are identical.  They are versions like 29.0.50 (Fedora,
wayland version), 24.3.1 (Centos 7), 24.4.1 (a derelict Gentoo
installation), 27.1 (Debian) ...

How do you make sure that all obsolete backup files are being deleted
without configuring about 20 instances of emacs on different machines
for different users?

> You can, for example, have hundred backups of each file you edit -
> in a folder of your choice so that they don't clobber your working
> directories.

I don't want like 20000 backup files all over all the places :)  When
something goes wrong, you're basically guaranteed that either at least
some of them will stick around or relevant ones will be deleted, or
both, in which case you may be left with only the irrelevant ones.
And which ones are the relevant ones?  Can you tell by their numbers?

> If you are familiar with git, I suggest to have a look at Magit and the
> wip modes.

Yes, I need to look into good ways to use git with emacs.

> After some setup, you get a backup for every save - or even
> two, if the original state of the file was not yet backed up.  Due to
> git's delta compression it doesn't waste much disk space.  The interface
> lets you browse the versions and diff them etc.
> 
> "helm-backup.el" does something similar.  You can use more than one
> method to gain some protection by redundancy.  The git based approaches
> have one big disadvantage though: deleting old versions is not trivial,
> you need to mess with git trees (that are not even branches) and
> manipulate references "by hand".  Not cool.

Right, I wouldn't want to have obsolete copies cluttering the repos
for every time I press C-x C-s or C-x s.  I rather commit only the
version that is working after it was modified, not countless
intermediate versions.

Emacs crashed a lot on the Atari ST, and I still automatically hit 'C-x
s' almost as much as I used to.

> I always wanted to implement a similar interface for making backups
> using "bup" - which would offer efficient compression of subsequent
> versions without the need of registering (tracking) the files, but
> didn't start the task yet.  With "bup" you can at least store backups in
> different places, it's somewhat easier to handle.  But it also doesn't
> allow history manipulation in a simple way.

But then you would have to configure all instances of emacs.

> And then you can make redundant backups of these backups to disk so that
> you finally can, without fear, rely on undo :-) In your case, undo
> should normally work, and it should be the fastest way to get the
> original contents back.

Ok so I run perltidy to replace the contents of the buffer visiting
the program I'm working on, save the buffer so I can run the program
and the power goes out, the computer freezes, emacs crashes or
something else goes wrong and it turns out that perltidy messed up my
program.

How do I undo the changes then?  Undo only works when nothing goes
wrong.

Sure, it "normally works" when you ignore that swapping the buffer
contents inevitably removes the undo information, which means it
doesn't work.  Yet "normally" is kinda boring, and backup files and
auto-save files are precisely for when things get interesting and when
we need to be smarter than boring.