Enhancing `denote-rewrite-front-matter` to save and kill buffer when it's safe to do so about denote

[jeanphilippegg]

The latest versions of those functions have a :save-buffer optional parameter that allows saving the buffer after renaming. They are still not closed automatically though. There are many situations in which Emacs is not deleting buffers automatically (Dired, Magit, Org agenda, etc.). I do not know if there is a good reason for that.

[mentalisttraceur]

That's good, but I'd rarely want to simply unconditionally save the buffer, because

1. if I already have unsaved changes, they're unsaved for a reason, and
2. all I said above about safety if the file was changed outside of Emacs.

So this only reduces my wrapper like this:

 (defun fixed-denote-rewrite-front-matter
         (denote-rewrite-front-matter path &rest arguments)
     (let* ((buffers (buffer-list))
            (buffer  (find-file-noselect path))
            (_ (refresh-modified-state buffer))
            (had-unsaved-changes (buffer-modified-p buffer)))
-        (apply denote-rewrite-front-matter path arguments)
+        (apply denote-rewrite-front-matter path :save-buffer (not had-unsaved-changes) arguments)
         (unless had-unsaved-changes
-            (with-current-buffer buffer
-                (basic-save-buffer))
             (unless (memq buffer buffers)
                 (kill-buffer buffer)))))

[mentalisttraceur]

Re:

There are many situations in which Emacs is not deleting buffers automatically (Dired, Magit, Org agenda, etc.). I do not know if there is a good reason for that.

I think there's several good reasons, most not applicable here (but it's not like I would be against a parameter to keep the buffers open unconditionally if someone wanted that):

1. Those things leave around buffers that you opened. They don't create and leave a bunch of persistent buffers that you never even saw. My wrapper above only automatically closes buffers if they weren't even open when you ran the rename - in other words, situations where you never even see the buffer open, because you just did the rename on the file under point in Dired or whatever.

2. Navigation. You can quickly find buffers you already opened.

   • I suspect this is part of why Dired does this: so you don't have to just navigate by Dired links and new calls to dired.

   • This is why I advise the help functions in my config to make a new help buffer for each topic (when I run describe-function on denote, I get a help buffer called *Help (function: denote)* and the main benefit is that I can then very quickly go to or search for any help page I've visited.

3. Persistence. You might have state you don't want to lose in the buffer, so you bury by default rather than killing.

   • Dired might have marks/etc. (Of course if this was the sole reason, they could kill by default and bury if there's marks.)

   • Magit might have some partially finished procedure. Similarly, my own Git interface has my quitting keys bound to quit-window without killing because if I still have a git command running in it, I don't want to kill it or lose it.

4. (historical reason) Efficiency. Creating buffers is cheap, but "expensive" relative to just reusing the buffer you already have. (Doesn't really matter with modern machines unless you're recreating buffers in a hot loop or something, but something like Dired hails from the 1970s/1980s when needlessly allocating a few thousand bytes, running an ls, and parsing+coloring ls output, all while the old almost identical buffer was being garbage collected, could actually be noticably expensive).

5. Invariants. Complex stateful packages might benefit from the simplicity or guarantees of having the same buffer persist in the background.

6. Review. Sometimes you want to review what you did or what happened.

   • In my Git interface, old commands are left in the buffer scrollback. So if you staged a hunk at some point, if you haven't yet killed the git add -p buffer for that repo or file, you can go back and find that you staged it, and when you did so. If a push had an error hours ago and you want to show it to someone, if you haven't killed the buffer that day you can go back in the git push buffer and see it again.

There's probably other reasons, but I think that covers almost all of them. And I don't think any of that applies to buffers of files only opened automatically in the background to do the front matter part of the rename, if they're also automatically saved.

[mentalisttraceur]

Actually, you could just add a :kill-buffer parameter!

Then I can simplify my wrapper down to

(let* ((buffer (find-buffer-visiting path))
       (unsaved-changes (when buffer
                           (refresh-modified-state buffer)
                           (buffer-modified-p buffer))))
    (denote-whatever
        ...
        :save-buffer (not unsaved-changes)
        :kill-buffer (not buffer)))

1. Simpler for you, no coupling to my code to refresh buffer's modified state. I think I even like that orthogonality better.
2. Still an improvement on my end too.
3. Kinda sucks that other users don't benefit like I do though... but I guess they should've thought about that before deciding to be someone other than me maybe we could toss a note in the docs about how to put these two pieces together.

[protesilaos]

Closing now that we have the new user option denote-kill-buffers by @jeanphilippegg.

[mentalisttraceur]

Nice! That code looks like it does exactly what I wanted/needed. Thank you @jeanphilippegg and @protesilaos !