[ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Eric Abrahamsen]

Hello all,

I've spent the past couple weeks organizing various bits of code into a
proper package, called Gnorb, which I'm billing as "Glue code between
Gnus, Org, and BBDB". The main point is to reduce friction between these
three packages, making it easier to sling around emails, TODOs,
attachments, and the like, and providing multiple views on information.

https://github.com/girzel/gnorb

Most of these bits fall under the category of "things you could have
written yourself", but taken together I've found that they really smooth
out my daily work flow. Some features:

- Whang attachments from Gnus messages onto Org headings, using org-attach.
- Automate the above as part of the org capture process
- Email contents of org subtree under point (prompt for export routine)
- Single-keystroke Org links or email citations of BBDB contacts
- Initiate search of emails from contacts in open BBDB buffer
- Initiate Org agenda tag search from BBDB buffer
- Inverse of the above: pop up a BBDB buffer alongside an Org tags search
- Treat headings as email-related TODOs, and handle them DWIM-style

See the README.org for more. Most of these are single-use small
snippets, but the last I've found particularly useful. A typical flow
would go like this: you have a capture template that looks like:

("r" "Reply" entry (file+headline "~/org/notes.org" "Emails")
 "** REPLY %a %?" :gnus-attachments t)

Use this template to capture from an email in the Gnus summary buffer.
You're prompted to attach the message attachments to the new heading,
and while you're there you decide to add BBDB links to people who should
also be in on the reply. You end up with this:

** REPLY [[gnus:link]] and also send to [[bbdb:bob]] and [[bbdb:jane]] :ATTACH:
   :PROPERTIES: (attachments and all that)

Then call `gnorb-org-handle-mail' on this headline in an Org or Agenda
buffer. A reply is started to the Gnus message, Bob and Jane are added
to the To header, and you're prompted to attach the attachments to the
outgoing message (presumably you've edited them). When the message is
sent you're returned to the original Org buffer and prompted to mark the
TODO as done. Next email!

The current version of this thing is "Works on My Computer (Beta)". I
would love bug reports, but would love feature requests even more! I'm
currently working on getting BBDB to store links to the last N messages
from any given contact. Also, how best to model email conversations
using TODO state-changes, log entries, and links.

I'm sure there's plenty more fun to be had, though.

Eric

[ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Eric Abrahamsen]

[this didn't seem to make it through the list hiccup yesterday, sending again]

Hello all,

I've spent the past couple weeks organizing various bits of code into a
proper package, called Gnorb, which I'm billing as "Glue code between
Gnus, Org, and BBDB". The main point is to reduce friction between these
three packages, making it easier to sling around emails, TODOs,
attachments, and the like, and providing multiple views on information.

https://github.com/girzel/gnorb

Most of these bits fall under the category of "things you could have
written yourself", but taken together I've found that they really smooth
out my daily work flow. Some features:

- Whang attachments from Gnus messages onto Org headings, using org-attach.
- Automate the above as part of the org capture process
- Email contents of org subtree under point (prompt for export routine)
- Single-keystroke Org links or email citations of BBDB contacts
- Initiate search of emails from contacts in open BBDB buffer
- Initiate Org agenda tag search from BBDB buffer
- Inverse of the above: pop up a BBDB buffer alongside an Org tags search
- Treat headings as email-related TODOs, and handle them DWIM-style

See the README.org for more. Most of these are single-use small
snippets, but the last I've found particularly useful. A typical flow
would go like this: you have a capture template that looks like:

("r" "Reply" entry (file+headline "~/org/notes.org" "Emails")
 "** REPLY %a %?" :gnus-attachments t)

Use this template to capture from an email in the Gnus summary buffer.
You're prompted to attach the message attachments to the new heading,
and while you're there you decide to add BBDB links to people who should
also be in on the reply. You end up with this:

** REPLY [[gnus:link]] and also send to [[bbdb:bob]] and [[bbdb:jane]] :ATTACH:
   :PROPERTIES: (attachments and all that)

Then call `gnorb-org-handle-mail' on this headline in an Org or Agenda
buffer. A reply is started to the Gnus message, Bob and Jane are added
to the To header, and you're prompted to attach the attachments to the
outgoing message (presumably you've edited them). When the message is
sent you're returned to the original Org buffer and prompted to mark the
TODO as done. Next email!

The current version of this thing is "Works on My Computer (Beta)". I
would love bug reports, but would love feature requests even more! I'm
currently working on getting BBDB to store links to the last N messages
from any given contact. Also, how best to model email conversations
using TODO state-changes, log entries, and links.

I'm sure there's plenty more fun to be had, though.

Eric

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Thomas S. Dye]

