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

[hw]

On Sun, 2022-03-20 at 01:21 +0100, Michael Heerdegen wrote:
> hw <hw@adminart.net> writes:
> 
> > 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.
> 
> I'm was talking about backup files, not about auto save.  You can
> control where these are saved.

Are you tring to say that I should configure making backup files in
some directory I like to use for them, configure things so that every
time I save a file, yet another backup file is being made, and then I
should use perltidy only after saving so that finally, I have to
delete all the backup files once I figured out which ones I don't need
any longer?

> > Who can remember things like ‘C-u C-u C-u C-x C-s’ just to save a
> > file?
> 
> If you want to use that stuff automatically, you can do it otherwise,
> you already wrote some Elisp code.  It's surely not my advice to always
> save using that keystroke.

I tend to go with default key bindings.  If I don't do that, I would
have to configure all the key bindings I might use and whatever is
needed to make them work everywhere for whatever program I make key
bindings for, and that isn't feasible.  Or I would be screwed because
I don't even know how to quit a program because I don't know which key
to press.  Even the key bindings of emacs are not the same depending
on what kind of display you're using, i. e. a GUI frame or a console
frame.  Even if I configured all that, I might end up stuck in vi
because I overlooked that some user hasn't configured their EDITOR
environment variable to emacs but to vi (which tends to be a default
with Redhat) and hasn't configured vi to use the key bindings I'm used
to.

> > 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 could, for example, use directory local variables and configure
> things so that all backups are located at one centralized place.

Then what do you suggest that I do when the connection to this central
place is down, or the server that serves that place is down? Why would
I care to painstakingly create a single point of failure?  And who is
going to configure all that?

> > 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.
> 
> With Magit or helm-browse, these saves would not be commits or parts of
> named branches.  They would live under a configurable separate namespace
> in e.g. ".git/refs/wip/".

That might be a nice feature.  I don't know Magit, helm-browse and git
well enough to say anything about this.

> > 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.
> 
> My advice was to use undo when nothing went wrong, and your backup
> concept when something went wrong.  Sorry if I wasn't clear enough in
> that regard.

Oh, ok, I don't have a backup concept I could use for that.  I haven't
really needed one for this because I haven't replaced the contents of
a buffer like this before, and undo plus auto-save files plus saving
the file(s) I'm workig on plus regular backups of everything has been
working well enough so far.

And fortunately, emacs never crashes :)

> What kind of solution d you want to have?  I find some of your answers
> contradicting, e.g. you say you don't want lots of backups because you
> don't want to delete them manually.  But automatic deletion is also not
> good because, what if the relevant backup was among the deleted files.
> You do not want to loose anything but OTOH do not want to clobber your
> repository, etc.

What's contradictory about that?

I'm making backups I don't need to delete unless something went (very)
wrong.  The automatic deletion isn't going to delete anything I would
want to keep (even when and especially if something goes wrong).  I'm
also not clobbering my repository.  With a couple lines of elisp,
emacs is doing it for me in a side effect of what emacs is making
easier for me to do.

There are disadvantages, like when things go bad, I'll have to delete
a bunch of auto-save files; the undo information is being removed from
the buffer by swapping buffer contents (which can be an advantage),
not all the modes are being copied from the original buffer to the
buffer holding the copy (doesn't matter in this case), and the
bookmarks are invalidated (which kinda sucks).  I can live with those,
and maybe some of them can be fixed.

> How could a solution you _do_ like look like?

I like this one:


(defun my-perltidy-replace (_)
  "This function replaces the contents of the current buffer with
the output of perltidy, and makes a backup of the current buffer.

Before and after modifications to contents of buffers are being
made, all buffers that need to be auto-saved are being
auto-saved.

The major-mode of the buffer containing the backup is set to
'cperl-mode'."
  (interactive "P")
  (do-auto-save)
  (let ((tidy_buffer (generate-new-buffer (generate-new-buffer-name (concat 
"TidyBackup-" (buffer-name))))))
    (with-current-buffer (buffer-name)
      ;; swapping the text can screw up linum mode with two buffers in
      ;; the same frame when automatically enabled by cperl-mode
      (linum-mode -1)
      (shell-command-on-region (point-min) (point-max) "perltidy 
--standard-output" tidy_buffer)
      (buffer-swap-text tidy_buffer))
    (with-current-buffer tidy_buffer
      (auto-save-mode nil)
      (do-auto-save)
      (cperl-mode))
    (linum-mode 1)
    (message "buffer contents replaced with output of perltidy; backup is in 
%s" tidy_buffer)))


And for the record:


(defun my-transient-copy (_)
  "This function makes a copy of the current buffer to a new
buffer.  The new buffer does not visit a file.  Its name is based
on the name of the current buffer.

The 'auto-save-mode' is enabled for the new buffer, and all
buffers that need to be auto-saved are being auto-saved right
away, once before the copy is created and once after."
  (interactive "P")
  (do-auto-save)
  (let ((transient_buffer (generate-new-buffer-name (concat 
"transient-copy-of-" (buffer-name)))))
    (copy-to-buffer transient_buffer (point-min) (point-max))
    (with-current-buffer transient_buffer (auto-save-mode nil))
    (do-auto-save)
    (message "transient copy created as %s" transient_buffer)))