Re: [O] Including linked emails during export (was Re: Integration of notmuch email references in notes in org-mode)
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: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)
Hey Nicolas,
On Wed, Feb 27, 2013 at 02:35:04PM +0100, Nicolas Goaziou wrote:
Hello,
Rainer M Krug r.m.k...@gmail.com 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)
-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-
