Reconsider make-backup-files default value

Reconsider make-backup-files default value

[James Ipswich]

Emacs has traditionally kept all defaults very minimal, and most
functionality needs to be explicitly enabled by the user. For example,
out of the box minibuffer and CAPF completion is quite plain.

However, make-backup-files default value is t, which I think goes
against this philosophy. If I open stock Emacs, with no configuration,
it pollutes all directories with backup files whenever I edit something.
This is a bit intrusive as I have never enabled such a functionality.

I understand this default is old, and comes from a time when machines
were less reliable and version control systems were not widely used. I
also understand some current users enjoy this functionality as an extra
safety net.

Personally, I think make-backup-files should default to nil or some
other less intrusive configuration, which would be better aligned with
the rest of Emacs defaults and how other software behaves.

Any thoughts?

Re: Reconsider make-backup-files default value

[Jeremy Baxter]

James Ipswich <james.ipswich@proton.me> writes:
> Personally, I think make-backup-files should default to nil or some
> other less intrusive configuration, which would be better aligned with
> the rest of Emacs defaults and how other software behaves.
>
> Any thoughts?

I also think this default behaviour can be quite annoying but having
automatic backups can also come in very handy at times. A possible
solution to the leftover backup issue is storing backup files in some
specified directory, such as .emacs.d/auto-saves. I think vim stores
them somewhere in .local/state, in my opinion it's quite a neat solution
compared to Emacs' current strategy.

 Jeremy

Re: Reconsider make-backup-files default value

[pinmacs]

+1

I also think it does not make sense this days:

1. There are plenty of free software solutions in the world of: (1) 
version control systems, (2) backup solutions
2. No other editors [2] are doing something like that by default; which 
could generate surprise for new users. In fact, I had this for years 
because I thought that if it was there, was because of something. At 
some point, I did an investigation on my own and I found that "nobody" 
was saying this was useful.
3. It is very strange the way it works [1], in some cases, I had a 
backup years ago from a file that I did changes from time to time (?); 
anyway, I don't use it anymore. When my changes are important, I do git 
on it, and emacs package magit is amazing; I was a long-time user of 
simple terminal git commands, but with magit I could get even more 
precision on what I wanted to stage, unstage, commit, etc. And very fast.

[1] Emacs makes a backup for a file only the first time the file is 
saved from a buffer. No matter how many times you subsequently save the 
file, its backup remains unchanged. However, if you kill the buffer and 
then visit the file again, a new backup file will be made. source: 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Backup.html

[2] At least, not in all the editors I tried or used in the last 15

Re: Reconsider make-backup-files default value

[James Ipswich]

Jeremy Baxter wrote:

> A possible solution to the leftover backup issue is storing backup
> files in some specified directory, such as .emacs.d/auto-saves.

This is possible in Emacs by setting backup-directory-alist, if I
recall correctly. One can also ask for numbered backups, etc.

My point was that the default seems a bit intrusive. AFAIK, Vim and
gedit, two prominent editors that used to have the same behavior as
Emacs no longer save backup files in the same directory. Neovim never
had this default either, I think.

pinmacs wrote:

> No other editors [2] are doing something like that by default [...]

Yes, exactly my point, thanks for the explanation!

Re: Reconsider make-backup-files default value

[Jeremy Baxter]

James Ipswich <james.ipswich@proton.me> writes:
> This is possible in Emacs by setting backup-directory-alist, if I
> recall correctly. One can also ask for numbered backups, etc.

I didn't know about that, neat!

Re: Reconsider make-backup-files default value

[Martin Edström]

> No other editors [2] are doing something like that by default;

Several do, e.g. LibreOffice, TextEdit... they just hide it.  The equivalent of having a backup-directory-alist configured to put it all inside ~/.emacs.d.

Interestingly, Emacs Prelude places it in /tmp, and Doom Emacs disables backups [1], but in case the user re-enables them, it actually hashes the backup filenames to make them shorter [2] but I don't like it since I rename files a lot and the hashed names destroy my ability to find backups under an old name.

