Hello,
Rainer M Krug <r.m.k...@gmail.com> 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
