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

[hw]

On Sun, 2022-03-20 at 08:29 +0100, tomas@tuxteam.de wrote:
> On Sun, Mar 20, 2022 at 07:36:42AM +0100, hw wrote:
> > On Sat, 2022-03-19 at 10:58 +0100, Michael Albinus wrote:
> > > hw <hw@adminart.net> writes:
> > > 
> > > Hi,
> > > 
> > > > 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.
> > > 
> > > There is the user option auto-save-file-name-transforms, which gives you
> > > this feature also for local files.
> > 
> > Thanks!
> > 
> > Its value is
> > (("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'" "/tmp/\\2" t))
> > 
> > Ah, hm, what is that regexp supposed to match?  All files with at
> > least a ':', a bunch of slashes and some optional brackets?  Who puts
> > bracktes into file names, that shouldn't be allowed.
> 
> The colon is to match remote files. That's the default. Tramp remote
> files for Emacs have a prefix with a colon.
> 
> And the brackets are regexp metacharacters, [^/]* meaning zero or
> more non-slashes (i.e. one path component)
> 
> Or do you mean the parentheses ()? Those are for grouping. Due to
> Emacs's regexp syntax (not ERE) you have to escape them. The extra
> backslash is for the string syntax.

Yes --- I didn't see that because that expression is so unreadable.

Forcing remote auto-save files into being saved into a volatile
directory is worse than not saving them at all.

> > Apprently that leads to puttting some files into /tmp, and I would
> > consider it a bug to put auto-save files into /tmp because doing that
> > totally defeats the auto-saving because /tmp is volatile.
> 
> One person's bugs are other person's features. That's why you can
> change it, after all.

How do I change that /tmp to not being volatile and keep it that way?

> I don't know why the default is as it is, but knowing Emacs I guess
> there has been some discussion. I'll leave it to you to *POLITELY*
> (hint, hint) ask around here if you are interested.

Or it has been decided some time ago when /tmp wasn't volatile and
wasn't changed.

> > I don't
> > know who made the utterly stupid decision to make /tmp volatile,
> 
> Careful. You can change that, too, if you want. Someone thought
> it to be useful.

Like how?

> I'm around for long enough that I remember the
> time before (for Gnu/Linux, anyway). I got along the change. It
> has up- and downsides. Throwing "stupid" around won't change those
> things :)

Some things, like making /tmp volatile, are still stupid.  I
understand and somewhat appreciate that it can be useful to use a
RAM-disk for some temporary files, yet that doesn't mean that breaking
things for everyone would be useful or a good idea.  IIUC, the purpose
of making /tmp volatile wasn't even making it volatile but making
things faster, so whoever did that could and should have introduced an
additional directory for this purpose.  Over time, software could and
probably would have adapted to use either the new directory or not.

For users, it would have been an easy choice to make because they
could simply symlink /tmp to /volatile (or to whatever that new
directory would be called), or the other way round.  It would also
been an option to decide between not keeping and keeping temporary
files.

But no, it was just forced upon us with no choice, and we weren't even
told about such an important change.  I'm sure that some people did
loose their data because of it.  Someone who is in the position to
make important decisions like this needs make better decisions, not
stupid ones like this ones.

> > but
> > it's the way it is since quite a while now.  This default needs to be
> > changed, or /tmp needs to go back to be a useful directory.
> 
> That depends on whether you want that auto-save file to persist
> across operating system sessions or not. Not everybody agrees with
> you (or me) on what a nice behaviour is.

That not everyone agrees with everything doesn't mean that deciding
and thus breaking things for everyone would be a good idea, especially
not when better alternatives are available which accomodate everyone
or at least a lot more people than otherwise.

> > Why didn't they just make a directory /volatile in addition to /tmp?
> > Because someone would argue that when something must not be saved,
> > then don't save it to begin with?
> > 
> > But then, the auto-save files for buffers not visiting files show up
> > in the directories the files are in from which the buffers not
> > visiting these files were created.
> 
> In a way, yes. It's whatever the value of `default-directory' is,
> I guess, unless you give it an absolute path.

Well, why is above regexp apparently ignoring the value of
`default-directory'?  Its description doesn't really describe it in
that it doesn't say what it is being used for.

So what is it being used for?  It's even global and defined in C
source code and buffer-local as well.  Shouldn't it be used to (help)
decide what the default-directory for auto-save files is?

What happens when I change it from it's global value of nil to some
directory?  Why is it nil while the docstring says it should be "an
absolute directory name"?

> > That is very confusing.
> 
> That's perhaps because there are not many people auto-saving
> buffers without an associated file: not many around for testing!

No, that a regexp like that is confusing doesn't have anything to do
with how many people are auto-saving buffers not visiting files.

Besides, IIUC, auto-save-mode is enabled by default for pretty much
every buffer, so everone who changes the contents of buffers, visiting
files or not, is subject to have their buffers auto-saved eventually
unless they change the default.  That's probably a lot of people.