5

My Internet was not working, and while waiting it to go back up, I used Emacs to type some ideas first.

A few minutes later, the Internet was up, and I checked my Chrome browser, and it worked. So I will use Google Docs instead, I thought.

So I came back to Emacs and too quickly pressed CTRL-x CTRL-c, and Emacs exited without asking. Will everything I typed be gone forever?

I saw some way to make scratch persistent if we configure it, but it seems weird if Emacs actually will exit without asking and let the content be gone forever without warning.

5
  • One way to handle this is to open a plain text file and write your comments there. In that case, Emacs will not exit without asking you if you would like to save the file first. Commented Oct 4, 2016 at 12:02
  • There is also M-x remember-notes. I learned about it from a similar question here a while back. Maybe a search will bring it up. Oh, wait … here it is. That question is not an exact duplicate of this one, but it is relevant. Commented Oct 4, 2016 at 12:18
  • 2
    What to learn from your experience: Do not use *scratch* for stuff that you don't want to throw away. (That's what "scratch" means.)
    – Drew
    Commented Oct 4, 2016 at 14:10
  • I will point out that the *scratch* buffer comes with the following notice: This buffer is for notes you don't want to save. But if you do want to save what is in your scratch buffer, just C-x C-s to save it somewhere. Commented Oct 4, 2016 at 16:28
  • @Drew: Alas, it would also quit silently, without saving (at least that's what mine does), if it's not the *scratch* buffer, but one that was created by a call to switch-to-buffer "name" somewhere, which does create a new one if "name" was not found. After modifying that, emacs would still fail to consider it "valuable" enough for its usual "modified buffers exist" warning (perhaps because it has no file associated with it), which is rather unfortunate.
    – Sz.
    Commented Aug 17, 2023 at 20:55

3 Answers 3

4

@Harald answered your question.

But I would not say "unfortunately". This is by design. Buffer *scratch* is designed for what its name suggests and its initial contents describe: It is a scratchpad, for throwaway content.

If you use it for some other purpose then you are misusing it.

  1. But of course you might want a scratchpad that is automatically backed up (autosaved) periodically. If so, then use a buffer that is backed by a file.

For example, edit your Lisp scratch in a new file buffer iii.el or whatever. Then (a) you can more easily save the content, if you want, and (b) Emacs will prompt you about any unsaved changes when you use C-x C-c.

In other words, Emacs does not prompt you about unsaved changes for *scratch* because it is not a buffer that is designed (intended, by default) to be saved. For that, use a file buffer, even for a not-yet-existing file.

With respect to autosaving, be aware that it happens only for an existing file, that is, a file on disk. So if you want autosaving to kick in then you must save the file buffer at least once.

  1. If you want C-x C-c to ask for confirmation, that is easy to get. You could even have it let you know about modification of buffers, such as *scratch*.

This is what I use:

(add-hook 'kill-emacs-query-functions
          (lambda () (y-or-n-p "Do you really want to exit Emacs? "))
          'append)

That always prompts me, when I use C-x C-c, regardless of the state of any buffers. You might prefer something more specific, which checks certain buffers etc.

You can also use command customize-customized to check whether you have unsaved customizations.

2
  • 1
    The “unfortunately” part of my answer is because the OP lost content of interest, which is always bad. I totally agree that this behaviour is by design, however. But is it good design? Not so sure about that; though the name *scratch* does seem like a strong hint, at least to native English speakers. Commented Oct 4, 2016 at 18:19
  • @HaraldHanche-Olsen, ahh, only noticed your comment after adding mine to the question. Totally agree, and it's even worse than that: there are apparently cases, where it's not even the *scratch* buffer, but any other regular new one, but one which has not been associated with a file yet. Even that would be lost without warning, unless explicitly saved at least once before quitting (because save-buffer will then assign a file to it)!
    – Sz.
    Commented Aug 17, 2023 at 21:04
2

The short answer is yes, unfortunately. But see this question for hints on avoiding this in the future.

1

Yes.

However, I would like to recommend an easy way of using emacs more efficiently.

First, you create emacs server: emacs --daemon

This makes emacs run as daemon(server mode), which means that you have one emacs server and you can have multiple clients.

Now when you open emacs(using emacsclient -t or emacsclient -c depending on console/GUI), you create new window(in emacs terminology you refer to it as a Frame). When you C-c C-x, you only close "Frame" - the client. The server is still running, so you can run another emacsclient, and you scratch will be the same as before.

The upside of this solution is that you start server once, and it's there in background; if you have many packages, Emacs can take few seconds to start. This solution makes starting an emacs client instantenous.

Warning

The above solution isn't perfect. It's good, it helps and fixes many problems, but one of Emacs's flaw is its design: it's single-threaded.

This means that some code that is executed might get stuck in an infinite loop. And this means you will be forced to kill the Emacs server and everything running there.

2
  • 1
    pkill -USR2 emacs (or any other way of sending SIGUSR2 to the Emacs process) usually gets you out of infinite loops. (Offer void on Windows, I don't know if there's an equivalent feature.) Commented Oct 4, 2016 at 21:43
  • @Gilles will try that next time, looks like valuable advice, thank you! Commented Oct 5, 2016 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.