[1] https://github.com/doomemacs/doomemacs/blob/master/lisp/doom-editor.el#L94

[2] https://github.com/doomemacs/doomemacs/blob/master/lisp/doom-editor.el#L151

Re: Reconsider make-backup-files default value

[Eli Zaretskii]

> Date: Sun, 15 Sep 2024 22:19:42 +0000
> From: James Ipswich <james.ipswich@proton.me>
> 
> Emacs has traditionally kept all defaults very minimal, and most
> functionality needs to be explicitly enabled by the user. For example,
> out of the box minibuffer and CAPF completion is quite plain.

That's not accurate, but I don't think it's worth our while to
side-track into a semi-philosophical argument about this.  Let's
focus on the actual issue at hand instead.

> However, make-backup-files default value is t, which I think goes
> against this philosophy. If I open stock Emacs, with no configuration,
> it pollutes all directories with backup files whenever I edit something.
> This is a bit intrusive as I have never enabled such a functionality.
> 
> I understand this default is old, and comes from a time when machines
> were less reliable and version control systems were not widely used. I
> also understand some current users enjoy this functionality as an extra
> safety net.
> 
> Personally, I think make-backup-files should default to nil or some
> other less intrusive configuration, which would be better aligned with
> the rest of Emacs defaults and how other software behaves.
> 
> Any thoughts?

I would hesitate to change such long-time defaults.  I'm guessing many
people have good use of these backup files (I do) and expect to have
them (I do); changing the default means they all will need to
customize Emacs, and that's _after_ they find out the behavior changed
and curse us, silently or otherwise.

If someone dislikes these backup files and doesn't need them,
customizing that away is so easy that I wonder why we need to argue
about changing these long-time defaults.  It almost never makes a good
use of everyone's time.  Arguing for changes in defaults of user
options is only useful when the existing default makes absolutely no
sense in any reasonable use case.

Re: Reconsider make-backup-files default value

[Eli Zaretskii]

> From: Jeremy Baxter <jeremy@baxters.nz>
> Cc: emacs-devel@gnu.org
> Date: Mon, 16 Sep 2024 11:29:35 +1200
> 
> I also think this default behaviour can be quite annoying but having
> automatic backups can also come in very handy at times. A possible
> solution to the leftover backup issue is storing backup files in some
> specified directory, such as .emacs.d/auto-saves.

This is possible, of course, and supported by Emacs, but it has a
disadvantage of quickly making that directory unmanageable.  So not
everyone will like this, if it becomes the default.

Re: Reconsider make-backup-files default value

[Eli Zaretskii]

> Date: Sun, 15 Sep 2024 20:40:44 -0300
> From: pinmacs <pinmacs@cas.cat>
> 
> 1. There are plenty of free software solutions in the world of: (1) 
> version control systems

When you edit a file under a VCS (Git etc.), Emacs by default doesn't
create backup files.  So this usage pattern is already taken care of.

Re: Reconsider make-backup-files default value

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Emacs has traditionally kept all defaults very minimal, and most
  > functionality needs to be explicitly enabled by the user. For example,
  > out of the box minibuffer and CAPF completion is quite plain.

This is not a rule, just a usual approach.  It tends to keep
the default mode of operation simple.  If a feature is a possible
convenience, people can turn it on if they want it.

  > However, make-backup-files default value is t, which I think goes
  > against this philosophy.

That is very important.  If you don't save the previous version, you
will regret it.  Being safe is a better default than being risky.

Thus, whether to enable an option by default is a matter of what it does.
Lets not make rigidity our rigid principle.

Changes in the details of making or naming backups are a different
issue.  They are not risky as disabling backups would be.
If we want to introduce a method that is not currently an option,
we should introduce it as an option.

Changing the default details of making or naming backups is
possible too, but we shouldn't consider changing to a method
until it has been in a release for a year and we can see how
much people like it.

"Hiding" backup files might cause a risk that other changed details
would not cause.  If you are not an expert on Emacs, and you don't see
a backup file when you list that directory, you may not realize that
it exists.  You might think that the old version is lost, when in fact
you have it in a backup file.