Aloha Eric,

Perfect timing! 

OS X Mavericks broke the workflow I'd developed with Contacts and I've
been looking to jettison the only Mac App I ever really used.  My
earlier experiments with bbdb generated lots of "friction".  I'm looking
forward to the time needed to explore gnorb.

Thanks,
Tom

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> [this didn't seem to make it through the list hiccup yesterday, sending again]
>
> Hello all,
>
> I've spent the past couple weeks organizing various bits of code into a
> proper package, called Gnorb, which I'm billing as "Glue code between
> Gnus, Org, and BBDB". The main point is to reduce friction between these
> three packages, making it easier to sling around emails, TODOs,
> attachments, and the like, and providing multiple views on information.
>
> https://github.com/girzel/gnorb
>
> Most of these bits fall under the category of "things you could have
> written yourself", but taken together I've found that they really smooth
> out my daily work flow. Some features:
>
> - Whang attachments from Gnus messages onto Org headings, using org-attach.
> - Automate the above as part of the org capture process
> - Email contents of org subtree under point (prompt for export routine)
> - Single-keystroke Org links or email citations of BBDB contacts
> - Initiate search of emails from contacts in open BBDB buffer
> - Initiate Org agenda tag search from BBDB buffer
> - Inverse of the above: pop up a BBDB buffer alongside an Org tags search
> - Treat headings as email-related TODOs, and handle them DWIM-style
>
> See the README.org for more. Most of these are single-use small
> snippets, but the last I've found particularly useful. A typical flow
> would go like this: you have a capture template that looks like:
>
> ("r" "Reply" entry (file+headline "~/org/notes.org" "Emails")
>  "** REPLY %a %?" :gnus-attachments t)
>
> Use this template to capture from an email in the Gnus summary buffer.
> You're prompted to attach the message attachments to the new heading,
> and while you're there you decide to add BBDB links to people who should
> also be in on the reply. You end up with this:
>
> ** REPLY [[gnus:link]] and also send to [[bbdb:bob]] and [[bbdb:jane]] :ATTACH:
>    :PROPERTIES: (attachments and all that)
>
> Then call `gnorb-org-handle-mail' on this headline in an Org or Agenda
> buffer. A reply is started to the Gnus message, Bob and Jane are added
> to the To header, and you're prompted to attach the attachments to the
> outgoing message (presumably you've edited them). When the message is
> sent you're returned to the original Org buffer and prompted to mark the
> TODO as done. Next email!
>
> The current version of this thing is "Works on My Computer (Beta)". I
> would love bug reports, but would love feature requests even more! I'm
> currently working on getting BBDB to store links to the last N messages
> from any given contact. Also, how best to model email conversations
> using TODO state-changes, log entries, and links.
>
> I'm sure there's plenty more fun to be had, though.
>
> Eric
>
>
>

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Eric Abrahamsen]

tsd@tsdye.com (Thomas S. Dye) writes:

> Aloha Eric,
>
> Perfect timing! 
>
> OS X Mavericks broke the workflow I'd developed with Contacts and I've
> been looking to jettison the only Mac App I ever really used.  My
> earlier experiments with bbdb generated lots of "friction".  I'm looking
> forward to the time needed to explore gnorb.

Let me know how it works out! Someone wrote to say I hadn't mentioned
package compatibility. I run the dev versions of all three of Gnus, Org,
and BBDB, which means BBDB 3! I'll make sure it works with the most
recent stable releases of those packages, though.

I know a lot of people still haven't moved to from BBDB 2 to 3, and it's
past time! I'd be happy to provide pointers if anyone's looking to take
the plunge.

Eric

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Alan Schmitt]

Hello Eric,

On 2014-05-07 03:23, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've spent the past couple weeks organizing various bits of code into a
> proper package, called Gnorb, which I'm billing as "Glue code between
> Gnus, Org, and BBDB". The main point is to reduce friction between these
> three packages, making it easier to sling around emails, TODOs,
> attachments, and the like, and providing multiple views on information.
>
> https://github.com/girzel/gnorb

I've read through the README and it looks very nice. I've installed
a few functions in my init file to learn to work with them, but in the
meantime I have a few questions.

> - Treat headings as email-related TODOs, and handle them DWIM-style

I usually avoid putting links in my tasks. For instance, the task
I generated from your email to the list looks like this:

  **** TODO Reply to this when I will have tried gnorb		       :@fun:
   [2014-05-07 Wed 11:25]
  
  [[gnus:lists.orgmode#87r446bcut.fsf@ericabrahamsen.net][Email from Eric Abrahamsen: {O} {ANN} Gnorb: Glue code bet (Wed, 07 May 2014 09:23:54 +0800)]]

Would it be difficult to handle such emails when the link is inside the
TODO, instead of in the heading?

I can of course change my capture format. I'm just wondering why you
prefer to have the link in the mail.

Regarding your daily flow, it seems that bbdb is very central to how you
work. Do you simply use it as a backend linked to the agenda view, or do
you often navigate your bbdb records? If you ever have the time to write
or do a screencast of your work flow, I would be most interested in
learning more about it.

Thanks again,

Alan

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Eric Abrahamsen]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> I usually avoid putting links in my tasks. For instance, the task
> I generated from your email to the list looks like this:
>
>   **** TODO Reply to this when I will have tried gnorb		       :@fun:
>    [2014-05-07 Wed 11:25]
>   
>   [[gnus:lists.orgmode#87r446bcut.fsf@ericabrahamsen.net][Email from Eric Abrahamsen: {O} {ANN} Gnorb: Glue code bet (Wed, 07 May 2014 09:23:54 +0800)]]
>
> Would it be difficult to handle such emails when the link is inside the
> TODO, instead of in the heading?

Not at all! In fact, the next tweak for this is an option allowing you
to expand the scope of the scan for links. I'll probably default it to
checking the first paragraph of the entry text, but you'll be able to go
all the way to 'subtree.

> I can of course change my capture format. I'm just wondering why you
> prefer to have the link in the mail.

Heck no I don't want you to change your format! I'm very sensitive to
issues of mental overhead and workflow/file-format lock-in with this
package. The whole point is to help you think *less*, not more, and I
don't want people having to write a bunch of code or change their files
to make it work. Ideally everything would just happen by calling
functions, and it will be the responsibility of those functions to
look at your TODO structure and do the right thing.

Actually, let me hijack this for a second and ask a more general
question. I announced the package at this stage, and not when it was
more complete, because the next thing to do is flesh out its email
handling capabilities, and I'd love to get feedback on that first.

I'm writing two more functions to complement `gnorb-org-handle-mail'. In
the end there will be three:

1. A function that says "make an Org todo out of the email I'm sending
now" (to keep track of conversations that need following-up).

2. A function that says "this email I just received is relevant to some
Org heading, and should trigger a TODO state-change or a note on that
heading". It will be able to suggest the correct heading.

3. A function that says "send an email by reading the current Org
heading and doing what I what". That's `gnorb-org-handle-mail'.

Everything else just depends on how you've set up your capture
templates, and how you like to structure your mail-related TODOs. I
don't want to enforce anything else, but I want those three functions to
be good at guessing how you do things, and I'll provide user options to
help them guess correctly. In particular, how `gnorb-org-handle-mail'
interprets the heading under point is important.

I just said I don't want to enforce anything, but one thing I want to
strongly *encourage* is the use of the LOGBOOK drawer to keep track of
email threads/conversations. By using `org-log-into-drawer', the "@"
cookie for TODO keywords, and `org-add-note', you can keep track of all
the important developments in an email conversation, using links to
specific messages. I do a fair amount of business negotiation via email,
and this is pretty crucial for me. I end up with headings looking like
this:

* WAIT Sort out copyright agreement with [[bbdb:johnbob]]
  :LOGBOOK:
  - State "WAIT"      from "REPLY"       [2014-05-08 Sat 09:45] \\
    I told him that might work, but we'd need to limit the language zone
  - State "REPLY"      from "WAIT"       [2014-05-07 Sat 15:09] \\
    He [[gnus:link][wrote back]] and proposed 14% royalties
  - Note taken on [2014-05-06 Sat 12:56] \\
    Mattbob [[gnus:link][wrote]] and reminded me to ask about digital rights
  - State "WAIT"       from "EMAIL"       [2014-05-04 Fri 13:25] \\
    Wrote to Johnbob and proposed terms.
  :END:
  :PROPERTIES
  :GNORB_MSG_IDS: 46bcut.fsf@ericabrahamsen.net jj8m.fsf@johnbob.fr
  :END:

I'd like gnorb to do all the complicated bits for you. You should just
be able to call whichever of the three functions is relevant, and then
gnorb will put you in the right place, with a link loaded, to take a
note or annotate a state-change. In the above example,
`gnorb-org-handle-mail' should see that there are gnus links in the
LOGBOOK, and start a reply to the most recent one.

If you only ever use email TODOs as a one-off send-or-reply reminder,
then everything is much simpler, of course.

So that's what I'm thinking. The code is half-done. If anyone has
any requests or objections or demands, let's have them!

> Regarding your daily flow, it seems that bbdb is very central to how you
> work. Do you simply use it as a backend linked to the agenda view, or do
> you often navigate your bbdb records? If you ever have the time to write
> or do a screencast of your work flow, I would be most interested in
> learning more about it.

That would be a very dull screencast :)

