search

Fanael / persistent-scratch

Preserve the scratch buffer across Emacs sessions
132 stars 14 forks source link

Persistent scratch buffer is saved all onto one line #17

Closed TinaRussell closed 5 years ago

TinaRussell commented 5 years ago

I have my Emacs directory under version control, to help sync it between systems, and to avoid disasters like #15. The problem is, version control is generally per-line—and persistent-scratch-save (using persistent-scratch--save-state-to-string) saves the buffer contents to one line, with \n for newline characters. So, any change to the persistent scratch file is seen by Git as the file being “rewritten”—and git-sync (a useful script for managing a personal repository) often chokes on it, as it thinks there have been drastic changes that I, the user, “should probably handle manually.”

I’m curious how to fix this. If persistent-scratch--save-to-string returned a string with literal newlines, would that mess up the restore functionality? Or is the one-line saving incidental rather than intentional?

Fanael commented 5 years ago

It's purely incidental, something is setting print-escape-newlines to non-nil (it's nil by default). Does this patch help?

diff --git a/persistent-scratch.el b/persistent-scratch.el
index 868800f..aad801d 100644
--- a/persistent-scratch.el
+++ b/persistent-scratch.el
@@ -313,6 +313,7 @@ lexicographically increasing file names when formatted using
     (let ((print-quoted t)
           (print-circle t)
           (print-gensym t)
+          (print-escape-newlines nil)
           (print-length nil)
           (print-level nil))
       (prin1-to-string save-data))))
TinaRussell commented 5 years ago

Yes, it works now! I applied the change manually, re-evaluated the defun, ran persistent-scratch-save, checked the saved scratch file, then ran persistent-scratch-restore, and everything seems to be in good order.

TinaRussell commented 5 years ago

…Weird. After writing that, my laptop battery ran out (not sure if that’s relevant, but it means Emacs quit unexpectedly)—but no matter, I thought, since I had just saved the scratch buffer manually. Anyway, once my computer was plugged in and started up again, I loaded Emacs, and was surprised to find the default scratch buffer waiting for me. I could restore my scratch buffer manually with persistent-scratch-save, and it even seemed to save properly on exit, but it never loaded the buffer properly on startup. Even evaluating (persistent-scratch-setup-default) manually didn’t seem to work.

I fixed this by changing the relevant part of my configuration from:

(use-package persistent-scratch
  :config
  (setq persistent-scratch-save-file (expand-file-name "scratch" user-emacs-directory))
  (persistent-scratch-setup-default))

to:

(use-package persistent-scratch
  :config
  (setq persistent-scratch-save-file (expand-file-name "scratch" user-emacs-directory))
  (let ((persistent-scratch--auto-restored nil))
    (persistent-scratch-setup-default)))

That did the trick. It’s like something in my Emacs is setting random incidental variables to t. :confused: