emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] [PATCH] Save buffer in org-capture-refile


From: Andrew Burgess
Subject: [O] [PATCH] Save buffer in org-capture-refile
Date: Wed, 5 Sep 2018 11:32:45 +0100

I notice that if a capture template sets ':kill-buffer t', and I use
org-capture-refile to refile into a different file then I don't get
the result I expect.

Let me give an example, here's my setup:

  $ mkdir ~/tmp
  $ cd ~/tmp
  $ echo "* loc1/tasks" > loc1.org
  $ echo "* inbox/tasks" > inbox.org
  $ cat test.el
  (setq org-capture-templates
        '(("t" "TASK that needs completing" entry
           (file+headline "~/tmp/inbox.org" "inbox/tasks")
           "** TODO %?"
           :prepend t :kill-buffer t)))
  (setq org-refile-targets (quote (("~/tmp/loc1.org" :maxlevel . 2))))
  $ emacs -Q -l test.el

Now in emacs:

  org-capture             # Start a capture
  t                       # Select the template 't'
  AAAAAA                  # Fill in a task title
  org-capture-refile      # Start refiling
  l<TAB>                  # Select refile location, should complete to
                          # 'loc1/tasks (loc1.org)'

At this point you should see the message:

  Buffer inbox.org modified; kill anyway? (yes or no)

Neither answer gets you the result you want (I think).

If you choose 'yes', then quit emacs (saving buffers as you go[1])
you'll find that task 'AAAAAA' is now in both inbox.org and loc1.org.

If you choose 'no', then quit emacs (saving buffers as you go) you'll
find that the task has moved out of inbox.org into loc1.org, but,
clearly the requested ':kill-buffer t' wasn't respected.

The problem is that org-capture-refile calls org-capture-finalize, but
suppresses the call to kill-buffer in org-capture-finalize, instead
performing that call itself.  However, org-capture-finalize calls
save-buffer, before calling kill-buffer, org-capture-refile doesn't.

If I add a call to save-buffer into org-capture-refile in a similar
fashion to the call in org-capture-finalize, then I get the behaviour
I expect.

My employer Embecosm should already have a copyright assignment on
file for emacs.

[1] I think that there's an argument to be made that, if the refile
destination is opened just for the purpose of refiling this item, and
':kill-buffer t' is in place, then org-capture-refile should probably
kill the refile destination too.  However, though related, I think
that's a separate issue.

Thanks,
Andrew

---

In org-capture-finalize if the capture template requests that the
capture buffer be killed, we first save the buffer, and then kill it.

However, org-capture-refile suppresses the killing of the buffer in
org-capture-finalize and performs the call to kill-buffer itself,
however, it doesn't save the buffer.  The result is that the user is
prompted with a "buffer has been modified, kill anyway?" message.  At
this point answering yes will leave the item being refiled in both the
source and destination locations, while answering no will leave the
buffer around (which isn't what the user wanted).

The solution is to call save-buffer in org-capture-refile, just like
it is called in org-capture-finalize.
---
 lisp/org-capture.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 993526fcb..33f1af147 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -877,7 +877,9 @@ for `entry'-type templates"))
              (org-with-wide-buffer
               (goto-char pos)
               (call-interactively 'org-refile))))
-         (when kill-buffer (kill-buffer base))
+         (when kill-buffer
+           (with-current-buffer base (save-buffer))
+           (kill-buffer base))
          (when jump-to-captured (org-capture-goto-last-stored)))
       (set-marker pos nil))))
 
-- 
2.14.4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]