Re: [O] Including linked emails during export (was Re: Integration of notmuch email references in notes in org-mode)
Hey Nicolas,
On Wed, Feb 27, 2013 at 02:35:04PM +0100, Nicolas Goaziou wrote:
> Hello,
>
> Rainer M Krug writes:
> >
> > 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:x
> > #+end_src
> >
> > Would not be much different then
> >
> > #+begin_src sh :exports raw
> > notmuch search id:x
> > #+end_src
> >
> > but possibly open more possibilities for customizations?
> > x
> > Or inline it could be src_notmuch{search id:x}
> >
> > The general advantage would be that one can use the existing
> > infrastructure for code blocks and
>
> 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.
Thanks for your feedback. I haven't had any time to look at this yet.
I'll keep this in mind.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Including linked emails during export (was Re: Integration of notmuch email references in notes in org-mode)
Hello,
Rainer M Krug 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:x
> #+end_src
>
> Would not be much different then
>
> #+begin_src sh :exports raw
> notmuch search id:x
> #+end_src
>
> but possibly open more possibilities for customizations?
> x
> Or inline it could be src_notmuch{search id:x}
>
> 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
Re: [O] Including linked emails during export (was Re: Integration of notmuch email references in notes in org-mode)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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:x
#+end_src
Would not be much different then
#+begin_src sh :exports raw
notmuch search id:x
#+end_src
but possibly open more possibilities for customizations?
x
Or inline it could be src_notmuch{search id:x}
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.
>
> Cheers,
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRIzQHAAoJENvXNx4PUvmCD7gH/3uS607nlfa31Nzxyt7j6bRH
UrFmDtpaU0zgjpPvSdqCRgF2V1R8O4lXTQd8P66swQ+tWglKSXaPaeP625I1zo0U
wjMHoAsppiENz4lMVV6S7Hya3DuegLgwU+5+KcC7m2XbiFqzStIs8uhczyIZ9EKH
GjrvMLrglkw3Nf/Gq4etvvPVnH05UqrBHsOF4j6W8ZcDAM0fufbv5EuMXt4gvlqy
E5fJbth06mphZRe/d8jpQ0XR97RIz5Vq4gOajwBa3kLT7BY7Y2SYUu2PDV44YjwF
8d4CSTgq0ReDQsg8qch6tE1dli/ftw2i0Qe9j3MCZ3QItB5aJ/y6rh4oAmMhzi0=
=0LBU
-END PGP SIGNATURE-
[O] Including linked emails during export (was Re: Integration of notmuch email references in notes in org-mode)
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). 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. I have CC'd Nicolas, lets see what he has to say. Cheers, -- Suvayu Open source is the future. It sets us free.
