emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Collaborative Team Project Management with Orgmode?


From: John Kitchin
Subject: Re: [O] Collaborative Team Project Management with Orgmode?
Date: Wed, 26 Aug 2015 06:59:31 -0400

Eric Abrahamsen writes:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.orgmode as well.
>
> John Kitchin <address@hidden> writes:
>
>>>
>>> Let's see... the org-contacts vs BBDB issue isn't a big deal, since
>>> Gnorb doesn't actually do all that much with contacts right now. I'd be
>>> happy to add tweaks to it to make it more org-contacts friendly.
>>>
>>> Email tracking is a bigger issue. Gnorb uses the Gnus registry to track
>>> correspondences between messages and headlines, and obviously none of
>>> that would work with mu4e.
>>>
>>> Earlier versions did tracking by storing message ids as a property on a
>>> headline. I suppose I could go back to doing that in a mu4e-specific
>>> library.
>>
>> Message id tracking is likely the way to do it in mu4e. mu4e links seem
>> to store this for links.
>>
>> [[mu4e:msgid:address@hidden
>
> Yup, I think most of the MUA links end up looking something like that.
> Message IDs are the one constant across MUAs and (most) mail sources, so
> everything in Gnorb is keyed to that.

It is pretty easy to get these from a message. I use this variable in a
send callback function:

(setq *email-message-id*
        (concat
         "mu4e:msgid:"
         ;; borrowed from 
https://github.com/girzel/gnorb/blob/master/gnorb-utils.el#L137
         (replace-regexp-in-string
          "\\(\\`<\\|>\\'\\)" "" (mail-fetch-field "Message-ID"))))

and then later use
(org-set-property "Message-ID" *email-message-id*)

and I get a clickable link in the property that will go back to the
message (after mu indexes again for freshly sent emails).
>
>>>
>>> To me, the most useful thing about message tracking isn't the
>>> identification and hinting of incoming emails. The two most useful
>>> things (I think) are:
>>>
>>> 1. Taking a message and saying "this message should trigger a state
>>>    change on that Org heading there"
>>> 2. Seeing all messages associated with a heading in their own virtual
>>>    "mailbox"
>>>
>>> Number one shouldn't be too difficult to implement for mu4e, as it would
>>> mostly rely on Org's own mu4e support. Number two would be nearly
>>> impossible, or at least impractical given my lack of familiarity with
>>> mu4e.
>>
>> I am still learning many things about emails. mu4e has pretty powerful
>> search capability via the underlying Xapian database.
>
> Well, on second thought, maybe it wouldn't need to be that hard, then.
> The Org heading would have its list of msg-ids, and if mu4e search has
> an easy way of saying "search for all messages whose IDs are in this
> list", then that it would be quite easy. Much easier than in Gnus, I
> have to say! If that search works across mail accounts and folders, then
> Gnorb wouldn't even have to care about messages being moved between
> folders, which is one of the main uses of the registry.
This seems to do what you describe. When I run it, I get an mu4e buffer
with those two messages in it. Basically you just create a mu query.

#+BEGIN_SRC emacs-lisp
(let ((ids '("address@hidden"
             "address@hidden") ))
  (mu4e-headers-search
   (mapconcat
    (lambda (id)
      (concat "msgid:" id))
    ids
    " or ")))
#+END_SRC

>
>>>
>>> Another thing I find hugely useful is automatically transferring files
>>> attached to incoming messages to Org headings (via org-attach).
>>> Presumably mu4e has a way of getting at the attachments on a message, so
>>> in theory this wouldn't be that hard, either.
>>
>> This sounds pretty interesting. I have never gotten that into
>> attachments, but this might change my mind. There are functions in mu4e
>> to view and save attachments, so this might not be hard.
>
> Much of my work involves throwing attachments around (or rather,
> receiving attachments and sending back plain text whenever possible),
> so this is pretty crucial for me. While org-attach is very sound, I
> found its surface-layer interface a bit cumbersome, and this makes it a
> lot easier to use.

Me too ;) I just have not progressed to org-attach yet. I usually have
to edit the attachments. How easy is it to reattach them to send back?

>
>> I am pretty interested in pursuing this, but am pretty busy for a while
>> so progress on my end will be slow ;(
>
> Mine as well, ha!
>
> BTW, mu4e still uses message mode for composition and sending, right?

yes.

>
>>> Anyway, those are some thoughts on the issue. If you all had some
>>> particular feature where you'd like mu4e support, let me know and I can
>>> take a stab at it.
>>>
>>> Eric
>>>
>>>> On Sun, Aug 23, 2015 at 12:39 PM, Eric Abrahamsen
>>>> <address@hidden> wrote:
>>>>
>>>>
>>>>     John Kitchin <address@hidden> writes:
>>>>
>>>>     > unless those services have some kind of API, and you have the
>>>>     desire to
>>>>     > implement it in emacs, you might be out of luck.
>>>>     >
>>>>     > I am trying to figure out a way to do collaborative work via
>>>>     email,
>>>>     > where I am the project coordinator. The idea is to use my
>>>>     email.el code
>>>>     > to send headlines to people I need information or action from,
>>>>     and then
>>>>     > to have them reply to the email. Then, I would have some easy
>>>>     way to get
>>>>     > information out of the reply back to the heading (e.g. TODO
>>>>     state
>>>>     > change, info etc...). Probably I would embed some org-id link in
>>>>     the email,
>>>>     > and "train" the users not to delete it. This is only a
>>>>     half-baked idea
>>>>     > so far.
>>>>     >
>>>>     > It would integrate org-contacts, mu4e, and org-mode in my setup.
>>>>
>>>>     Sounds exactly like Gnorb! Except org-contacts instead of BBDB,
>>>>     and mu4e
>>>>     instead of Gnus :(
>>>>
>>>>     > depending in your role in the project, you might get something
>>>>     like that
>>>>     > to work too.
>>>>     >
>>>>     > Tory S. Anderson writes:
>>>>     >
>>>>     >> I've relied on Orgmode heavily for over half a decade, and I'm
>>>>     >> loathe to leave it. But what solutions have been found out
>>>>     there
>>>>     >> for using it collaboratively (where others are not using
>>>>     emacs),
>>>>     >> rather than just for personal task management (where it
>>>>     excels)?
>>>>     >> It has some integration with Trello, I know; some of my
>>>>     co-workers
>>>>     >> are advocating BaseCamp (...) and PivotalTracker.
>>>>     PivotalTracker
>>>>     >> looks pretty good, but I would rather find a way to leverage
>>>>     >> orgmode in a way that facilitates collaboration. What has
>>>>     worked
>>>>     >> for you?
>>>>     >
>>>>     > --
>>>>     > Professor John Kitchin
>>>>     > Doherty Hall A207F
>>>>     > Department of Chemical Engineering
>>>>     > Carnegie Mellon University
>>>>     > Pittsburgh, PA 15213
>>>>     > 412-268-7803
>>>>     > @johnkitchin
>>>>     > http://kitchingroup.cheme.cmu.edu
>>
>> --
>> Professor John Kitchin
>> Doherty Hall A207F
>> Department of Chemical Engineering
>> Carnegie Mellon University
>> Pittsburgh, PA 15213
>> 412-268-7803
>> @johnkitchin
>> http://kitchingroup.cheme.cmu.edu

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



reply via email to

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