Org Mode: Are you ever concerned that you might make some major editing mistake and lose some data?

As a newbie, it seems a little scary to have your entire life in a text file, freely editable, right in front of you. I know that one can have backups and revisions. But what if you make a mistake? You cut some large chunk of text, then get a phone call while your wife screams because she hurt herself. When you get back to your session, you forget that you cut out that large chunk, but it's not obvious that it's missing. Or your cat walks on your keyboard while you're away, and does some damage to your file? Do you perform a regular review of changes made? Or is this not a concern?

I have emacs auto save when idle for a certain period of time. Using org roam splits my notes across multiple files. Finally, I use syncthing to make sure I have backups across multiple devices (and to work across those devices as well).

I have my files under version control. Version control software lets you take snapshots of your files at any point in time and lets you go back to the state in any snapshot.

If you're really scared, host it on gitlab, it will also teach you magit. But emacs automatically saves your opened files every now and then so I wouldn't worry

Others have mentioned version control. I just want to point out that, with version control, the answer to >Do you perform a regular review of changes made? Is yes! That's exactly what happens when you make a commit. You look at the diff between the last commit and what you have, and (hopefully) write a meaningful explanation about what changed, so that when you look back later you'll have that explanation. If you commit frequently, in small increments with good messages, you won't have to wonder.

> Or is this not a concern? It should not be. Not more than say the house burning down, burglars stealing your computer, a flood,... a least as far as your data is concerned. As long as you have backups, regularly save your work (I do it every couple lines, every time I stop writing and each time I step away from the keyboard) and, why not, use version control. Even though I am not a developer, I recently started using version control and it's probably the best addition to my writing toolbox. Sure, it requires some time getting used to it and its 'developer' mindset but it can also be ‘dumbed down’ to a mere mortal level (aka, making it work for a prose writer) and it makes an amazing tool to, well, save your work, keep track of every important change. It is also amazing to test idea, explore leads without ever risking losing a single line of prose. The time spent learning version control basics (and understanding how to make it work with prose, and what habits is worth changing to get the most out of it) is well worth it, imho. Nowadays, I would not start writing a new project without putting it first in its own Git repo. I even automated the whole process with a little shell script. > But what if you make a mistake? Accept it. Mistakes will happen. Even more so, our *own* mistakes that no tool can rescue us from. Hence, the importance of backups to limit the loss. Incremental, local and remote backups (plural is key). With my non-expert backup system the *worst* case that could happen: I lose 24h worth of writing. And that would be the absolute worst. More probably that would be much less than that. I can live with that. > As a newbie, it seems a little scary to have your entire life in a text file, Why with text files only? What you describe could happen with absolutely every single other file type. Edit: clarifications

Thanks for the detailed write up!

I'm familiar with doing such explanations with code. Do you make similar change notes with org mode? That seems like it's so fluid and complex that change notes would almost be just a repetition of what you just did, or similar information that would be contained within the LOGBOOK.

Yes, I think that's a very good idea.

What I do is have a local dir which stores a copy of the file every time I do a save, so every edit and save creates a new file (so if I make 3 edits and save in between each edit, that creates 3 separate files if that makes sense). In turn, that backup gets put into version control AND gets synced to a backup drive. Version control allows me to review the changes. Backup is backup. And the best part is this is all done in less than 10 lines of elisp in my .init file.