I use the BBDB a lot because when I think "now I have to do XYZ", that
often starts with thinking of the people involved with the task. So I go
to the record in BBDB, and then call `gnorb-bbdb-mail-search' to see
messages from them, or `gnorb-bbdb-tag-agenda' to see Org todos related
to them. When I do a tags search in Org, `gnorb-org-popup-bbdb' shows me
relevant contacts. I'm going to expand this so that org-occur also does
a generalized BBDB search, and pops up the relevant buffer. The more
information that's available using BBDB as a starting point, the more
you'll use BBDB, of course!

All this depends on you giving your BBDB records an "org-tag" field,
which is pretty much the only file-format buy-in that Gnorb asks of you
(I hope it remains the only one).

Roland Winkler just made changes to the BBDB codebase that will allow us
to store links to recently-received messages as an Xfield on each
record, and I think that will be awesome (I happily stole this idea from
org-contacts). It will also depend on people running the development
version of BBDB, which will mean it will have a userbase of about four
:)

Sorry, this was a bit of a brain-dump. I think the issue of how people
use email is fascinating, though, and I plan to look at software like
Google Tasks or whatever, to collect some ideas. I'd love input from
anyone with opinions!

Eric

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Alan Schmitt]

On 2014-05-10 12:32, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> I usually avoid putting links in my tasks. For instance, the task
>> I generated from your email to the list looks like this:
>>
>>   **** TODO Reply to this when I will have tried gnorb		       :@fun:
>>    [2014-05-07 Wed 11:25]
>>   
>>   [[gnus:lists.orgmode#87r446bcut.fsf@ericabrahamsen.net][Email from Eric Abrahamsen: {O} {ANN} Gnorb: Glue code bet (Wed, 07 May 2014 09:23:54 +0800)]]
>>
>> Would it be difficult to handle such emails when the link is inside the
>> TODO, instead of in the heading?
>
> Not at all! In fact, the next tweak for this is an option allowing you
> to expand the scope of the scan for links. I'll probably default it to
> checking the first paragraph of the entry text, but you'll be able to go
> all the way to 'subtree.

That would be great indeed.

>> I can of course change my capture format. I'm just wondering why you
>> prefer to have the link in the mail.
>
> Heck no I don't want you to change your format! I'm very sensitive to
> issues of mental overhead and workflow/file-format lock-in with this
> package. The whole point is to help you think *less*, not more, and I
> don't want people having to write a bunch of code or change their files
> to make it work. Ideally everything would just happen by calling
> functions, and it will be the responsibility of those functions to
> look at your TODO structure and do the right thing.

A more robust alternative than looking at the note's text could be to
have a property with the link to the mail. (Later) I see that your
LOGBOOK example uses a property to track the message. Could this be
considered as the link? And I also see you only record the message
id. How do you get to the right folder using it?

> Actually, let me hijack this for a second and ask a more general
> question. I announced the package at this stage, and not when it was
> more complete, because the next thing to do is flesh out its email
> handling capabilities, and I'd love to get feedback on that first.

For comparison, my email handling workflow is very simple. I have
a "capture with link" template that looks like this, that I can use
from inside gnus:

#+begin_src emacs-lisp
          ("T" "todo with link" entry (file "refile-orgx.org")
           "* TODO %?\n %U\n\n%a")
#+end_src

I'm also making sure the link text has enough information to find the
mail again if it's moved (I would love a more robust linking system,
maybe based on notmuch, but this works well enough for the moment). To
do so, I set `org-email-link-description-format' to "Email %c: %.30s (%d)".

