[elpa] externals/gnorb de4b0e8 145/449: Associate outgoing messages with arbitrary headings

[Stefan Monnier]

branch: externals/gnorb
commit de4b0e8aeccba313b7068dc626723a58045c0c9a
Author: Eric Abrahamsen <eric@ericabrahamsen.net>
Commit: Eric Abrahamsen <eric@ericabrahamsen.net>

    Associate outgoing messages with arbitrary headings
    
    Previously, calling gnorb-gnus-outgoing-do-todo on messages under
    composition would automatically either make a new TODO, or trigger state
    change on an existing todo. With a prefix arg, now allow the user to
    choose an arbitrary heading that this message should be associated with.
    
    lisp/gnorb-gnus.el: (gnorb-gnus-outgoing-do-todo) prefix arg prompts for
                    new heading to associate message with.
---
 lisp/gnorb-gnus.el | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/lisp/gnorb-gnus.el b/lisp/gnorb-gnus.el
index d70ed1d..ef911ed 100644
--- a/lisp/gnorb-gnus.el
+++ b/lisp/gnorb-gnus.el
@@ -282,6 +282,10 @@ message that isn't referenced by any TODOs, a new TODO 
will be
 created. If it references an existing TODO, you'll be prompted to
 trigger a state-change or a note on that TODO.
 
+Otherwise, you can call it with a prefix arg to associate the
+sending/sent message with an existing Org subtree, and trigger an
+action on that subtree.
+
 If a new todo is made, it needs a capture template: set
 `gnorb-gnus-new-todo-capture-key' to the string key for the
 appropriate capture template. If you're using a gnus-based
@@ -294,14 +298,27 @@ manual (org) Template expansion section). If you don't, 
then the
 the outgoing message will still be available -- nothing else will
 work."
   (interactive "P")
-  (let (header-ids ref-ids rel-headings gnorb-org-window-conf
-                  reply-id reply-group)
+  (let ((org-refile-targets gnorb-gnus-trigger-refile-targets)
+       header-ids ref-ids rel-headings gnorb-org-window-conf
+       reply-id reply-group)
+    (when arg
+      (setq rel-headings
+           (org-refile-get-location "Trigger action on" nil t))
+      (setq rel-headings
+           (list (list (save-window-excursion
+                         (find-file (nth 1 rel-headings))
+                         (goto-char (nth 3 rel-headings))
+                         (org-id-get-create))))))
     (if (not (eq major-mode 'message-mode))
        ;; The message is already sent, so we're relying on whatever was
        ;; stored into `gnorb-gnus-sending-message-info'.
-       (progn
+       (if arg
+           (progn
+             (push (caar rel-headings) gnorb-message-org-ids)
+             (gnorb-org-restore-after-send))
          (setq ref-ids (plist-get gnorb-gnus-sending-message-info :refs))
-         (if ref-ids ;; the message might be relevant to some TODO
+         (if ref-ids
+             ;; the message might be relevant to some TODO
              ;; heading(s). But if there had been org-id
              ;; headers, they would already have been
              ;; handled when the message was sent.
@@ -326,7 +343,11 @@ work."
        (widen)
        (message-narrow-to-headers-or-head)
        (setq header-ids (mail-fetch-field gnorb-mail-header nil nil t))
-       (setq ref-ids (mail-fetch-field "References" t))
+       ;; With a prefix arg we do not check references, because the
+       ;; whole point is to add new references. We still want to know
+       ;; what org id headers are present, though, so we don't add
+       ;; duplicates.
+       (setq ref-ids (unless arg (mail-fetch-field "References" t)))
        (setq reply-group (car-safe (read (mail-fetch-field "X-Draft-From" t))))
        ;; when it's a reply, store a link to the reply just in case.
        ;; This is pretty embarrassing -- we follow a link just to