From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: inserting files within remember templates Date: Sat, 8 Dec 2007 20:08:22 +0000 Message-ID: <20071208200822.GD15129@atlantic.linksys.moosehall> References: <20071105181739.GB13544@atlantic.linksys.moosehall> <8A730AEC-45F4-4A2F-BD38-24DEBF937445@science.uva.nl> <20071106163647.GC13544@atlantic.linksys.moosehall> <87wssupypp.fsf@bzg.ath.cx> <20071107095826.GE13544@atlantic.linksys.moosehall> <87ir4ew7d6.fsf@bzg.ath.cx> <20071107125022.GK13544@atlantic.linksys.moosehall> <87ejf2nmr8.fsf@bzg.ath.cx> <20071107143641.GP13544@atlantic.linksys.moosehall> <871wb1mljc.fsf@bzg.ath.cx> Reply-To: Adam Spiers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J15yO-0007ay-Uw for emacs-orgmode@gnu.org; Sat, 08 Dec 2007 15:08:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J15yN-0007am-Aa for emacs-orgmode@gnu.org; Sat, 08 Dec 2007 15:08:28 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J15yN-0007aj-5L for emacs-orgmode@gnu.org; Sat, 08 Dec 2007 15:08:27 -0500 Received: from mail.beimborn.com ([70.84.38.100]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J15yM-0007aw-MM for emacs-orgmode@gnu.org; Sat, 08 Dec 2007 15:08:26 -0500 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id lB8K8P6V003054 for ; Sat, 8 Dec 2007 14:08:25 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id lB8K8PNf003049 for emacs-orgmode@gnu.org; Sat, 8 Dec 2007 20:08:25 GMT Content-Disposition: inline In-Reply-To: <87fxzgg9yv.fsf@bzg.ath.cx> <871wb1mljc.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.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\" " :subject "Re: [Orgmode] Using org-remember to include stored link?" :subjectquery "s:Using,org,remember,to,include,stored,link" :message-id "" :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" 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 %-)