To follow a link, I don't simply click on it as it usually breaks my
carefully crafted layout for my agenda and todo files. So I have a very
simple function that creates a frame to display the link:

#+begin_src emacs-lisp
  (defun as/copy-link-and-open-in-new-frame ()
    (interactive)
    "Copies the next link found and opens it in a new frame"
    (org-next-link)
    (let ((link (org-element-property :raw-link (org-element-link-parser))))
      (make-frame '((name . "follow-link")))
      (select-frame-by-name "follow-link")
      (org-open-link-from-string link)))
#+end_src

This setup is why I'm so interested in gnorb: it's too much manual
manipulation and friction.

> I'm writing two more functions to complement `gnorb-org-handle-mail'. In
> the end there will be three:
>
> 1. A function that says "make an Org todo out of the email I'm sending
> now" (to keep track of conversations that need following-up).
>
> 2. A function that says "this email I just received is relevant to some
> Org heading, and should trigger a TODO state-change or a note on that
> heading". It will be able to suggest the correct heading.
>
> 3. A function that says "send an email by reading the current Org
> heading and doing what I what". That's `gnorb-org-handle-mail'.

These three functions would be most useful indeed.

> I just said I don't want to enforce anything, but one thing I want to
> strongly *encourage* is the use of the LOGBOOK drawer to keep track of
> email threads/conversations. By using `org-log-into-drawer', the "@"
> cookie for TODO keywords, and `org-add-note', you can keep track of all
> the important developments in an email conversation, using links to
> specific messages. I do a fair amount of business negotiation via email,
> and this is pretty crucial for me. I end up with headings looking like
> this:
>
> * WAIT Sort out copyright agreement with [[bbdb:johnbob]]
>   :LOGBOOK:
>   - State "WAIT"      from "REPLY"       [2014-05-08 Sat 09:45] \\
>     I told him that might work, but we'd need to limit the language zone
>   - State "REPLY"      from "WAIT"       [2014-05-07 Sat 15:09] \\
>     He [[gnus:link][wrote back]] and proposed 14% royalties
>   - Note taken on [2014-05-06 Sat 12:56] \\
>     Mattbob [[gnus:link][wrote]] and reminded me to ask about digital rights
>   - State "WAIT"       from "EMAIL"       [2014-05-04 Fri 13:25] \\
>     Wrote to Johnbob and proposed terms.
>   :END:
>   :PROPERTIES
>   :GNORB_MSG_IDS: 46bcut.fsf@ericabrahamsen.net jj8m.fsf@johnbob.fr
>   :END:
>
> I'd like gnorb to do all the complicated bits for you. You should just
> be able to call whichever of the three functions is relevant, and then
> gnorb will put you in the right place, with a link loaded, to take a
> note or annotate a state-change. In the above example,
> `gnorb-org-handle-mail' should see that there are gnus links in the
> LOGBOOK, and start a reply to the most recent one.

I know how to record state changes in the logbook (in the definition of
`org-todo-keywords'), but I don't know how one adds notes. Do you do it
by hand?

> I use the BBDB a lot because when I think "now I have to do XYZ", that
> often starts with thinking of the people involved with the task. So I go
> to the record in BBDB, and then call `gnorb-bbdb-mail-search' to see
> messages from them, or `gnorb-bbdb-tag-agenda' to see Org todos related
> to them. When I do a tags search in Org, `gnorb-org-popup-bbdb' shows me
> relevant contacts. I'm going to expand this so that org-occur also does
> a generalized BBDB search, and pops up the relevant buffer. The more
> information that's available using BBDB as a starting point, the more
> you'll use BBDB, of course!
>
> All this depends on you giving your BBDB records an "org-tag" field,
> which is pretty much the only file-format buy-in that Gnorb asks of you
> (I hope it remains the only one).

Basic question: how does one add such a tag? I'm a very very basic user
of bbdb, in the sense that I only use it to expand addresses when
writing messages. I know it can do much more, but I don't know how.

> Roland Winkler just made changes to the BBDB codebase that will allow us
> to store links to recently-received messages as an Xfield on each
> record, and I think that will be awesome (I happily stole this idea from
> org-contacts). It will also depend on people running the development
> version of BBDB, which will mean it will have a userbase of about four
> :)

Such information would be useful, indeed. But you already provide
a similar function with gnorb-bbdb-mail-search, don't you?

> Sorry, this was a bit of a brain-dump. I think the issue of how people
> use email is fascinating, though, and I plan to look at software like
> Google Tasks or whatever, to collect some ideas. I'd love input from
> anyone with opinions!

I also find the topic very interesting. Thanks again for your work!

Alan

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Eric Abrahamsen]

On 05/10/14 15:34 PM, Alan Schmitt wrote:
> On 2014-05-10 12:32, Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Alan Schmitt <alan.schmitt@polytechnique.org> writes:

[...]

> A more robust alternative than looking at the note's text could be to
> have a property with the link to the mail. (Later) I see that your
> LOGBOOK example uses a property to track the message. Could this be
> considered as the link? And I also see you only record the message
> id. How do you get to the right folder using it?

But the link that should be replied to will change as the conversation
progresses, that's why we're still scanning for links. But you're right,
it might be a little safer to put the newest relevant message link in a
property.

Right now (this code hasn't been pushed yet), the GNORB_MSG_IDS property
is used in the *other* direction: when you receive a message that might
be relevant to a TODO (ie the second of the three mail functions I
mentioned), the GNORB_MSG_IDS property is used to suggest the relevant
TODO. We look at the IDs mentioned the References and In-Reply-To
headers of the incoming mail, if any of those IDs appear in the
GNORB_MSG_IDS property of a TODO, that TODO is suggested for
state-change/completion. This doesn't do anything automatically, it's
just used to suggest a likely default.

[...]

> To follow a link, I don't simply click on it as it usually breaks my
> carefully crafted layout for my agenda and todo files. So I have a very
> simple function that creates a frame to display the link:
>
> #+begin_src emacs-lisp
>   (defun as/copy-link-and-open-in-new-frame ()
>     (interactive)
>     "Copies the next link found and opens it in a new frame"
>     (org-next-link)
>     (let ((link (org-element-property :raw-link (org-element-link-parser))))
>       (make-frame '((name . "follow-link")))
>       (select-frame-by-name "follow-link")
>       (org-open-link-from-string link)))
> #+end_src
>
> This setup is why I'm so interested in gnorb: it's too much manual
> manipulation and friction.

Yup, that looks like a pain. Right now gnorb saves window configuration
when you handle a mail TODO, and restores it when the message is sent.
But there are probably a lot of contingencies I haven't thought of, so
it would be great to see how it works for you.

Actually, the very first motivation for starting to work on these
functions was annoyance at not being able to return properly from
following a gnus link.

[...]

>> I'd like gnorb to do all the complicated bits for you. You should just
>> be able to call whichever of the three functions is relevant, and then
>> gnorb will put you in the right place, with a link loaded, to take a
>> note or annotate a state-change. In the above example,
>> `gnorb-org-handle-mail' should see that there are gnus links in the
>> LOGBOOK, and start a reply to the most recent one.
>
> I know how to record state changes in the logbook (in the definition of
> `org-todo-keywords'), but I don't know how one adds notes. Do you do it
> by hand?

Gnorb will give you the choice of triggering state change, or adding a
note (with a customizable default, and a prefix arg to get the inverse).
Usually, you can add a note manually with C-c C-z. A note won't affect
`gnorb-org-handle-mail's behavior, it's just there for your information.
In both cases, gnorb will leave you at the note message buffer, where
you can insert a link or type whatever comments you want.

[...]

>> All this depends on you giving your BBDB records an "org-tag" field,
>> which is pretty much the only file-format buy-in that Gnorb asks of you
>> (I hope it remains the only one).
>
> Basic question: how does one add such a tag? I'm a very very basic user
> of bbdb, in the sense that I only use it to expand addresses when
> writing messages. I know it can do much more, but I don't know how.

Sure: just hit "i" on a record, and it will prompt you to insert a
field. The first time you use org-tags it will ask you to confirm you
want to create a new field type; after that it will provide completion.

>> Roland Winkler just made changes to the BBDB codebase that will allow us
>> to store links to recently-received messages as an Xfield on each
>> record, and I think that will be awesome (I happily stole this idea from
>> org-contacts). It will also depend on people running the development
>> version of BBDB, which will mean it will have a userbase of about four
>> :)
>
> Such information would be useful, indeed. But you already provide
> a similar function with gnorb-bbdb-mail-search, don't you?

I guess, yes, but redundancy is good!

>> Sorry, this was a bit of a brain-dump. I think the issue of how people
>> use email is fascinating, though, and I plan to look at software like
>> Google Tasks or whatever, to collect some ideas. I'd love input from
>> anyone with opinions!
>
> I also find the topic very interesting. Thanks again for your work!
>
> Alan

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Alan Schmitt]

