Re: [O] Including linked emails during export (was Re: Integration of notmuch email references in notes in org-mode)

[Nicolas Goaziou]

Hello,

Rainer M Krug <address@hidden> writes:

> On 18/02/13 22:41, Suvayu Ali wrote:
>> Hi,
>> 
>> On Mon, Feb 18, 2013 at 04:33:45PM +0100, Rainer M Krug wrote:
>>> On 18/02/13 16:12, Suvayu Ali wrote:
>>>> On Mon, Feb 18, 2013 at 02:49:32PM +0100, Rainer M Krug wrote:
>>>>> 
>>>>> - From time to time, I have to include email references in notes in org. 
>>>>> There is
>>>>> obviously org-notmuch.el, but I am not to happy with it as, when 
>>>>> exporting the notes, the
>>>>> link is shown but neither clickable nor the resulting email is shown in 
>>>>> the exported
>>>>> document (both understandable).
>>>>> 
>>>> 
>>>> This has also been an irritation of mine.  I think I will take your second 
>>>> idea (include
>>>> the email on export) and see if I can come-up with a patch for 
>>>> org-notmuch.  Since I'm
>>>> still a newbie elisp programmer, this might take a while.  :-p
>>> 
>>> If there is a solution in sight, I am happy to wait a bit - email in 
>>> export, possibly in a
>>> block so that it is set apart from the rest of the document, would be 
>>> brilliant. Possibly
>>> having an option which can be set to have links exported as links or 
>>> expanded on export,
>>> would be really nice.
>> 
>> The option to open the link is out of the question since different people 
>> read their emails
>> differently.  There is no way for a library to get everything right, 
>> specially since the link
>> won't be in Emacs. It is in the exported file (e.g. html, pdf, txt).
>
> If I understand the link system correctly, one would need to create a notmuch 
> protocoll so that
> linux can react to clicking the link. But you are right, this is outside org.
>
>
>> 
>> Now to include the email during the export at first I thought it should be 
>> possible to write a
>> filter, but then I realised I need to insert an email quote block after 
>> whatever parent
>> greater-element holds the link and then redirect the link to this new block. 
>>  A filter allows
>> you a way to modify an element, but nothing more.  So I think the correct 
>> approach here would
>> be to write a derived backend.  This complicates things quite significantly 
>> since now you need
>> to support each backend separately.  I wonder if there is any easier 
>> (generic) way to do the
>> above for all present and future backends.
>
> How is the export of links to pictures handled - as far as I remember, if the 
> image is in a LaTeX
> suitable format, the image is included in the LaTeX file, and the same for 
> html. But you are right
> - I guess this is handled in the backend. I don't think that would be a 
> suitable approach as it
> would include to much maintenance.
>
> But what about defining notmuch as a new language for babel, so that one 
> could do the following:
>
> #+begin_src notmuch :exports raw
>   search id:XXXXXXXXXXXXXXXXx
> #+end_src
>
> Would not be much different then
>
> #+begin_src sh :exports raw
>   notmuch search id:XXXXXXXXXXXXXXXXx
> #+end_src
>
> but possibly open more possibilities for customizations?
> XXXXXXXXXXXXXXXXx
> Or inline it could be src_notmuch{search id:XXXXXXXXXXXXXXXXx}
>
> The general advantage would be that one can use the existing infrastructure 
> for code blocks and
>
> Cheers,
>
> Rainer
>
>> 
>> I have CC'd Nicolas, lets see what he has to say.

FWIW, I think the approach suggested by Rainer is good, i.e. writing
a new "language" for Babel, with specific headers. Such blocks would
then be expanded into appropriate Org syntax the exporter can
understand.


Regards,

-- 
Nicolas Goaziou