emacs-oob-reboot
emacs-oob-reboot copied to clipboard
josteink
Do not inhibit backups and auto-saves
These settings added in https://github.com/josteink/emacs-oob-reboot/pull/7
Autosaves and backup files are there to protect the user. Disabling that protection is a bad idea IMO. What's the rationale behind doing that?
Similarly for create-lockfiles.
I don't think disabling any of the protective features in Emacs makes for sensible default behaviour.
@phil-s If this feature of Emacs was better documented and explained to the user, then I might agree–as something for the user to turn on. As it stands, for a new-user, having files clutter up their directory and autosaves happen without their clear knowledge is contrary to workflow in other text editors. Other popular editors do not create extra files and periodically save by default. It also has the potential for the polluting of a project in VCS as the new user may not realize they are tracking these files.
Basically, it should be default off and then the user can choose to enable this protection with the knowledge of how to actually use it. Personally, and anyone I know who uses Emacs, doesn't use these features.
@phil-s Expanding: if this is to make OOB Emacs experience less painful, disabling features that are very Emacs specific and require a more intermediate knowledge make sense. When I first started Emacs, I was like why are these files being created? What are they? Why is the file saving automatically? I had to search to figure that out. It wasn't obvious.
But yes, maybe it helps the user, but only a more advanced user. Not a user that just was introduced to Emacs.
What is the default of other editors ? I also think this is a feature, users usually activate after they decided to give a new editor a try.
Auto saving is a feature that is best when its out of the way. Not much needs to be said on what auto save means for any user.
Emacs mode line even periodically says its saving the file. How is this not enough?
Focusing on what other editors are doing isnt the best way to go about this. Inspiration perhaps yes but calling some feature as not modern or user friendly solely because another editor doesnt have it means nothing.
Besides its hard to say what is user friendly and what is not. People come from different backgrounds with different concepts of all things.
Emacs is best when the user is allowed to shape it in the way they wish. This is the power and beauty of emacs. ITs not what we agree emacs should be. Its how we tailor make it for ourselves. So instead of focusing on rather small details on how a defualt emacs should look why not instead put users in a position to explore and shape emacs to their liking? A better means of exploration, documentation, tutorials, etc. Improve the means for the user to know emacs and shape emacs to their liking.
On Sun, May 7, 2017 at 2:22 PM, brotzeitmacher [email protected] wrote:
What is the default of other editors ? I also think this is a feature, users usually activate after they decided to give a new editor a try, but I could be wrong.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/josteink/emacs-oob-reboot/issues/25#issuecomment-299724640, or mute the thread https://github.com/notifications/unsubscribe-auth/AHdJSM7wSHLAHDy-MugRVo_KVHLEGHF1ks5r3gwAgaJpZM4NTEz6 .
So instead of focusing on rather small details on how a defualt emacs should look why not instead put users in a position to explore and shape emacs to their liking?
I totally agree, but most users need time to feel comfortable enough to even think about building their own environment.
I feel like the clutter is completely unnecessary. If a user wants it they can google it or be told about it in the tutorial, apart from that I say no to the backups. Auto-save is absolutely fine in my opinion.
@Grimscythe1983 It's hard to google for something you have no clue might exist. Also not everyone reads tutorials in full.
@angrybacon are you then suggesting that we should leave the backup feature on?
@Grimscythe1983 Yes absolutely, both backup files and lock files. And if we agree to leaving the backup files, then leave auto-save on for sure too; if not, perhaps increase the value for auto-save-timeout.
Ok then, can I then suggest to put all the backup files into a single directory, so that the feature doesn't trash?
Ok then, can I then suggest to put all the backup files into a single directory, so that the feature doesn't trash?
This is what I was going to say, put them in ~/.emacs.d/tmp or something out of the way.
Something like this (setq backup-directory-alist '(("." . "~/.emacs.d/backup"))) does the trick.
What's the harm in leaving them next to their related file? It's so much easier to access them. If the issue is Git-related (or similar), I found it to be a good opportunity to setup my global .gitignore.
Yes absolutely, both backup files and lock files. And if we agree to leaving the backup files, then leave auto-save on for sure too; if not, perhaps increase the value for auto-save-timeout.
As someone who considers myself a advanced user by now, I've had nothing but trouble with the lock-files. I find them highly unintuitive, and I am consistently annoyed whenever I meet them. The only thing I see them doing, is breaking my workflow.
File-locking, if done (and that can be debated. No other editor on the market locks files!), should be done at OS-level, with real file-locks, provided by the OS.
What Emacs does doesn't actually work the second you step outside the Emacs-frame, and even inside Emacs it feels broken.
The current implementation in Emacs is terrible, and I really think it would benefit new users to disable it, maybe coupled with auto-revert-mode, to avoid conflicts when a file is open/edited in multiple editors or programs at the same time.
Here's a clear vote for disabling locking.
What's the harm in leaving them next to their related file?
Tidiness? I personally hate clutter, I simply hate when files show up that I haven't made myself.
Here's a clear vote for disabling locking.
Same here, disable locking. It is very confusing for a new user.
Backups are an useful safety feature and have saved me from losing a couple hours of work more than once. I think we should consider solutions other than disabling them altogether, e.g. introducing a size limit and (setq backup-directory-alist `(("." . ,(locate-user-emacs-file "backups")))), or perhaps using a per-drive and per-user directories (similar to how Linux file managers handle the Trash folder).
@pkkm How long did it take you to figure out how to use it? (I'm asking because I don't think a new user can utilize it with any effectiveness)
It doesn't take much to understand what they are, they are grayed out and visiting them should make it clear that they are an older version of the file.
@angrybacon True, but it does increase the bar for people to get into Emacs.
I don't remember exactly, but I think I figured it out quickly. I might be an outlier though, I was already a programmer and had used another editor which makes backups.
Anyway, I agree that the default backup settings aren't intuitive for new users; my point is that there may be a good solution that doesn't litter all over the place but still makes some backups. New users may not even know about the backups until they accidentally overwrite something important and google for ways to recover it. I don't have an exact proposal, but I think the two possible solutions I described in my previous post are a good start for discussion.
What's the harm in leaving them next to their related file?
Contrived example: Imagine a piece of software that automatically includes all config files in a directory. I edit a file in that directory. Now I have both my new edited version and the old version, both of which the program includes because the programmer forgot to exclude files ending in ~. Kaboom!
I have my autosaves consigned to something like ~/.emacs.d/backups. The downside here is that it silently fills up over time and could potentially be a security problem (e.g., I edit a root-owned credentials file with mode 600 on a remote server using tramp, now the backup save is in my home directory, owned by me. oops....).
I don't know what the right course of action is here, but I'd agree that the current default is not usual or expected.
Now I have both my new edited version and the old version, both of which the program includes because the programmer forgot to exclude files ending in ~.
That requires 1. that the user forgot / didn't know he had to ignore backup files, 2. that he added the backup files to the commit (himself, not Emacs on its own) and 3. that the user decides to commit configuration files at all. Usually I see .sample files.
Kaboom!
Huh?
now the backup save is in my home directory, owned by me
Yeah that could be bad. Why not use Emacs from that remote instead? Or better disable backups altogether when doing remote?
@angrybacon I think you're losing sight of my point. We're not talking about me, we're talking about a new user, who has only used more "conventional" editors in the past, and is trying out emacs.
-
The config file example was a bit contrived, and probably very unlikely; but things like this have happened to me in the past when working with less-than brilliantly written software. Yes, there are things that "could have" or "should have" been done, the point is that people unused to the emacs way of working wouldn't necessarily expect that save file to be there, and in such a situation it can cause problems. And unless you
lsyour directory after every save, you're not likely to notice these files (or know where they came from). -
With the tramp/remote thing -- the point is that if autosave is enabled by default and directed to a hidden directory, inexperienced users won't know of its existence and will likely make this exact blunder.
Why not use Emacs from that remote instead?
Perhaps Emacs isn't installed on the remote? Certainly not with my personal settings.
Or better disable backups altogether when doing remote?
Why would a new user do this if they didn't even know backups were being done in the first place? Heck, I don't even know how to temporarily disable backups, and I wouldn't remember to do it every time I edited a potentially sensitive file.
I don't know what the answer is on the autosave issue. I think that:
- The current default behavior is a useful safety feature, at least for config files and random editing (One would hope for codebases you're using version control). Leaving those save files everywhere is kind of a nuisance.
- Disabling it puts emacs on par with most other editors in this regard. It removes a significant annoyance, but at the cost of a potentially butt-saving feature.
- Redirecting the files to a hidden location is probably a bad idea. It's only a good idea if you know it's being done and know how to manage it. For beginners, not such a good idea.
the point is that people unused to the emacs way of working wouldn't necessarily expect that save file to be there
I'm assuming the user is familiar with basic usage of a version-control system. The user would have to deliberately add the backup files himself.
Perhaps Emacs isn't installed on the remote? Certainly not with my personal settings.
That's the thing I was implying using your own configuration remotely after installing whichever version suits you. But I get it, not always an option.
inexperienced users won't know of its existence and will likely make this exact blunder
Well, we're talking about a user who attempts to work on a remote machine where he knows root-owned credentials live from his local Emacs. I'd expect that person knows what he's doing. But you're also right, he wouldn't automatically guess that backups are made at all.
Redirecting the files to a hidden location is probably a bad idea. It's only a good idea if you know it's being done
One way of ensuring they know backup files are being saved somewhere would be not to make it a default behavior. :-)
Whatever you all decide on, one thing I can recommend is that when closing emacs (or just the buffer) without saving changes, emacs should ask if you want to save the file only ONCE. One thing that constantly bothered me was it asking me twice and STILL leaving those backup files. To me, if I intentionally close without saving, it should remove those backup files. Or am I wrong on this? I thought the point was to protect you from system (or just emacs) crashes. I made a change in my config to only prompt once, though I don't have access to it at the moment to show what I'm talking about. And I support having all those files with # and ~ (I forget which one does which) saved to a single location in ~/.emacs.d
it should remove those backup files
Do you mean lock files? Backup files, lock files and auto-save are 3 different things.
Do you mean lock files? Backup files, lock files and auto-save are 3 different things.
I'm referring to the backup files (~) & auto-save files (#). I'm not exactly sure why Emacs uses both. I understand the usefulness of the auto-save files and I don't seem to have a problem with them, they go away if emacs is properly closed. The backup files, however, stay. Why?
When you have different save slots in a game, they don't disappear when you exit the game. :-)
I don't think that's the best analogy. The "game" here is a text editor and the save slots are you text files. Why is my game creating hidden backups of my save slots? I understand this may have been useful when Emacs was first created, when hard drives (and floppy drives) were less reliable and the chance of file corruption was much greater. But today... me thinks it no so necessary.
This is regardless of where we should store the backup files.
In my analogy, the save slots of your game are foo.el~. The auto-save slot (the one you load when you just select "Continue" as opposed to "Load") is foo.el, it's the latest version. Provided the game supports the "Load" feature and allows to keep several slots of saves, then I wouldn't expect it (the game) to just delete those previous saves (foo.el~) upon restart.