Emacs holds a lot of [undo information](https://www.emacswiki.org/emacs/CategoryUndo) in memory. You should try the [Undo Tree package](https://www.emacswiki.org/emacs/UndoTree).

Here are some use cases and a *few* solutions: * save wanted changes * [auto-save-mode](https://www.gnu.org/software/emacs/manual/html_node/emacs/Auto-Save-Files.html) * periodically back up buffer contents into *different* files. * [auto-save-visited-mode](https://www.gnu.org/software/emacs/manual/html_node/emacs/Auto-Save-Files.html) * periodically save buffer into *current* file. * revert unwanted changes * [undo-fu-session](https://gitlab.com/ideasman42/emacs-undo-fu-session) * persist buffer undo between Emacs sessions * long-term history * version control system (e.g. `git`, `svn` etc.) * long-term storage * redundant backups on different devices (e.g. `Syncthing`, `rclone` etc.)

Emacs has a good built-in undo function. And that one can be beefed up further with [undo-tree](https://www.emacswiki.org/emacs/UndoTree) --- which I used for some years --- or [undo-fo](https://gitlab.com/ideasman42/emacs-undo-fu) --- which I use now ---. On top of this, I'm a programmer. So I'm used to keep all important stuff under version control, orchestrated by Magit. I use org-files mostly to track progress of large work-related projects, and also to document them. As I keep my source-code in git, it's just natural to do the same with the the org files. > Or your cat walks on your keyboard while you're away, and does some damage to your file? Undo foo. Also, should I later use magit to check in my changes, I see the diff and would see if something unrelated changed. But more important, I don't have a cat :-) > Do you perform a regular review of changes made? Yes, implicitly via magit. I generally view ever diff "hunk" before committing. Often, I only commit some lines, so that the source-code change and the doc change are in the same commit. I tend to make rather many small commits than one huge "end of the day" commit. With these big commits, you tend to not look at the changes. > Or is this not a concern? Yes and no. It would concern me normally. But not the way I work. Because of the way I work, I even disabled Emacs from creating backup files.

I keep many text files and link them together.

I keep all my org-mode files in Dropbox (unless they’re already in a Git repository). Dropbox takes care of uploading versions automatically, and can roll back a file arbitrarily.

Version control works well if it's part of your regular workflow, but regular backups would work too.

I have a `cron` job that uses `rsync` to copy my files to my work OneDrive every 15 minutes. OneDrive has versions, so I can roll back any time I want to. If I didn't use that, I'd use git with automatic commits.

Set up a backup directory, where emacs saves mutiple numbered versions of your files automatically: https://www.emacswiki.org/emacs/BackupDirectory

syncthing is not a backup! If one copy gets damaged, that corruption may just be silently copied to all the other devices.

I use git to prevent disasters. But this setting has saved me a few times: (setq org-ctrl-k-protect-subtree t) If you try to delete a hidden sub-tree, you will get a y/n query. Before I started using git, sometimes I would accidentally delete a subtree and not notice it for a while, leading to grief.

> change notes would almost be just a repetition of what you just did I use version control for my notes and do try to leave meaningful commit messages. I don't repeat the change I made but instead write a one-sentence description of the change. "Fleshed out argument about ostriches and garden hoses", "Added a few TV shows my brother recommended", "Typos", "Reordered list of IKEA's tricks to get you to buy more", etc. I don't see why writing commit messages needs to be any different for code than for prose, but maybe I'm missing something?

> When you get back to your session, you forget that you cut out that large chunk, but it's not obvious that it's missing. If you never notice it's missing later, then you didn't need it. If you do notice and have backups or version control, you restore the missing chunk. In either case what you don't do is worry about it. :)

What I meant was, sometimes I totally forget things, and maybe I want to search for some knowledge that I thought was important. I might have a good majority of the knowledge there, but there could be some fact missing, and I might not even know it's missing, despite the fact that I thought it was important to remember in the past. Or maybe I just don't have the patience to go looking for it in the version control. I might not recall when it was added, could be years later I wanted to reference it. But yeah, I'm not really going to worry about this. It is what it is. Org mode has its pros and cons, and I'm going to stick with it.

If you do use source control, just take a peek at the changes before each commit to safeguard against accidental deletion.

Interesting, thanks!

No you're not missing anything, I think that's a good idea, thanks!

Yes, I can see the benefit in making more smaller changes than one big change. I'll check into those undo packages. Thanks for the write- up!

Yeah that's a good poor-man's version control, I'll probably go ahead and do that next week just to give me a little more peace of mind. I'll eventually get around to just doing version control prob.

Thank You!!! I set that in my init.el file. Easy fix to give me a little more confidence at this stage, especially since I don't have version control in place.

Hmmm... you make backup files, like notes.org.001, notes.org.002, notes.org.003? And all of those go into version control along with your notes.org. file? Wouldn't that be overkill since version control can save the changes with your one file?

I'm going to look into it, thanks!

Oh very good beakdown, thanks! And this: persist buffer undo between Emacs sessions. I really want that! Thanks so much I'll bump up the priority of undo-fu!

Yes, I think this strategy generally minimizes the amount of damage that can occur to any one file.

Can you do diffs on the versions? Can dropbox make named versions?

Yes, numbered backup files like what you mentioned above are what go into my backup dir. But no, the main file (notes.org) with no version number is the one that stays in source control. Sorry, I should have described that a little better.

Undo is you friend. If I've lost context while editing, I'll undo until I recognize my changes. At that point I can move the cursor and undo will now redo changes so you can review cat footprints in case they somehow fixed your race conditions.

I've been using this setup for many years. VC is also suitable, though if you don't actually need version history then it's just a waste of effort. If you only need safety backup then with this backup solution you can set how many old versions should it kept (say, 30 or 50 or whatever),so you can go back and retrieve the content in case of a problem.

[deleted]

(Full disclosure: I can't speak exactly for org-mode. But I have used git to version-control some large LaTeX documents.) I find the key with commit messages is to explain the context of *why* the change was made, rather than just what was changed — the diff will show the latter, as you've pointed out. So, for example, the commit message may mention your source, your inspiration, or your intention. If you replaced something, it may explain the difference. If you added something, it may explain why this and not something else. It's a place to store your thoughts about the change external to the document, but still associated to it. I like to imagine someone coming across a line, saying, "Why the hell is this here?", and then reading the commit history and coming away satisfied. Some commits speak for themselves; not every commit needs a novel. So a simple "Add items to XYZ list" may suffice.

+1. I make commits for every little change I make just in case I do something stupid (I'm almost famous for my mistakes :/)

You can set it to save versions though

If you use vc, then you can type C-c C-w in the commit buffer to get a Changelog-like style entry. This might be good enough to keep a list of headings that changed.

You can do better than poor man's version control if you use vc-backup alongside. It is a vc frontend for backup files!

Interesting! The online documentation is rather terse. How does this benefit me beyond emacs native backup system? (And tbh, I don't know much about emacs native backup system, only that I think it does something like notes.org.001, notes.org.002, etc.)

Good points, thanks!

I hope to get to this level within a few months! Thanks!

No problem, thanks again!

You can take a look at the commentary section of the package to see the list of implemented features. Full disclosure: I havent tried the package myself since my backup settings are all messy, but you can e.g., show a diff between revisions, jump to an earlier revision, etc. If Philip happens to see this thread, maybe he can chime in? (Hi Philip!)

> you can e.g., show a diff between revisions, jump to an earlier revision That's basically all I would want or expect out of a package like that. List versions, show diffs, maybe add names to versions. Thanks! I'll definitely give it a consideration. Though I think when I graduate from backups, my next step will probably be full version control system.

magit-wip-mode

You can backup your data automatically after every save using the after-save-hook if you are paranoid. :D

2 steps (*i.e. git and 4 lines of elisp*) 1) Install git. 2) One-click to commit from emacs: i.e. create a simple keyboard shortcut like Ctrl-1 to commit your file to git from within emacs without asking you anything else See *details* on how it's done. **Why do this?** i) **why git?**: it is worth it to make the first step into the world of "git": it is an initial investment, but well worth it even if OP doesn't yet use it to its full extent. ii) **why the small emacs script below?**: once git is installed, a simple key press (Control-1) in emacs would then issue a command to commit, silently; no emacs package to install. If something goes wrong, everything's in git. **details:** 1) install git (for windows, you could install git-bash) then do this: cd myDir <-- where your myfile.txt resides git init git add myfile.txt git commit -m "my initial commit" 2) put this in your .emacs: ;;this will issue a command to the shell (defun execute-shell-command-on-buffer (shell-command-text) ;;from https://gist.github.com/tenpn/2367513 (interactive "MShell command:") (shell-command (format shell-command-text (shell-quote-argument buffer-file-name))) ) ;; Hold Control key and then press number 1 key and it will issue a git command (global-set-key [(control \1)] (lambda () (interactive) (execute-shell-command-on-buffer "git commit -a -m\"silent comment from emacs.\" ") ) ) Hold Control key and then press number 1 from time to time and it just does git commits silently, without asking for anything else. Fire and forget. From there, you can then evolve to "magit" or other solutions, if you feel like it. **Edit**: *I added the function definition that I had missed initially + more comments on the key to use. Thanks to Status-Detective for letting me know. Also, see my comment below. https://www.reddit.com/r/emacs/comments/ticvrq/org_mode_are_you_ever_concerned_that_you_might/i1pejkh/

Well you sent this newbie down a rabbit hole. It was NOT as easy as you suggested. What is `global-set-key [(control \1)]`? Is that `C-1`? I don't know what that means, but being the idiot that I am, I kept pressing C-1 thinking that it must be committing my changes. My emacs doesn't even recognize that as a keypress. So doing nothing, the rest of your command was never executed. Once I changed that, it gave me an error on `execute-shell-command-on-buffer`. What is that? Oh, it's a 10 year old answer to a stack-overflow question: https://stackoverflow.com/questions/10121944/passing-emacs-variables-to-minibuffer-shell-commands, with definition here: https://gist.github.com/tenpn/2367513 Good thing I wanted to add a little print to the mini-buffer just for fun. SIX HOURS LATER, I think that MAYBE I got your suggestion working? (defun execute-shell-command-on-buffer (shell-command-text) (interactive "MShell command:") (shell-command (format shell-command-text (shell-quote-argument buffer-file-name))) ) (global-set-key (kbd "C-c k") (lambda () (interactive) (execute-shell-command-on-buffer "git commit -a -m\"emacs newbie commit.\" ") (message "Issued git command") ) ) I mean, it probably works now. I'm just not sure what `"MShell command:"` does. Probably nothing.

[deleted]

I find that writing those one-sentence descriptions is a good review of what I wrote and helps me remember it better.

a) I actually did say **"Ctrl-1"** in the text. Maybe I need to add: press Control key and number 1 key at the same time. OK. b) execute-shell-command-on-buffer: OOPS. Indeed it need to be defined. My bad. I'll update my post accordingly. My point is that: i) it is worth it to make the first step into the world of "git": it is an initial investment, but well worth it even if OP doesn't yet use it to its full extent. ii) once git is installed, a simple key press (Control-1) in emacs would then issue a command to commit, silently; no emacs package to install. If something goes wrong, everything's in git. BTW, that's what I use to this day, even after seeing all the other (nice) solutions around. I just like simplicity.

