help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Heerdegen
Subject: Re: how to force auto-save of buffers not visiting files, right now?
Date: Sat, 19 Mar 2022 04:47:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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?  Why not just use normal backup
files?  You can explicitly force the creation of backup files.  And keep
a lot of them around.  See (info "(emacs) Backup") and
(info "(emacs) Backup Deletion").  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.

If you are familiar with git, I suggest to have a look at Magit and the
wip modes.  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.

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.

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.

Michael.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]