On 2014-05-10 18:36, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Right now (this code hasn't been pushed yet), the GNORB_MSG_IDS property
> is used in the *other* direction: when you receive a message that might
> be relevant to a TODO (ie the second of the three mail functions I
> mentioned), the GNORB_MSG_IDS property is used to suggest the relevant
> TODO. We look at the IDs mentioned the References and In-Reply-To
> headers of the incoming mail, if any of those IDs appear in the
> GNORB_MSG_IDS property of a TODO, that TODO is suggested for
> state-change/completion. This doesn't do anything automatically, it's
> just used to suggest a likely default.

Ah, very nice.

I still think basing links on message ids is the most robust. I just
gave a quick try and I can fairly easily find a message from an id
through notmuch on the command line, or using an interactive
search. I had a quick look at notmuch.el but I don't see a way to use it
without a notmuch buffer, though.

> Actually, the very first motivation for starting to work on these
> functions was annoyance at not being able to return properly from
> following a gnus link.

That's motivation enough!

>> I know how to record state changes in the logbook (in the definition of
>> `org-todo-keywords'), but I don't know how one adds notes. Do you do it
>> by hand?
>
> Gnorb will give you the choice of triggering state change, or adding a
> note (with a customizable default, and a prefix arg to get the inverse).
> Usually, you can add a note manually with C-c C-z. A note won't affect
> `gnorb-org-handle-mail's behavior, it's just there for your information.
> In both cases, gnorb will leave you at the note message buffer, where
> you can insert a link or type whatever comments you want.

Good to know, thanks.

>> Basic question: how does one add such a tag? I'm a very very basic user
>> of bbdb, in the sense that I only use it to expand addresses when
>> writing messages. I know it can do much more, but I don't know how.
>
> Sure: just hit "i" on a record, and it will prompt you to insert a
> field. The first time you use org-tags it will ask you to confirm you
> want to create a new field type; after that it will provide
> completion.

I'll give it a try.

Thanks again,

Alan

Re: [ANN] Gnorb: Glue code between Gnus, Org, and BBDB

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'm writing two more functions to complement `gnorb-org-handle-mail'. In
> the end there will be three:
>
> 1. A function that says "make an Org todo out of the email I'm sending
> now" (to keep track of conversations that need following-up).
>
> 2. A function that says "this email I just received is relevant to some
> Org heading, and should trigger a TODO state-change or a note on that
> heading". It will be able to suggest the correct heading.
>
> 3. A function that says "send an email by reading the current Org
> heading and doing what I what". That's `gnorb-org-handle-mail'.
>
> Everything else just depends on how you've set up your capture
> templates, and how you like to structure your mail-related TODOs. I
> don't want to enforce anything else, but I want those three functions to
> be good at guessing how you do things, and I'll provide user options to
> help them guess correctly. In particular, how `gnorb-org-handle-mail'
> interprets the heading under point is important.

Okay, the above is basically up and working, modulo bugs. In an OCD fit
I had to rename a couple of functions, I'm going to coder hell, I know
it. gnorb-gnus-outgoing-make-todo is now gnorb-gnus-outgoing-do-todo,
and gnorb-gnus-message-trigger-todo is now gnorb-gnus-incoming-do-todo.

The readme at https://github.com/girzel/gnorb has a general description
of how one might use this for email tracking.

E