Thanks for the clarification! Yes, I'm glad I got this done, thanks. It gives me assurance of a versioned backup (better than just Dropbox, where all my files reside). That C-1 combo, is that a chord? You have to press both at the "same time" (within a low fraction of a second threshold)? If so, you might want to call it a chord press for newbies. And the simple mini buffer message I added does give a nice little feedback.

Not a chord. On MS Windows: You just hold the Control key, and quickly press number "1" (I developed that habit on my keyboard as both keys are close, but you can use something else if it works for you.) And the main advantage is you have full control: if something goes wrong, you can drop to the command line and use git. Edit: I update my post to clarify things. Thanks Added MS Windows for clarity.

I don't want to make things more complicated, but if you're ready to have your mind blown away: install git-timemachine in your emacs (https://gitlab.com/pidu/git-timemachine) You'll be able to cycle through versions of your file in the past from within emacs without the need to go into a command line for git, and without magit or anything else. Simplicity. Worth the investment if you ask me.

Hmmm. Holding the control key down, like a shift key, and then tapping 1. That did nothing on my macport emacs v 27.2. It's not recognized as a key press. The 'C-h k' describe-key command just sat there, like it was saying, "well? I'm waiting for you to press something..." And I'm away from my desk right now but I believe that my system did not even recognize C-1 as being bound. I looked in C-h b, iirc

Maybe it's a MS Windows thing (I'm on Windows). Use another keybinding then. For macos, you may want to check this out: https://www.emacswiki.org/emacs/EmacsForMacOS#h5o-36

Arrgh! Command + 1 is a dedicated MacOS keybinding that means "Switch to Desktop 1". And since I only use Desktop 1 at the moment (and I'm new to MacOS), it effectively does nothing. But it's still a binding! Oof. This was one of those perfect storm technical issues that had rabbit hole after rabbit hole all lined up to waste a lot of my time, lol! Anyway, it's all resolved now, and I have git working, and I'm a little less stupid now. Thanks again for helping me out!