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