The harm done by one instance of that could easily outweigh a thousand
instances of being annoyed about "clutter".

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Reconsider make-backup-files default value

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I would hesitate to change such long-time defaults.  I'm guessing many
> people have good use of these backup files (I do) and expect to have
> them (I do); changing the default means they all will need to
> customize Emacs, and that's _after_ they find out the behavior changed
> and curse us, silently or otherwise.
>
> If someone dislikes these backup files and doesn't need them,
> customizing that away is so easy that I wonder why we need to argue
> about changing these long-time defaults.  It almost never makes a good
> use of everyone's time.  Arguing for changes in defaults of user
> options is only useful when the existing default makes absolutely no
> sense in any reasonable use case.

To be quite honest, I don't understand why the default state of backup
files has arisen for "deep philosophical" debate.  The number of
occasions where backup files have rescued someone from a very unpleasant
experience, or where they have simply provided valuable data after a
file was overwritten, must be beyond count in the case of any Emacs user
or installation.  Their usefulness is plain for all to see.

Re: Reconsider make-backup-files default value

[Emanuel Berg]

Po Lu wrote:

> To be quite honest, I don't understand why the default state
> of backup files has arisen for "deep philosophical" debate.
> The number of occasions where backup files have rescued
> someone from a very unpleasant experience, or where they
> have simply provided valuable data after a file was
> overwritten, must be beyond count in the case of any Emacs
> user or installation. Their usefulness is plain for all
> to see.

I think those who don't want it have other forms of backup.
I am one of them and indeed, it came in mighty handy once when
I accidentally deleted a bunch of files.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Reconsider make-backup-files default value

[Petteri Hintsanen]

Eli Zaretskii <eliz@gnu.org> writes:

>> A possible solution to the leftover backup issue is storing backup
>> files in some specified directory, such as .emacs.d/auto-saves.
>
> This is possible, of course, and supported by Emacs, but it has a
> disadvantage of quickly making that directory unmanageable.  So not
> everyone will like this, if it becomes the default.

Storing backups in some centralized directory (by default) might cause
privacy issues as well.  An unwary user may inadvertently leave stray
backups containing confidential data even after they have removed the
originals from the file system.

All kinds of passwords.txt~ files come to mind.

-- 
Petteri

Re: Reconsider make-backup-files default value

[Christopher Howard]

I would vote for keeping backups turned on by default.

Something I have wondered about for a while is why the kept-old-versions default is 2 instead of 1. It makes sense of course that you would want to keep, e.g., the original (template) version of a config file, but what is special about the first revision you made to it?

When using Emacs' backup system, which I sometimes find useful, I usually increase kept-new-versions to 10, though I suppose 2 makes a more sensible default.

-- 
Christopher Howard

Re: Reconsider make-backup-files default value

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> To be quite honest, I don't understand why the default state of backup
> files has arisen for "deep philosophical" debate.

It's because no other text editor does it by default, and many users
consider them as useless clutter.  I think it's expected that this
question will come up every now and then, as long as its the default.

> Their usefulness is plain for all to see.

FWIW, I find them quite useless.  I have put them in a separate
directory for 20+ years, and have never had to consult that directory.
In some cases, I wished I had disabled them, because some data I thought
I had deleted was kept (the "passwords.txt" case).  YMMV.

That said, I have no strong opinion about changing the default.  Neither
choice is obviously better (on or off).  The main reason for keeping
what we have now is that it's always been that way, and changing it
might surprise some users.

If this feature had been added today, we would obviously have kept it
disabled by default.

Re: Reconsider make-backup-files default value

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> To be quite honest, I don't understand why the default state of backup
>> files has arisen for "deep philosophical" debate.
>
> It's because no other text editor does it by default, and many users
> consider them as useless clutter.  I think it's expected that this
> question will come up every now and then, as long as its the default.

The reason the "other text editors" can make ends met without backup
files is that they are designed for MS-Windows, which supports file
version numbers.  Decent text editors always produce backup files (if
not in the same directory), and only if the time comes when users of
Unix systems can easily restore previous versions of a file from a
Properties dialog will Emacs backup files actually become redundant.  As
here,

  https://winaero.com/restore-previous-versions-windows-10/

