Re: inserting files within remember templates

[Adam Spiers <orgmode@adamspiers.org>]

Caveat: the following was written using a sleep-deprived brain %-)

Georg, judging by your mail

  http://article.gmane.org/gmane.emacs.orgmode/3814/

I think you and I are trying to achieve something similar with our
org/mairix integration efforts.  I would also find your suggestion of
`org-remember-files' useful as a way of choosing the destination file
orthogonally from the choice of remember template.  Alternatively if
remember templates supported prefix keys in the same way that
org-agenda-custom-commands now does, it would be possible to have the
prefix key for choosing the template, and the sub-keymap key for
choosing the destination file, or vice-versa, though I think a
separate variable associating key shortcuts with destination files
would be cleaner.  Would be good to get Carsten's thoughts on the
relevant merits of these two approaches.

The main difference between our needs is that while I use mutt as the
mail client, IIRC you are using gnus.  Using a MUA external to emacs
has its own set of challenges, as previously discussed with Bastien:

  http://thread.gmane.org/gmane.emacs.orgmode/4217/focus=4289

I have written a simple Perl script which when a mail is piped into it
(e.g. from a mutt macro), will extract properties from that mail and
dump an elisp form into a temporary file which emacs can then
evaluate, e.g.

  (org-store-link-props
    :type "mairix"
    :link "mairix:m:m3abqlrjf2.fsf@cerebro.fsfeurope.org"
    :from "\"Georg C. F. Greve\" <greve@fsfeurope.org>"
    :subject "Re: [Orgmode] Using org-remember to include stored link?"
    :subjectquery "s:Using,org,remember,to,include,stored,link"
    :message-id "<m3abqlrjf2.fsf@cerebro.fsfeurope.org>"
    :message-id-query "m:m3abqlrjf2.fsf@cerebro.fsfeurope.org")

I chose to parse the mail and extract properties once at the time the
mutt macro was invoked, mainly because I knew I could implement it
quicker in Perl than in elisp :-)  However I am now wondering if that
was a design mistake...

The end goal is that by invoking `org-remember' and then a single
keystroke to select the right remember template, something like:

* TODO [#B] todo description provided by prompting user
  [[mairix:m:m3abqlrjf2.fsf@cerebro.fsfeurope.org][mail from Georg C. F. Greve: Re: [Orgmode] Using org-remember to include stored link?]]

will get inserted at the top of a particular TODO.org file, according
to the current value of `org-email-link-description-format'.

However, at this point I am somewhat stuck, since invoking
`org-store-link-props' by merely evaluating the elisp in the file is
not sufficient to:

  (a) push the link onto the `org-stored-links' list, and
  (b) figure out the link description using `org-email-link-description'.

In normal usage, `org-store-link' takes care of both of these, but
what if instead, you want to store a link non-interactively for later
use in a remember template, and you already know what type of link you
want to store?

In this case, it seems that there are two issues with
`org-store-link', presumably due to it having been designed to support
interactive usage only.  Firstly, the type of link is automagically
determined by iterating over `org-store-link-functions', which in this
case is not what I want (since I want to enforce storage of a mairix
link).  Secondly, it is automatically invoked from 'org-remember' via
`org-remember-annotation', which would presumably push a link to the
current buffer ahead of the stored mairix link in the org-stored-links
list, meaning that %a gets the wrong link substituted.

It looks like Georg faced the same problem (a) when writing
`org-mairix-sent-message-remember' as he had to copy the following
code out of `org-store-link':

     (setq org-stored-links
           (cons (list link desc) org-stored-links))

One solution to (a) might be to factor out the code at the end of
`org-store-link' into a separate helper function which could then be
reused by the elisp in the temporary file?  But what about (b) and the
question of how to get the remember template to include the stored
link?

On Thu, Nov 08, 2007 at 01:09:28PM +0000, Bastien wrote:
> Hi Georg,
> 
> "Georg C. F. Greve" <greve@fsfeurope.org> writes:
> 
> > I would like to do this in a way that it only temporarily modifies the
> > org-remember-templates, but at the moment, this function does that
> > permanently.
> 
> See my comment below.
> 
> > (defun org-mairix-sent-message-remember ()
> >   "Function to be called by org-mairix-message-send-and-exit-with-link
> > via hook to store a link to a sent message by calling remember.
> >
> > It works by first inserting the 'org-mairix' link provided by
> > org-mairix-message-send-and-exit-with-link for '%a' in the
> > org-mairix-message-sent-remember-template string and then
> > iterating through the org-remember-templates, replacing all the
> > standard items by the org-mairix-message-sent-remember-template
> > before calling org-remember."
> >   (let* ((templates) (templ)
> > 	 (org-remember-templates org-remember-templates)
> 
> Why do you need to copy the global value of `org-remember-templates'?
> Can't you just define it *locally*?
> 
> (let* ((org-remember-templates 
>          '((?w org-mairix-message-sent-remember-template 
>                nil ; no file name
>                "WAITING" ; the headline))))
>    ...)
> 
> This shouldn't modify the global set of templates.

[Aside: I haven't thought too hard about how to handle remembering of
messages just *sent*, since AFAIK mutt does not have a hook for
executing macros just after sending mail and saving a copy locally,
but regardless of whether we're trying to remember a link to a mail
just sent or one previous received, it seems to be the same problem.]

Locally overriding the global value of the `org-remember-templates'
list by iterating over it with %a substitutions sounds a bit hackish
to me.  If we can fix the above issues I mention, I believe it would
no longer be necessary to do that.

Finally, as Bastien suggested, I could instead have had the mutt macro
dump the mail header into a file which emacs could then parse, perhaps
by using `message-fetch-mail' in the same way that org-mairix.el
already does.  But I suspect that the issues I mention above with
`org-store-link' will still cause problems.

I hope that all made sense.  I can't think 100% straight right now %-)