elisp code clobbering a buffer, instead of saving off elsewhere... why?

Question

I'm having some difficulties when trying to set something up that saves some persistent state, so that I can use the data between emacs invocations.

Using as a starting point some code from another question, I came up with the following little code snippet for something I'm wanting to do:

(defmacro with-output-to-file (path &rest body)
  "record output of commands in body to file"
  `(save-excursion
     (let* ((buf (find-file-noselect ,path))
            (standard-output buf))
       (set-buffer buf)
       (erase-buffer)
       ,@body
       (save-buffer)
       (kill-buffer))))

I then have a function that uses this, like:

(defun my-save-some-data ()
  (with-output-to-file my-data-save-file
                       (prin1 my-data)))

EDIT: These both follow code like the following (previously, these were both setq; thanks to a comment from @phils for inspiring me to switch them to devfar and defcustom):

; note: my actual variable names (and filename value) are different;
; changed for example sake:
(defvar my-data (make-hash-table :test 'equal) "Data for a thing")
(defcustom my-data-save-file "~/tmp/my-data.el" "File to save my data to")

(Note: I also have a function to read the data back in, which happens automatically at load time, or on demand.)

I've set that up to run in a few circumstances (maybe too many? maybe poor choices? Anyway, this is what I set up):

(add-hook 'auto-save-hook 'my-save-some-data)
(add-hook 'kill-emacs-hook 'my-save-some-data)
(add-hook 'post-gc-hook 'my-save-some-data)

Most of the time, this works fine. However, every once in a while, I'm getting a problem where the data gets written to one of my previously-open buffers (killing all previous content there!), and then that buffer gets killed, with the saved changes.

Suffice it to say, this is highly annoying, as the buffer where this happens is frequently somewhere where I've been doing some work, and not necessarily checked it in yet.

I tried altering the macro above, replacing from (set-buffer buf) on with:

       (with-current-buffer buf ; because set-buffer wasn't working??
         (erase-buffer)
         ,@body
         (if (eq buf (current-buffer))
             (progn
               (save-buffer)
               (kill-buffer))
           (message "buffer changed?!"))))))

This has somehow managed to cause it to append to the buffer, instead of overwriting it... so my if statement does seem to be working to some degree... however I don't see the message in my *Messages* buffer, so... I'm not quite sure what's going on.

One thing I think I've noticed (though it's hard to be certain, since I may not be actively paying attention when this happens) is that this happens in a not-then-currently-active buffer, rather than a buffer I'm currently editing.

So, the questions:

1. Am I doing something wrong here?
2. Are there other/better ways of doing this?
3. Are there standard ways to save state in a programatic way, that I could be using? (I poked around a bit in apropos, but failed to find anything... though perhaps I just don't know what to look for.)
4. What can I do to help myself track this down? (is there a way I can set breakpoints or something?)
5. Are there other protections I could use in code like this?

Any other thoughts welcome. I'm adding some more (message) forms in hopes of getting more debugging info in the mean time.

UPDATE: I've figured out that this only happens with the post-gc-hook. I don't know if my variables were somehow getting clobbered (and perhaps switching to defvar and defcustom will solve that?), or if there's some sort of obscure bug in the post-gc-hook processing... checking for reproducing the test-case with this latest change.

Answer 1

You can indeed set breakpoints, an easy way to do this is to put (edebug) in the place where you want to break. Then you can use, n for next, SPC for step, and e to eval. You can read more about edebug here.

So you can set a conditional breakpoint as a protection/warning, like this, before your call to (set-buffer):

(when (get-file-buffer my-data-save-file) 
 (read-from-minibuffer 
   (format "Warning: %s is already being visited by a buffer, contents will be overwritten! Entering edebug" my-data-save-file))
   (edebug))

This will warn you and then enter the debugger if a file you are visiting in some buffer is about to be overwritten by your macro, where you can inspect what is going on.

Here is part the docstring of find-file-no-select:

Read file FILENAME into a buffer and return the buffer.
If a buffer exists visiting FILENAME, return that one, but
verify that the file has not changed since visited or saved.

My guess is that the my-data-save-file is already being visited by a buffer, so that is the buffer that is returned (and subsequently overwritten). But you can really find out what is happening with (edebug).

Answer 2

Just a quick reply to some of what you said. Your message never appears probably because you test whether the buffer of with-current-buffer is the current-buffer, which it always is, unless body changes the current buffer.

But you are right to use with-current-buffer instead of save-excursion followed by set-buffer.

As for other ways: why not put your data in a temporary buffer and then use write-file or append-to-fileor write-region?

FWIW, I tried your code briefly and saw no problem. But I just tried a simple (prin1 (symbol-function 'my-save-some-data)) for the body and a constant file name for the file. I tried with pre-existing file or not, and with pre-existing buffer or not, and with pre-existing unsaved modified buffer or not.

Are you testing with the interpreted code (e.g., macro present) or byte-compiled code?