> FWIW, I find them quite useless.  I have put them in a separate
> directory for 20+ years, and have never had to consult that directory.
> In some cases, I wished I had disabled them, because some data I thought
> I had deleted was kept (the "passwords.txt" case).  YMMV.
>
> That said, I have no strong opinion about changing the default.  Neither
> choice is obviously better (on or off).

It is this reasoning which I cannot understand.  It is always better to
be cautious, especially in this age of 500GB+ disk drives.

Re: Reconsider make-backup-files default value

[Eli Zaretskii]

> From: Christopher Howard <christopher@librehacker.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Jeremy Baxter <jeremy@baxters.nz>,
>   james.ipswich@proton.me,  emacs-devel@gnu.org
> Date: Wed, 18 Sep 2024 13:46:18 -0800
> 
> Something I have wondered about for a while is why the kept-old-versions default is 2 instead of 1. It makes sense of course that you would want to keep, e.g., the original (template) version of a config file, but what is special about the first revision you made to it?

If you start from an empty file, the first version is frequently not
useful.

Re: Reconsider make-backup-files default value

[Alfred M. Szmidt]

   If this feature had been added today, we would obviously have kept it
   disabled by default.

The "obviously" here is clearly not obvious (specially for one where
you have no strong opinion), backup files are still uesful to keep
even today in plenty of situations.

The current default strikes a balance between not having too many, and
stil having them which is infinitly better than never having them in
case of any issues.

Re: Reconsider make-backup-files default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 18 Sep 2024 23:31:07 +0000
> Cc: James Ipswich <james.ipswich@proton.me>, emacs-devel@gnu.org
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > To be quite honest, I don't understand why the default state of backup
> > files has arisen for "deep philosophical" debate.
> 
> It's because no other text editor does it by default

I think "no other editor" is inaccurate: some do.  But many don't,
yes.

> That said, I have no strong opinion about changing the default.  Neither
> choice is obviously better (on or off).  The main reason for keeping
> what we have now is that it's always been that way, and changing it
> might surprise some users.

Yes.

> If this feature had been added today, we would obviously have kept it
> disabled by default.

Perhaps.  But we aren't designing a new feature here, so I agree that
leaving the default alone is the best way forward, since changing the
default is so easy if someone doesn't like it.

Re: Reconsider make-backup-files default value

[Juri Linkov]

>> Something I have wondered about for a while is why the kept-old-versions
>> default is 2 instead of 1. It makes sense of course that you would want
>> to keep, e.g., the original (template) version of a config file, but what
>> is special about the first revision you made to it?
>
> If you start from an empty file, the first version is frequently not
> useful.

Is it possible not to create a backup for a new empty file?
Because empty backups are useless.

Re: Reconsider make-backup-files default value

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Christopher Howard <christopher@librehacker.com>,  petterih@iki.fi,
>   jeremy@baxters.nz,  james.ipswich@proton.me,  emacs-devel@gnu.org
> Date: Thu, 19 Sep 2024 09:10:13 +0300
> 
> >> Something I have wondered about for a while is why the kept-old-versions
> >> default is 2 instead of 1. It makes sense of course that you would want
> >> to keep, e.g., the original (template) version of a config file, but what
> >> is special about the first revision you made to it?
> >
> > If you start from an empty file, the first version is frequently not
> > useful.
> 
> Is it possible not to create a backup for a new empty file?

I don't think we have such a feature, no.

> Because empty backups are useless.

Not always useless, but in most cases, yes.

The first backup is also not useful in other cases: when you start
from a copy of another file, or from something very short.

So I think there's some sense in the current default value of
kept-old-versions.

Re: Reconsider make-backup-files default value

[Andrea Corallo]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> The current default strikes a balance between not having too many, and
> stil having them which is infinitly better than never having them in
> case of any issues.

I agree, plus I think we'd need some strong motivation/evidence to
change such default.  I'm for keeping the current default settings.


  Andrea