* Composing letters using Org mode and the LaTeX isodoc class
@ 2010-09-07 11:36 Sébastien Vauban
2010-09-07 18:46 ` Jambunathan K
0 siblings, 1 reply; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-07 11:36 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hello,
Based on a thread launched by Jambunathan, I've tried to follow another
direction, having a huge interest in getting such a thing to work.
My trial is very border-line, as I tried using Org code blocks. Would these be
"convertable" to LaTeX, that would make (or have made) sense.
Just presenting this to you, in order to receive ideas on how to progress in
the right direction.
--8<---------------cut here---------------start------------->8---
#+TITLE: Org-isodoc
#+AUTHOR: Seb Vauban
#+DATE: 2010-09-07
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE: en_US
* To
#+srcname: to
#+begin_src org
Org mode user group \\
World Wide Web
#+end_src
* Subject
#+srcname: subject
#+begin_src org
Composing letters using Org mode and the LaTeX isodoc class
#+end_src
* Opening
#+srcname: opening
#+begin_src org
Dear Org mode users,
#+end_src
* Body
#+srcname: body
#+begin_src org
Following ideas found here, I am trying to use Org for writing LaTeX letters
at the speed of light.
The class I'm used to compose with is called isodoc. Very nice. You should try
it...
*Problems* encountered /so far/:
- how to insert properly converted tables (to =LaTeX=)?
| test | hello |
| foo | bar |
- begin an Org block, editing this code adds commas in front of every line...
That's all for now.
#+end_src
* Closing
#+srcname: closing
#+begin_src org
Yours Truly
#+end_src
* Encl
#+srcname: encl
#+begin_src org
I still have to look at how to declare some attached documents.
#+end_src
* Letter
#+begin_src latex :noweb yes :tangle yes
\documentclass[11pt]{isodoc}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
%\usepackage[scorpios]{isodoc-style}
\usepackage[mygooglest]{isodoc-style}
\setupdocument{
to = {%
<<to>>},
subject = {<<subject>>},
opening = {<<opening>>},
closing = {<<closing>>}
}
\begin{document}
\letter{%
<<body>>
}
\end{document}
#+end_src
#+results:
#+BEGIN_LaTeX
\documentclass[11pt]{isodoc}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
%\usepackage[scorpios]{isodoc-style}
\usepackage[mygooglest]{isodoc-style}
\setupdocument{
to = {%
Org mode user group \\
World Wide Web},
subject = {Composing letters using Org mode and the LaTeX isodoc class},
opening = {Dear Org mode users,},
closing = {Yours Truly}
}
\begin{document}
\letter{%
Following ideas found here, I am trying to use Org for writing LaTeX letters
at the speed of light.
The class I'm used to compose with is called isodoc. Very nice. You should try
it...
*Problems* encountered /so far/:
- how to insert properly converted tables (to =LaTeX=)?
| test | hello |
| foo | bar |
- begin an Org block, editing this code adds commas in front of every line...
That's all for now.
}
\end{document}
#+END_LaTeX
--8<---------------cut here---------------end--------------->8---
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-07 11:36 Composing letters using Org mode and the LaTeX isodoc class Sébastien Vauban
@ 2010-09-07 18:46 ` Jambunathan K
2010-09-07 19:45 ` Sébastien Vauban
0 siblings, 1 reply; 21+ messages in thread
From: Jambunathan K @ 2010-09-07 18:46 UTC (permalink / raw)
To: emacs-orgmode
Hi Sebastien
Tried out isodoc. I like it.
I only wish I had started out with this package rather than
scrlttr2.
The good thing about isodoc is that the default style of 'A simple
letter' in the document [1] is more closer to the convention that is
used here in India. Furthermore package seems 'very recent'.
With scrlttr2 [2], I had invested good amount of time reading through
the manual and tweaking DIN.lco to assigning From, To and Subject lines
to their 'rightful' place. I also felt that the default style was a bit
too gaudy for my taste.
I will have isodoc in mind when I get to work on a patch for letter
writing support in orgmode. The essentials for letter writing support
seem to be the same - setup key, value pairs (with key being a headline
and value being the body) and emit them in a way that is expected by the
underlying package.
I would like to hear why you chose to go down the tangling
path. Personally I feel any sort of markup (this includes babel
directives) distracting.
Btw, your approach set me thinking. I think there is a strong case for
making headlines act as babel srcnames with their body providing content
for noweb expansion [3]. This behaviour could be controlled by a buffer
local variable.
Wondering how babel treats srcnames? Can there be spaces? Is upper and
lower cases treated one and the same ...
Footnotes:
[1] http://mirror.ctan.org/macros/latex/contrib/isodoc/isodoc.pdf
[2] http://thread.gmane.org/gmane.emacs.orgmode/28012
[3] It is likely the body of the headline might be run through a custom
renderer (say latex, html or even emac's own comment-region) before
finding it's way in to the document generated by tangle.
Thanks once again for referring me to isodoc.
Thanks,
Jambunathan K.
Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:
> Hello,
>
> Based on a thread launched by Jambunathan, I've tried to follow another
> direction, having a huge interest in getting such a thing to work.
>
> My trial is very border-line, as I tried using Org code blocks. Would these be
> "convertable" to LaTeX, that would make (or have made) sense.
>
> Just presenting this to you, in order to receive ideas on how to progress in
> the right direction.
>
> #+TITLE: Org-isodoc
> #+AUTHOR: Seb Vauban
> #+DATE: 2010-09-07
> #+DESCRIPTION:
> #+KEYWORDS:
> #+LANGUAGE: en_US
>
> * To
> #+srcname: to
> #+begin_src org
> Org mode user group \\
> World Wide Web
> #+end_src
>
> * Subject
> #+srcname: subject
> #+begin_src org
> Composing letters using Org mode and the LaTeX isodoc class
> #+end_src
>
> * Opening
> #+srcname: opening
> #+begin_src org
> Dear Org mode users,
> #+end_src
>
> * Body
> #+srcname: body
> #+begin_src org
> Following ideas found here, I am trying to use Org for writing LaTeX letters
> at the speed of light.
>
> The class I'm used to compose with is called isodoc. Very nice. You should try
> it...
>
> *Problems* encountered /so far/:
> - how to insert properly converted tables (to =LaTeX=)?
> | test | hello |
> | foo | bar |
> - begin an Org block, editing this code adds commas in front of every line...
>
> That's all for now.
> #+end_src
>
> * Closing
> #+srcname: closing
> #+begin_src org
> Yours Truly
> #+end_src
>
> * Encl
> #+srcname: encl
> #+begin_src org
> I still have to look at how to declare some attached documents.
> #+end_src
>
> * Letter
> #+begin_src latex :noweb yes :tangle yes
> \documentclass[11pt]{isodoc}
> \usepackage[utf8x]{inputenc}
> \usepackage[T1]{fontenc}
>
> %\usepackage[scorpios]{isodoc-style}
> \usepackage[mygooglest]{isodoc-style}
>
> \setupdocument{
> to = {%
> <<to>>},
> subject = {<<subject>>},
> opening = {<<opening>>},
> closing = {<<closing>>}
> }
>
> \begin{document}
> \letter{%
> <<body>>
> }
> \end{document}
> #+end_src
>
> #+results:
> #+BEGIN_LaTeX
> \documentclass[11pt]{isodoc}
> \usepackage[utf8x]{inputenc}
> \usepackage[T1]{fontenc}
>
> %\usepackage[scorpios]{isodoc-style}
> \usepackage[mygooglest]{isodoc-style}
>
> \setupdocument{
> to = {%
> Org mode user group \\
> World Wide Web},
> subject = {Composing letters using Org mode and the LaTeX isodoc class},
> opening = {Dear Org mode users,},
> closing = {Yours Truly}
> }
>
> \begin{document}
> \letter{%
> Following ideas found here, I am trying to use Org for writing LaTeX letters
> at the speed of light.
>
> The class I'm used to compose with is called isodoc. Very nice. You should try
> it...
>
> *Problems* encountered /so far/:
> - how to insert properly converted tables (to =LaTeX=)?
> | test | hello |
> | foo | bar |
> - begin an Org block, editing this code adds commas in front of every line...
>
> That's all for now.
> }
> \end{document}
> #+END_LaTeX
>
> Best regards,
> Seb
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-07 18:46 ` Jambunathan K
@ 2010-09-07 19:45 ` Sébastien Vauban
2010-09-08 0:56 ` Eric Schulte
0 siblings, 1 reply; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-07 19:45 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Jambunathan,
Jambunathan K wrote:
> Tried out isodoc. I like it.
Delighted to hear so.
I had tried different packages as well, before, but was always (very)
disappointed by the complexity, as soon as what you want is not what they
made.
With isodoc, everything is quite easily doable, and quite intuitive...
> I only wish I had started out with this package rather than scrlttr2.
>
> The good thing about isodoc is that the default style of 'A simple letter'
> in the document is more closer to the convention that is used here in
> India. Furthermore package seems 'very recent'.
Yep, last update a couple of months ago.
> I will have isodoc in mind when I get to work on a patch for letter writing
> support in orgmode. The essentials for letter writing support seem to be the
> same - setup key, value pairs (with key being a headline and value being the
> body) and emit them in a way that is expected by the underlying package.
>
> I would like to hear why you chose to go down the tangling path.
For two reasons:
- because I had not the hope of being able to configure the LaTeX export class
and/or code in the right way,
- because, in a way, that's quite logical. Here and there, you define stuff.
At the end, you just arrange them all in a way that fits well the LaTeX
class demands.
Though, it's not just copying, the way Babel actually does with snippets of
code "à la Noweb". Hence, I really need at least the body to be in real Org
plain code, and be automatically converted to LaTeX, so that I can make use of
the tables, and all the Org markup.
I'm sure Babel is able of that, mixing raw code with convertable code. Just
needs more thinking.
> Personally I feel any sort of markup (this includes babel directives)
> distracting.
They're much less distracting as soon as they're properly highlighted.
Question of color-theme. I can provide you (all) with mine, if you're
interested.
> Btw, your approach set me thinking. I think there is a strong case for
> making headlines act as babel srcnames with their body providing content for
> noweb expansion [3]. This behaviour could be controlled by a buffer local
> variable.
That would definitely make sense to me, at least for this particular need.
But, maybe, there is already a parallel way to do such a thing...
> Wondering how babel treats srcnames? Can there be spaces? Is upper and lower
> cases treated one and the same ...
Being a (tiny) part-time Babel user, I wish I could easily answer such
questions. But, as I always try to take as less risks as possible, these are
things I never really looked at.
> Footnotes:
> [3] It is likely the body of the headline might be run through a custom
> renderer (say latex, html or even emac's own comment-region) before
> finding it's way in to the document generated by tangle.
>
> Thanks once again for referring me to isodoc.
"When someone shares something of value with you and you benefit from it, you
have a moral obligation to share it with others." -- Chinese proverb
I've been as well referred to this excellent package by a friend. Hence, I do
what I have to do...
I now would be pleased to hear what others think, and eventually can do along
this line!
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-07 19:45 ` Sébastien Vauban
@ 2010-09-08 0:56 ` Eric Schulte
2010-09-08 1:52 ` Thomas S. Dye
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Eric Schulte @ 2010-09-08 0:56 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
Hi,
I'll try to answer some of the Babel related portions of this discussion
below.
I look forward to any potential org->letter export this line of
investigation yields.
Best -- Eric
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> Hi Jambunathan,
>
> Jambunathan K wrote:
[...]
>> I would like to hear why you chose to go down the tangling path.
>
> For two reasons:
>
> - because I had not the hope of being able to configure the LaTeX export class
> and/or code in the right way,
>
Hmm, I don't know how complex isodoc is to configure, but I'd think that
defining a custom latex class would be simpler than tangling out LaTeX
code blocks, however maybe this will change once I've looked at and
understood an example application.
>
> - because, in a way, that's quite logical. Here and there, you define
> stuff. At the end, you just arrange them all in a way that fits well
> the LaTeX class demands.
>
> Though, it's not just copying, the way Babel actually does with snippets of
> code "à la Noweb". Hence, I really need at least the body to be in real Org
> plain code, and be automatically converted to LaTeX, so that I can make use of
> the tables, and all the Org markup.
>
> I'm sure Babel is able of that, mixing raw code with convertable code. Just
> needs more thinking.
>
I've just implemented export of org code blocks to ascii, latex or html,
so the following should now (if I understood) allow the tangling
behavior you've described
--8<---------------cut here---------------start------------->8---
** tangle org-mode block
#+source: org-list
#+begin_src org :results latex
- one
- two
- three
#+end_src
#+begin_src emacs-lisp :tangle yes :noweb yes
"
<<org-list()>>
"
#+end_src
--8<---------------cut here---------------end--------------->8---
tangles to
--8<---------------cut here---------------start------------->8---
"
\begin{itemize}
\item two
\item three
\end{itemize}
"
--8<---------------cut here---------------end--------------->8---
note that the () on the end of the code block name in the noweb syntax
means to insert the results of evaluating the code block (in this case
latex) rather than the body of the code block itself.
>
>
>> Personally I feel any sort of markup (this includes babel directives)
>> distracting.
>
> They're much less distracting as soon as they're properly highlighted.
> Question of color-theme. I can provide you (all) with mine, if you're
> interested.
>
>
>> Btw, your approach set me thinking. I think there is a strong case for
>> making headlines act as babel srcnames with their body providing content for
>> noweb expansion [3]. This behaviour could be controlled by a buffer local
>> variable.
>
> That would definitely make sense to me, at least for this particular need.
> But, maybe, there is already a parallel way to do such a thing...
>
>
>> Wondering how babel treats srcnames? Can there be spaces? Is upper and lower
>> cases treated one and the same ...
>
Spaces are now allowed, I'm honestly not sure that it will successfully
distinguish between upper and lower cases in code block names (all of
mine are lower-case), but either way I'd say it's poor style to rely on
case to distinguish between different code blocks.
Best -- Eric
>
> Being a (tiny) part-time Babel user, I wish I could easily answer such
> questions. But, as I always try to take as less risks as possible, these are
> things I never really looked at.
>
>
>> Footnotes:
>> [3] It is likely the body of the headline might be run through a custom
>> renderer (say latex, html or even emac's own comment-region) before
>> finding it's way in to the document generated by tangle.
>>
>> Thanks once again for referring me to isodoc.
>
> "When someone shares something of value with you and you benefit from it, you
> have a moral obligation to share it with others." -- Chinese proverb
>
> I've been as well referred to this excellent package by a friend. Hence, I do
> what I have to do...
>
> I now would be pleased to hear what others think, and eventually can do along
> this line!
>
> Best regards,
> Seb
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 0:56 ` Eric Schulte
@ 2010-09-08 1:52 ` Thomas S. Dye
2010-09-08 4:39 ` Jambunathan K
2010-09-08 11:45 ` Composing letters using Org mode and the LaTeX isodoc class Sébastien Vauban
2 siblings, 0 replies; 21+ messages in thread
From: Thomas S. Dye @ 2010-09-08 1:52 UTC (permalink / raw)
To: Eric Schulte; +Cc: Sébastien Vauban, emacs-orgmode
Hi Eric,
Thank you. This will be very useful.
All the best,
Tom
On Sep 7, 2010, at 2:56 PM, Eric Schulte wrote:
> #+begin_src org :results latex
> - one
> - two
> - three
> #+end_src
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 0:56 ` Eric Schulte
2010-09-08 1:52 ` Thomas S. Dye
@ 2010-09-08 4:39 ` Jambunathan K
2010-09-08 11:48 ` Sébastien Vauban
2010-09-08 15:15 ` Eric Schulte
2010-09-08 11:45 ` Composing letters using Org mode and the LaTeX isodoc class Sébastien Vauban
2 siblings, 2 replies; 21+ messages in thread
From: Jambunathan K @ 2010-09-08 4:39 UTC (permalink / raw)
To: Eric Schulte; +Cc: Sébastien Vauban, emacs-orgmode
Eric
Thanks for the changes. I believe I need not work (or for all practical
purposes set aside) working on letter writing support.
Jambu>>> Btw, your approach set me thinking. I think there is a strong
Jambu>>> case for making headlines act as babel srcnames with their body
Jambu>>> providing content for noweb expansion [3]. This behaviour could
Jambu>>> be controlled by a buffer local variable.
Is this suggestion considered and set aside or overlooked? Read on down
below.
Jambu>>> Wondering how babel treats srcnames? Can there be spaces? Is
Jambu>>> upper and lower cases treated one and the same ...
Eric> Spaces are now allowed, I'm honestly not sure that it will
Eric> successfully distinguish between upper and lower cases in code
Eric> block names (all of mine are lower-case)
Good.
Honoring spaces would be a pre-requisite if one were to allow org's
headlines as implicit srcnames.
Question on case-handling was intended not as a feature request but more
on clarity of the behaviour.
Eric> I've just implemented export of org code blocks to ascii, latex or html,
Eric> so the following should now (if I understood) allow the tangling
Eric> behavior you've described
Eric>
Eric> ** tangle org-mode block
Eric> #+source: org-list
Eric> #+begin_src org :results latex
Eric> - one
Eric> - two
Eric> - three
Eric> #+end_src
Eric>
Eric> #+begin_src emacs-lisp :tangle yes :noweb yes
Eric> "
Eric> <<org-list()>>
Eric> "
Eric> #+end_src
Eric>
Eric> tangles to
Eric>
Eric>
Eric> "
Eric> \begin{itemize}
Eric> \item two
Eric> \item three
Eric> \end{itemize}
Eric>
Eric>
Eric> "
Eric>
Eric> note that the () on the end of the code block name in the noweb syntax
Eric> means to insert the results of evaluating the code block (in this case
Eric> latex) rather than the body of the code block itself.
If babel supports headlines as srcnames, without requiring additional
begin/end directives one could just write,
* org-list
- one
- two
- three
#+begin_src emacs-lisp :tangle yes :noweb yes
"
<<org-list(:fmt latex)>>
"
#+end_src
and achieve similar results.
Based on my earlier efforts at letter-writing, I have the following
observation.
Letters have a To address and they could be pulled from bbdb. So one
could say,
* To
[[a bbdb link]]
#+begin_src emacs-lisp :tangle yes :noweb yes
"
<<To(:fmt custom)>>
"
#+end_src
The string custom could be a elisp form or a function pointer that takes
the body of the headline as an argument and does the needful.
Specifically in the above example, 'custom' handler would visit the bbdb
record, fetch the address and return the formatted address (with line
breaks etc etc) as the noweb expansion. [Custom handler would be
implemented by the user himself]
Any thoughts on how this could be achieved ...
Jambunathan K.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 0:56 ` Eric Schulte
2010-09-08 1:52 ` Thomas S. Dye
2010-09-08 4:39 ` Jambunathan K
@ 2010-09-08 11:45 ` Sébastien Vauban
2010-09-08 15:38 ` Eric Schulte
2 siblings, 1 reply; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-08 11:45 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Eric,
"Eric Schulte" wrote:
> I look forward to any potential org->letter export this line of
> investigation yields.
As soon as this is closed, I'm willing to write a Worg page for this.
>> - because I had not the hope of being able to configure the LaTeX export class
>> and/or code in the right way,
>
> Hmm, I don't know how complex isodoc is to configure, but I'd think that
> defining a custom latex class would be simpler than tangling out LaTeX code
> blocks, however maybe this will change once I've looked at and understood an
> example application.
Isodoc is quite easy to configure, but it's through keyval mappings. I don't
know enough of Org to imagine being able to convert headings and contents to
keys and values, respectively...
That does not mean it really is difficult. Just for me, the only accessible
way remained the Babel route.
>> - because, in a way, that's quite logical. Here and there, you define
>> stuff. At the end, you just arrange them all in a way that fits well the
>> LaTeX class demands.
>>
>> Though, it's not just copying, the way Babel actually does with snippets of
>> code "à la Noweb". Hence, I really need at least the body to be in real Org
>> plain code, and be automatically converted to LaTeX, so that I can make use
>> of the tables, and all the Org markup.
>>
>> I'm sure Babel is able of that, mixing raw code with convertable code. Just
>> needs more thinking.
>
> I've just implemented export of org code blocks to ascii, latex or html,
This is brand new, right? In any case, the real good solution to such a
problem, IMHO...
> so the following should now (if I understood) allow the tangling
> behavior you've described
>
> ** tangle org-mode block
> #+source: org-list
> #+begin_src org :results latex
> - one
> - two
> - three
> #+end_src
>
> #+begin_src emacs-lisp :tangle yes :noweb yes
> "
> <<org-list()>>
> "
> #+end_src
>
> tangles to
>
>
> "
> \begin{itemize}
> \item two
> \item three
> \end{itemize}
>
>
> "
Here, I just don't understand why you're choosing `emacs-lisp' as target
language for LaTeX code. Is there a reason for this, or just a typo?
> note that the () on the end of the code block name in the noweb syntax
> means to insert the results of evaluating the code block (in this case
> latex) rather than the body of the code block itself.
Understood! Thanks.
FYI, I've git pulled once again 15 minutes ago (13:30 CET). My repo was
already up-to-date, but your code does not work for me...
_Nothing is tangled anymore_... Not even if I explicitly state
=:tangle "AA.tex"= for example (with and without quotes ;-)).
*Extract* of what should be tangled:
--8<---------------cut here---------------start------------->8---
* Letter
#+begin_src latex :noweb yes :tangle yes
\documentclass[11pt]{isodoc}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{isodoc-style}
\setupdocument{
to = {%
<<to()>>},
subject = {<<subject()>>},
opening = {<<opening()>>},
closing = {<<closing()>>}
}
\begin{document}
\letter{%
<<body()>>
}
\end{document}
#+end_src
* tangle org-mode block
#+source: org-list
#+begin_src org :results latex
- one
- two
- three
#+end_src
#+begin_src emacs-lisp :tangle yes :noweb yes
"
<<org-list()>>
"
#+end_src
--8<---------------cut here---------------end--------------->8---
Side note: I now have "my" green background for Org code (as in
http://www.mygooglest.com/sva/highlight-whole-ines.png), but I've lost all
fontification of source code blocks...
Thanks again and again.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 4:39 ` Jambunathan K
@ 2010-09-08 11:48 ` Sébastien Vauban
2010-09-08 15:15 ` Eric Schulte
1 sibling, 0 replies; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-08 11:48 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Jambunathan,
Jambunathan K wrote:
> Honoring spaces would be a pre-requisite if one were to allow org's
> headlines as implicit srcnames.
Or you would have to impose titles without spaces, which is acceptable as well
for such a usage...
> If babel supports headlines as srcnames, without requiring additional
> begin/end directives one could just write,
>
> * org-list
> - one
> - two
> - three
>
> #+begin_src emacs-lisp :tangle yes :noweb yes
> "
> <<org-list(:fmt latex)>>
> "
> #+end_src
>
> and achieve similar results.
>
> Based on my earlier efforts at letter-writing, I have the following
> observation.
>
> Letters have a To address and they could be pulled from bbdb. So one
> could say,
>
> * To
> [[a bbdb link]]
>
>
> #+begin_src emacs-lisp :tangle yes :noweb yes
> "
> <<To(:fmt custom)>>
> "
> #+end_src
>
> The string custom could be a elisp form or a function pointer that takes
> the body of the headline as an argument and does the needful.
>
> Specifically in the above example, 'custom' handler would visit the bbdb
> record, fetch the address and return the formatted address (with line
> breaks etc etc) as the noweb expansion. [Custom handler would be
> implemented by the user himself]
>
> Any thoughts on how this could be achieved ...
That's going (really) far... But would that be do-able, waaoow!
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 4:39 ` Jambunathan K
2010-09-08 11:48 ` Sébastien Vauban
@ 2010-09-08 15:15 ` Eric Schulte
2010-09-08 16:22 ` [BABEL][PROPOSAL] headlines as executable srcnames Jambunathan K
1 sibling, 1 reply; 21+ messages in thread
From: Eric Schulte @ 2010-09-08 15:15 UTC (permalink / raw)
To: Jambunathan K; +Cc: Sébastien Vauban, emacs-orgmode
Hi,
Jambunathan K <kjambunathan@gmail.com> writes:
> Eric
>
> Thanks for the changes. I believe I need not work (or for all practical
> purposes set aside) working on letter writing support.
>
> Jambu>>> Btw, your approach set me thinking. I think there is a strong
> Jambu>>> case for making headlines act as babel srcnames with their body
> Jambu>>> providing content for noweb expansion [3]. This behaviour could
> Jambu>>> be controlled by a buffer local variable.
>
> Is this suggestion considered and set aside or overlooked? Read on down
> below.
>
No, I missed this suggestion in the previous post. This is an
interesting suggestion. Next time I have time I will but together a
trail implementation to see how naturally this fits into the rest of the
Babel system. There could be issues (e.g. how to do set header
arguments for the headline).
>
> Jambu>>> Wondering how babel treats srcnames? Can there be spaces? Is
> Jambu>>> upper and lower cases treated one and the same ...
>
> Eric> Spaces are now allowed, I'm honestly not sure that it will
> Eric> successfully distinguish between upper and lower cases in code
> Eric> block names (all of mine are lower-case)
>
I mistyped, Spaces are *not* allowed in code-block names. However any
implementation of treating headlines as code-block names could
automatically convert between hyphens and spaces.
>
> Good.
>
> Honoring spaces would be a pre-requisite if one were to allow org's
> headlines as implicit srcnames.
>
> Question on case-handling was intended not as a feature request but more
> on clarity of the behaviour.
>
> Eric> I've just implemented export of org code blocks to ascii, latex or html,
> Eric> so the following should now (if I understood) allow the tangling
> Eric> behavior you've described
> Eric>
> Eric> ** tangle org-mode block
> Eric> #+source: org-list
> Eric> #+begin_src org :results latex
> Eric> - one
> Eric> - two
> Eric> - three
> Eric> #+end_src
> Eric>
> Eric> #+begin_src emacs-lisp :tangle yes :noweb yes
> Eric> "
> Eric> <<org-list()>>
> Eric> "
> Eric> #+end_src
> Eric>
> Eric> tangles to
> Eric>
> Eric>
> Eric> "
> Eric> \begin{itemize}
> Eric> \item two
> Eric> \item three
> Eric> \end{itemize}
> Eric>
> Eric>
> Eric> "
> Eric>
> Eric> note that the () on the end of the code block name in the noweb syntax
> Eric> means to insert the results of evaluating the code block (in this case
> Eric> latex) rather than the body of the code block itself.
>
> If babel supports headlines as srcnames, without requiring additional
> begin/end directives one could just write,
>
> * org-list
> - one
> - two
> - three
>
> #+begin_src emacs-lisp :tangle yes :noweb yes
> "
> <<org-list(:fmt latex)>>
> "
> #+end_src
>
> and achieve similar results.
>
Yes, however the syntax you've used above to pass a header argument to
the org-lisp code block violates the existing noweb syntax. The place
where you've inserted ":fmt latex" is reserved for passing regular
arguments to code blocks.
>
> Based on my earlier efforts at letter-writing, I have the following
> observation.
>
> Letters have a To address and they could be pulled from bbdb. So one
> could say,
>
> * To
> [[a bbdb link]]
>
>
> #+begin_src emacs-lisp :tangle yes :noweb yes
> "
> <<To(:fmt custom)>>
> "
> #+end_src
>
> The string custom could be a elisp form or a function pointer that takes
> the body of the headline as an argument and does the needful.
>
> Specifically in the above example, 'custom' handler would visit the bbdb
> record, fetch the address and return the formatted address (with line
> breaks etc etc) as the noweb expansion. [Custom handler would be
> implemented by the user himself]
>
> Any thoughts on how this could be achieved ...
>
There has been discussion of allowing post-processing forms for code
blocks which would take the results of a code block as an argument every
time the code block has been called and whose results would replace the
actual code block results, however this has not yet been implemented.
Best -- Eric
>
> Jambunathan K.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 11:45 ` Composing letters using Org mode and the LaTeX isodoc class Sébastien Vauban
@ 2010-09-08 15:38 ` Eric Schulte
2010-09-08 21:26 ` Sébastien Vauban
0 siblings, 1 reply; 21+ messages in thread
From: Eric Schulte @ 2010-09-08 15:38 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
Hi Seb,
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> Hi Eric,
>
> "Eric Schulte" wrote:
>> I look forward to any potential org->letter export this line of
>> investigation yields.
>
> As soon as this is closed, I'm willing to write a Worg page for this.
>
>>> - because I had not the hope of being able to configure the LaTeX export class
>>> and/or code in the right way,
>>
>> Hmm, I don't know how complex isodoc is to configure, but I'd think that
>> defining a custom latex class would be simpler than tangling out LaTeX code
>> blocks, however maybe this will change once I've looked at and understood an
>> example application.
>
> Isodoc is quite easy to configure, but it's through keyval mappings. I don't
> know enough of Org to imagine being able to convert headings and contents to
> keys and values, respectively...
>
> That does not mean it really is difficult. Just for me, the only accessible
> way remained the Babel route.
>
I see, I just wanted to ensure that wrapping content in code blocks was
a last resort, but I agree using Babel in this way should be much easier
than defining a new Org export backend or mucking with Org-mode
internals. I'm very happy if Babel can help to further blur the lines
between Org-mode usage and development in this way.
>
>>> - because, in a way, that's quite logical. Here and there, you define
>>> stuff. At the end, you just arrange them all in a way that fits well the
>>> LaTeX class demands.
>>>
>>> Though, it's not just copying, the way Babel actually does with snippets of
>>> code "à la Noweb". Hence, I really need at least the body to be in real Org
>>> plain code, and be automatically converted to LaTeX, so that I can make use
>>> of the tables, and all the Org markup.
>>>
>>> I'm sure Babel is able of that, mixing raw code with convertable code. Just
>>> needs more thinking.
>>
>> I've just implemented export of org code blocks to ascii, latex or html,
>
> This is brand new, right? In any case, the real good solution to such a
> problem, IMHO...
>
Yes this is new, it actually only required a couple of lines of code to
implement. However that means it may still be buggy.
>
>
>> so the following should now (if I understood) allow the tangling
>> behavior you've described
>>
>> ** tangle org-mode block
>> #+source: org-list
>> #+begin_src org :results latex
>> - one
>> - two
>> - three
>> #+end_src
>>
>> #+begin_src emacs-lisp :tangle yes :noweb yes
>> "
>> <<org-list()>>
>> "
>> #+end_src
>>
>> tangles to
>>
>>
>> "
>> \begin{itemize}
>> \item two
>> \item three
>> \end{itemize}
>>
>>
>> "
>
> Here, I just don't understand why you're choosing `emacs-lisp' as target
> language for LaTeX code. Is there a reason for this, or just a typo?
>
I do all my testing with emacs-lisp code blocks, as their sort of the
simplest (at least for me/Babel) code block. Once it's working there it
should extend to code blocks in other languages as well.
>
>
>> note that the () on the end of the code block name in the noweb syntax
>> means to insert the results of evaluating the code block (in this case
>> latex) rather than the body of the code block itself.
>
> Understood! Thanks.
>
> FYI, I've git pulled once again 15 minutes ago (13:30 CET). My repo was
> already up-to-date, but your code does not work for me...
>
> _Nothing is tangled anymore_... Not even if I explicitly state
> =:tangle "AA.tex"= for example (with and without quotes ;-)).
>
I've taken your excerpt and changed it so that it was tangling
successfully on my system. The main problem was that there were many
noweb references which pointed to outside of the example. The following
does work on my system. Notice that it uses a table to hold the small
components rather than wrapping each in it's own Org-mode block.
--8<---------------cut here---------------start------------->8---
* Letter
#+tblname: head
| To | Eric Schulte |
| Subject | Tangling is Broken |
| Opening | Hi |
| Closing | Best |
#+source: body
#+begin_src org :results latex
- one
- two
- three
#+end_src
#+begin_src latex :noweb yes :tangle yes :var h-to=head[0,1] :var h-subject=head[1,1] :var h-opening=head[2,1] :var h-closing=head[3,1]
\documentclass[11pt]{isodoc}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{isodoc-style}
\setupdocument{
to = {h-to},
subject = {h-subject},
opening = {h-opening},
closing = {h-closing}
}
\begin{document}
\letter{%
<<body()>>
}
\end{document}
#+end_src
--8<---------------cut here---------------end--------------->8---
There appears to be some lingering issues with converting the org block
to latex, for me the first item in the list was missing, I'll try to
take a look at this later today. However, hopefully this gets Babel far
enough that at least the structure of an isodoc letter writing solution
can be fleshed out.
Best -- Eric
^ permalink raw reply [flat|nested] 21+ messages in thread
* [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-08 15:15 ` Eric Schulte
@ 2010-09-08 16:22 ` Jambunathan K
2010-09-08 21:30 ` Sébastien Vauban
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Jambunathan K @ 2010-09-08 16:22 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]
Jambu> I think there is a strong case for making headlines act as babel
Jambu> srcnames with their body providing content for noweb expansion
Jambu> [3]. This behaviour could be controlled by a buffer local
Jambu> variable.
Eric> This is an interesting suggestion. Next time I have time I will
Eric> but together a trail implementation to see how naturally this fits
Eric> into the rest of the Babel system. There could be issues
Eric> (e.g. how to do set header arguments for the headline).
Good to hear this.
I am attaching a mail that I had (accidentally) unicast to Sebastien
elaborating on the possibilities. This could be of interest to the list.
Jambu> If babel supports headlines as srcnames, without requiring additional
Jambu> begin/end directives one could just write,
Jambu>
Jambu> * org-list
Jambu> - one
Jambu> - two
Jambu> - three
Jambu>
Jambu> #+begin_src emacs-lisp :tangle yes :noweb yes
Jambu> "
Jambu> <<org-list(:fmt latex)>>
Jambu> "
Jambu> #+end_src
Jambu>
Jambu> and achieve similar results.
Jambu>
Eric> Yes, however the syntax you've used above to pass a header
Eric> argument to the org-lisp code block violates the existing noweb
Eric> syntax. The place where you've inserted ":fmt latex" is reserved
Eric> for passing regular arguments to code blocks.
That is precisely my point.
If org headlines are srcnames there is every reason that they take
arguments. See my attached mail that talks of implicit 'this' and ':fmt'
parameters.
I am not as concerned about the existing syntax, as the possibilities
that could potentially unfold with this mind-twister.
Eric> There has been discussion of allowing post-processing forms for
Eric> code blocks which would take the results of a code block as an
Eric> argument every time the code block has been called and whose
Eric> results would replace the actual code block results, however this
Eric> has not yet been implemented.
If headlines are considered as code blocks one actually inflate
headlines and execute them for interesting side-effects. The attached
mail elaborates on this point.
Thanks,
Jambunathan K.
Attachment:
[-- Attachment #2: Type: text/plain, Size: 4941 bytes --]
From: Jambunathan K <kjambunathan@gmail.com>
Subject: Re: Composing letters using Org mode and the LaTeX isodoc class
To: Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
Date: Wed, 08 Sep 2010 21:07:26 +0530
Message-ID: <81lj7cqma1.fsf@gmail.com>
Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:
> Hi Jambunathan,
>
> Jambunathan K wrote:
>> Honoring spaces would be a pre-requisite if one were to allow org's
>> headlines as implicit srcnames.
>
> Or you would have to impose titles without spaces, which is acceptable as well
> for such a usage...
>
Org is for humans. We need spaces (pun intended).
This is why I find CamelCase words in a text document quite awkward. On
the otherhand, I don't find it awkward as variable and function names in
source code.
Read on ... More comments down below.
>
>> If babel supports headlines as srcnames, without requiring additional
>> begin/end directives one could just write,
>>
>> * org-list
>> - one
>> - two
>> - three
>>
>> #+begin_src emacs-lisp :tangle yes :noweb yes
>> "
>> <<org-list(:fmt latex)>>
>> "
>> #+end_src
>>
>> and achieve similar results.
>>
>> Based on my earlier efforts at letter-writing, I have the following
>> observation.
>>
>> Letters have a To address and they could be pulled from bbdb. So one
>> could say,
>>
>> * To
>> [[a bbdb link]]
>>
>>
>> #+begin_src emacs-lisp :tangle yes :noweb yes
>> "
>> <<To(:fmt custom)>>
>> "
>> #+end_src
>>
>> The string custom could be a elisp form or a function pointer that takes
>> the body of the headline as an argument and does the needful.
>>
>> Specifically in the above example, 'custom' handler would visit the bbdb
>> record, fetch the address and return the formatted address (with line
>> breaks etc etc) as the noweb expansion. [Custom handler would be
>> implemented by the user himself]
>>
>> Any thoughts on how this could be achieved ...
>
> That's going (really) far... But would that be do-able, waaoow!
Yes it is going far.
Sometimes going far makes us feel elated while at other times it makes
us feel down and out ;-). In the present case, the experience would be
of the first kind. Otherwise would I dare suggest it?
I would provide an example and later summarize what the implications
are.
Before proceeding ahead we need to remember the following:
1. Headline in an org document is code.
That is I can call it.
It always has an implicit 'this' parameter which is the 'content of
the headline'. It could have additional parameters like :fmt as above
(with :fmt text or :fmt org) being the default values.
2. (1) implies that I can 'execute' an org file.
Now an example.
* Isodoc
[[Link to page 9 of isodoc.pdf]]
* Extract of Isodoc for ready reference
<Isodoc ()>>
Now if I execute the 'Extract ...' subtree I have essentially imported a
pdf page as text content.
In the above example, the execution of headline would do some sort of
extract pdf pages and/or pdftotext. If the link were actually a gmane
thread it would amount to doing 'w3m -dump ...'.
Let's now take it even a bit further.
It seems that there are a good number of people who use 'one org file to
rule them all'. It also seems fairly common that one version controls an
agenda or a working file. Then it naturally follows that one would like
to import a git controlled file as a headline node in the master
file.
This should be quite possible with the proposed enhancement.
* Agenda file
[[git url]]
* Agenda Node
<<Agenda file ()>>
Good thing is that I only need to tangle the headline to checkout the
agenda file on a remote server as a head line node. One could also think
of how one could git commit a headline node on the way out.
One could achieve Aliased Trees [1], Translations [2] and interesting
mashups like selective annotation [3] and agenda mashups[4]
[1] http://thread.gmane.org/gmane.emacs.orgmode/27108
Plain import headline in another headline
[2] http://article.gmane.org/gmane.emacs.orgmode/27534/match=translation
Tangling as language translation. Tangling a vocabulary node tangles
the headline nodes to be translated which in turn 'pull' in the
newly translation.
[3] http://thread.gmane.org/gmane.emacs.orgmode/24431/focus=24581
Requests like a master TODO file that is 'shared' by teams,
extracting text snippets from a file (that I don't have control
over) and possibly view it side-by-side with my annotation etc etc
have surfaced in the past in this mailing list.
[4] http://thread.gmane.org/gmane.emacs.orgmode/3273/focus=3274
Good thing is that all these workflows could be supported with little
effort and without impairing the simplicity and elegance of org-mode.
Jambunathan K.
[-- Attachment #3: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 15:38 ` Eric Schulte
@ 2010-09-08 21:26 ` Sébastien Vauban
2010-09-10 8:51 ` Eric S Fraga
0 siblings, 1 reply; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-08 21:26 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Eric,
"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>> Hmm, I don't know how complex isodoc is to configure, but I'd think that
>>> defining a custom latex class would be simpler than tangling out LaTeX
>>> code blocks, however maybe this will change once I've looked at and
>>> understood an example application.
>>
>> Isodoc is quite easy to configure, but it's through keyval mappings. I
>> don't know enough of Org to imagine being able to convert headings and
>> contents to keys and values, respectively...
>>
>> That does not mean it really is difficult. Just for me, the only accessible
>> way remained the Babel route.
>
> I see, I just wanted to ensure that wrapping content in code blocks was a
> last resort, but I agree using Babel in this way should be much easier than
> defining a new Org export backend or mucking with Org-mode internals. I'm
> very happy if Babel can help to further blur the lines between Org-mode
> usage and development in this way.
You prove me right, even simplifying the stuff by using a table. Why not using
Babel, then? ;-)
That does not mean I'm not interested by seeing other solutions to this
"problem"...
>>>> - because, in a way, that's quite logical. Here and there, you define
>>>> stuff. At the end, you just arrange them all in a way that fits well
>>>> the LaTeX class demands.
>>>>
>>>> Though, it's not just copying, the way Babel actually does with snippets
>>>> of code "à la Noweb". Hence, I really need at least the body to be in
>>>> real Org plain code, and be automatically converted to LaTeX, so that I
>>>> can make use of the tables, and all the Org markup.
>>>>
>>>> I'm sure Babel is able of that, mixing raw code with convertable code.
>>>> Just needs more thinking.
>>>
>>> I've just implemented export of org code blocks to ascii, latex or html,
>>
>> This is brand new, right? In any case, the real good solution to such a
>> problem, IMHO...
>
> Yes this is new, it actually only required a couple of lines of code to
> implement. However that means it may still be buggy.
Maybe. At least, I'm unable to tangle and execute your code since a couple of
hours (this noon, CET).
I've git pulled right now. Same as before...
>>> so the following should now (if I understood) allow the tangling
>>> behavior you've described
>>
>> Here, I just don't understand why you're choosing `emacs-lisp' as target
>> language for LaTeX code. Is there a reason for this, or just a typo?
>
> I do all my testing with emacs-lisp code blocks, as their sort of the
> simplest (at least for me/Babel) code block. Once it's working there it
> should extend to code blocks in other languages as well.
Clear... Thanks for the precision.
>>> note that the () on the end of the code block name in the noweb syntax
>>> means to insert the results of evaluating the code block (in this case
>>> latex) rather than the body of the code block itself.
>>
>> Understood! Thanks.
>>
>> FYI, I've git pulled once again 15 minutes ago (13:30 CET). My repo was
>> already up-to-date, but your code does not work for me...
>>
>> _Nothing is tangled anymore_... Not even if I explicitly state =:tangle
>> "AA.tex"= for example (with and without quotes ;-)).
As said, situation is stayed the same. Of course, I guess you did not have
time yet fixing that, if I can make the assumption you're responsible of the
change in tangle behavior.
> I've taken your excerpt and changed it so that it was tangling successfully
> on my system. The main problem was that there were many noweb references
> which pointed to outside of the example.
Sorry for that. I tried to keep the post as small as possible, knowing that
the other blocks could be find back in the previous post. Not smart from me,
it seems.
> The following does work on my system. Notice that it uses a table to hold
> the small components rather than wrapping each in it's own Org-mode block.
>
> There appears to be some lingering issues with converting the org block to
> latex, for me the first item in the list was missing, I'll try to take a
> look at this later today. However, hopefully this gets Babel far enough that
> at least the structure of an isodoc letter writing solution can be fleshed
> out.
The subject of your letter seems right: tangling is broken; at least on my PC.
So I don't understand why it works for you...
I can't get anything out anymore of the following:
--8<---------------cut here---------------start------------->8---
* From Eric
#+tblname: head
| To | Eric Schulte |
| Subject | Tangling is Broken |
| Opening | Hi |
| Closing | Best |
#+source: h-body
#+begin_src org :results latex
- one
- two
- three
#+end_src
#+begin_src latex :noweb yes :tangle yes :var h-to=head[0,1] :var h-subject=head[1,1] :var h-opening=head[2,1] :var h-closing=head[3,1]
\documentclass[11pt]{isodoc}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{isodoc-style}
\setupdocument{
to = {h-to},
subject = {h-subject},
opening = {h-opening},
closing = {h-closing}
}
\begin{document}
\letter{%
<<h-body()>>
}
\end{document}
#+end_src
--8<---------------cut here---------------end--------------->8---
It's your code, where I just renamed `body' in `h-body', so that I did not
interfere with previous code blocks.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-08 16:22 ` [BABEL][PROPOSAL] headlines as executable srcnames Jambunathan K
@ 2010-09-08 21:30 ` Sébastien Vauban
2010-09-09 15:38 ` Jambunathan K
2010-09-20 4:15 ` Eric Schulte
2 siblings, 0 replies; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-08 21:30 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Jambunathan,
Jambunathan K wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMSQIYZ4X/+iSw@public.gmane.orgrg> writes:
>> Jambunathan K wrote:
>>> [...] Any thoughts on how this could be achieved ...
>>
>> That's going (really) far... But would that be do-able, waaoow!
>
> Yes it is going far.
>
> Sometimes going far makes us feel elated while at other times it makes
> us feel down and out ;-). In the present case, the experience would be
> of the first kind. Otherwise would I dare suggest it?
Don't misinterpret me. I said far, not too far! I really desire such
possibilities as well... Simply, that's a huge integration, with great power.
In other words, go on with this idea, and implement it, or convince the right
people that can make this become real.
> I would provide an example and later summarize what the implications
> are.
Thanks for the other info as well...
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-08 16:22 ` [BABEL][PROPOSAL] headlines as executable srcnames Jambunathan K
2010-09-08 21:30 ` Sébastien Vauban
@ 2010-09-09 15:38 ` Jambunathan K
2010-09-09 16:30 ` Jambunathan K
2010-09-10 4:51 ` Jambunathan K
2010-09-20 4:15 ` Eric Schulte
2 siblings, 2 replies; 21+ messages in thread
From: Jambunathan K @ 2010-09-09 15:38 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
> Jambu> I think there is a strong case for making headlines act as babel
> Jambu> srcnames with their body providing content for noweb expansion
> Jambu> [3]. This behaviour could be controlled by a buffer local
> Jambu> variable.
I have some more thoughts on this. Let me capture it before it goes
away. My thoughts are fragmented and my only request is that it be noted
and embraced and extended when you hash out the final details.
I think value of Babel could be tremendously enhanced if '#+results ...'
are revisited and redefined.
So that not I sound too abstract, let us take an example.
Remember the recent thread [1] where there was a request to
automagically 'embed' the revision number of a document in an orgmode
file? This is what emerged as a solution that the original poster was
happy with.
> ,----
> | * revision control
> | The version of this file is
> | src_emacs-lisp{(vc-working-revision (or (buffer-file-name) org-current-: export-file))}.
> `----
IMHO, I believe there is an opportunity for improvement. What if the
actual solution ended up like the following ...
* Revision
#+begin_src emacs-lisp
(vc-working-revision (or (buffer-file-name) org-current-export-file))
#+end_src
# Variant-1:
* revision control
Version of the file is <<Revision()>>
# Variant-2:
Or better still something like this
* revision control
Version of the file [[<<Revision()>>][Rev-1]]
Following items are worthy of note:
1. The body of the headline is provided by executing the blocks
undeneath it.
Worth comparing this with the idea that emerged in the original post
- where the content of the headline is provided by the user (for
example a pdf link or body of a letter) and the results of the
execution is one that obtained by piping the results through a custom
exporter (latex)
2. In both cases there is no notion of a '#+results ' being created.
3. In Variant-2, the org's notion of what a link is redefined (Remember
extensible link syntax proposed by Samuel Wales).
Let's look at how the link is defined in the example
[[<<Revision()>>][Rev-1]]
The url portion of the link is actually a 'babel macro call' and
provides the content. Note how the macro call is embedded in the url
portion and there by hidden from human eye and Rev-1 provides a
placeholder. The special link face (or may be a 'babel macro face')
would let the user know that there are more things lurking
underground.
Time to get abstract ...
As I see it, removing 'extra levels of indirection' as the 'results of
source block' travel through org document more the Babel workflow would
seemlessly integrate with org's world view.
In some sense Babel would be more successful if it does it's offices
under the hood and not really make it's presence felt to the person
editing the document :-).
Footnotes:
[1] http://thread.gmane.org/gmane.emacs.orgmode/29690/focus=29792 [2]
Jambunthan K.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-09 15:38 ` Jambunathan K
@ 2010-09-09 16:30 ` Jambunathan K
2010-09-10 4:51 ` Jambunathan K
1 sibling, 0 replies; 21+ messages in thread
From: Jambunathan K @ 2010-09-09 16:30 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
In the context of 'expanding babel macros', I think it would be useful
to think of the context in which the babel macros are expanded.
For example, if the macro is expanded with 'point' at the point of macro
call then one would be able to pull in information from the current
subtree (like property, tags etc etc)
I was looking at this post -
http://www.mail-archive.com/emacs-orgmode@gnu.org/msg29961.html
and reference to the existing #+MACRO facility within orgmode and the
need for accessing properties etc triggered this post.
Hope I could be of some help even if my thougts are a bit fragmented and
in the clouds ...
Jambunathan K.
ps: In the version control example down below the only context is
filename and it doesn't matter where the 'point' is when the macro is
expanded.
> * Revision
> #+begin_src emacs-lisp
> (vc-working-revision (or (buffer-file-name) org-current-export-file))
> #+end_src
>
>
> # Variant-1:
>
> * revision control
> Version of the file is <<Revision()>>
>
> # Variant-2:
>
> Or better still something like this
>
> * revision control
> Version of the file [[<<Revision()>>][Rev-1]]
>
>
> Following items are worthy of note:
>
> 1. The body of the headline is provided by executing the blocks
> undeneath it.
>
> Worth comparing this with the idea that emerged in the original post
> - where the content of the headline is provided by the user (for
> example a pdf link or body of a letter) and the results of the
> execution is one that obtained by piping the results through a custom
> exporter (latex)
>
> 2. In both cases there is no notion of a '#+results ' being created.
>
> 3. In Variant-2, the org's notion of what a link is redefined (Remember
> extensible link syntax proposed by Samuel Wales).
>
> Let's look at how the link is defined in the example
>
> [[<<Revision()>>][Rev-1]]
>
> The url portion of the link is actually a 'babel macro call' and
> provides the content. Note how the macro call is embedded in the url
> portion and there by hidden from human eye and Rev-1 provides a
> placeholder. The special link face (or may be a 'babel macro face')
> would let the user know that there are more things lurking
> underground.
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-09 15:38 ` Jambunathan K
2010-09-09 16:30 ` Jambunathan K
@ 2010-09-10 4:51 ` Jambunathan K
2010-09-20 4:03 ` Eric Schulte
1 sibling, 1 reply; 21+ messages in thread
From: Jambunathan K @ 2010-09-10 4:51 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
I am slightly drifting a bit. I think the broader theme that is emerging
in this thread is this - how Babel as a Org's VM would enable one to
create useful text mashups. Call it Org 2.0 if you may like.
Needless, to say I am having a hammer and everything looks nail to
me. Please be patient with my regurgitations! Read on ...
,----
| "*Article*" #("From: Vinh Nguyen <vinhdizzo@gmail.com>
| Subject: Re: text color + highlight
| Newsgroups: gmane.emacs.orgmode
| To: emacs-orgmode@gnu.org
| Date: Thu, 9 Sep 2010 09:15:05 -0700
| Message-ID: <AANLkTinr_ZoRpygJPkSkYUo6pt1t3-ztOtHo32fnhscd@mail.gmail.com>
| Archived-At: <http://permalink.gmane.org/gmane.emacs.orgmode/30143>
|
| I'd like to write a concluding email for this thread for future
| searchers to find. This easy solution is brought to you by Eric
| Schulte and Christian Moe.
|
| Place the following in your .emacs or init.el file:
| ;; org-mode color
| (org-add-link-type
| \"color\" nil
| (lambda (path desc format)p
| (cond
| ((eq format 'html)
| (format \"<span style=\\\"color:%s;\\\">%s</span>\" path desc))
| ((eq format 'latex)
| (format \"{\\\\color{%s}%s}\" path desc)))))
| ;; org-mode highlight
| (org-add-link-type
| \"hl\" nil
| (lambda (path desc format)
| (cond
| ((eq format 'html)
| (format \"<font style=\\\"background-color:%s;\\\">%s</font>\" path desc))
| ((eq format 'latex)
| (format \"\\\\colorbox{%s}{%s}\" path desc))))) ;; require \\usepackage{color}
|
| Examples:
| [[color:blue][test this out]]
| [[hl:yellow][highlighted text]]
|
| Remarks:
| * Pros
| - don't need to modify org-mode source (just edit your .emacs)
| - use the existing links syntax
| * Cons
| - cannot be used concurrently or with other formatting
| * To Do
| - Hopefully it will be implemented via extensible syntax in the
| future ($[options mytext])
| - highlight and color paragraph or region
|
|
| -- Vinh
|
|
|
| On Thu, Aug 5, 2010 at 1:42 PM, Vinh Nguyen <vinhdizzo@gmail.com> wrote:
| > Dear list,
| >
| > I was wondering if there is an easy way to markup the color of the
| > text for html output (and highlight as well). When I prepare meeting
| > minutes I'd like to color some things and highlight certain things.
| > Right now, I am using emphasizing a major portion of the text. It
| > would be great to have colors and highlights to draw attention to
| > certain items.
| >
| > Thanks.
| > Vinh
`----
I wonder whether there is a way to achieve the requested feature without
too much of elisp programming.
[[color:blue][test this out]]
^^^^^ ^^^^^ ^^^^^^^^^^^^^
If one imagines this as a macro call
color => babel srcname [accessible through %0 in srcbody]
blue => param1 for srcname [accessible through %1 in srcbody]
test this out => text param for the macro ['this' param for text mashup]
In my earlier post, I tried to argue that if headlines could be srcnames
then the text content of the headline could be considered as an implicit
'this' param (which the 'headline macro' works upon)
Now if link syntax could be used as a macro call (as seen above) then
the description part of the link i.e., text contained within "inner []"
could be considered as the 'this' param for link-oriented
srcnames. (Think of links as mini, inline headlines and desc as headline
body)
It is important to note that the user still works with text documents
which are very much like existing org documents.
Note also that having positional params and having them canonically
accessible as %0, %1, %2 etc could have it's uses [1]. It is left to the
reader how color macro could be defined with above redefinitions.
Let me reiterate (and I think it is important) Babel's macro expansion
if tweaked and designed for 'text mashups and massages' then much of
user requirements (like the one above) could be implemented by the user
himself without any help from expert elisp programmers.
Footnotes:
[1] I believe babel as of this writing only permits named param list.
Jambunathan K.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-08 21:26 ` Sébastien Vauban
@ 2010-09-10 8:51 ` Eric S Fraga
2010-09-10 9:13 ` Sébastien Vauban
0 siblings, 1 reply; 21+ messages in thread
From: Eric S Fraga @ 2010-09-10 8:51 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Wed, 08 Sep 2010 23:26:15 +0200, Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
[...]
> The subject of your letter seems right: tangling is broken; at least
> on my PC. So I don't understand why it works for you...
Just to add a data point: this works for me with
: Org-mode version 7.01trans (release_7.01h.493.gece2)
: GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-08-14 on raven, modified by Debian
Time to learn isodoc as it looks very useful indeed!
Thanks,
eric
[-- Attachment #2: Type: text/plain, Size: 75 bytes --]
--
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
[-- Attachment #3: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Composing letters using Org mode and the LaTeX isodoc class
2010-09-10 8:51 ` Eric S Fraga
@ 2010-09-10 9:13 ` Sébastien Vauban
0 siblings, 0 replies; 21+ messages in thread
From: Sébastien Vauban @ 2010-09-10 9:13 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Eric,
Eric S Fraga wrote:
> On Wed, 08 Sep 2010 23:26:15 +0200, Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
>> The subject of your letter seems right: tangling is broken; at least on my
>> PC. So I don't understand why it works for you...
>
> Just to add a data point: this works for me with
>
> : Org-mode version 7.01trans (release_7.01h.493.gece2)
> : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-08-14 on
> : raven, modified by Debian
Thanks for the info.
But, as said in another posting, it was just me: I was so silly (or tired) to
fallback on the old key binding (C-c C-c) when trying to evaluate the blocks.
Of course, nothing happened...
> Time to learn isodoc as it looks very useful indeed!
I'll document this on Worg during the week-end, hopefully. And insert some
nice examples.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-10 4:51 ` Jambunathan K
@ 2010-09-20 4:03 ` Eric Schulte
2010-09-20 7:39 ` Jambunathan K
0 siblings, 1 reply; 21+ messages in thread
From: Eric Schulte @ 2010-09-20 4:03 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Hi Jambunathan,
So, if I'm understanding correctly, what you are proposing includes two
separate things, first, a new link-style syntax for calling code blocks,
and second, the ability to provide un-named arguments to code blocks.
I definitely agree that the second suggestion would be desirable. Even
if we still use named arguments when writing code blocks it should be
possible to supply un-named arguments when calling code blocks, and use
the order of the arguments to resolve their variable mappings. This has
been on our TODO list for some time and is just waiting for some
development time.
I'm less sure about expanding link syntax into a means of calling code
blocks. There has been some recent discussion on the list about
expanding link syntax (in fact related to the thread your referenced
below) and my impression was that there is far from unanimous support
for changing the semantics of links in Org-mode. Maybe this would be
appropriate as an optional extension to org, i.e. something in the
contrib directory.
Thanks -- Eric
Jambunathan K <kjambunathan@gmail.com> writes:
> I am slightly drifting a bit. I think the broader theme that is emerging
> in this thread is this - how Babel as a Org's VM would enable one to
> create useful text mashups. Call it Org 2.0 if you may like.
>
> Needless, to say I am having a hammer and everything looks nail to
> me. Please be patient with my regurgitations! Read on ...
>
> ,----
> | "*Article*" #("From: Vinh Nguyen <vinhdizzo@gmail.com>
> | Subject: Re: text color + highlight
> | Newsgroups: gmane.emacs.orgmode
> | To: emacs-orgmode@gnu.org
> | Date: Thu, 9 Sep 2010 09:15:05 -0700
> | Message-ID: <AANLkTinr_ZoRpygJPkSkYUo6pt1t3-ztOtHo32fnhscd@mail.gmail.com>
> | Archived-At: <http://permalink.gmane.org/gmane.emacs.orgmode/30143>
> |
> | I'd like to write a concluding email for this thread for future
> | searchers to find. This easy solution is brought to you by Eric
> | Schulte and Christian Moe.
> |
> | Place the following in your .emacs or init.el file:
> | ;; org-mode color
> | (org-add-link-type
> | \"color\" nil
> | (lambda (path desc format)p
> | (cond
> | ((eq format 'html)
> | (format \"<span style=\\\"color:%s;\\\">%s</span>\" path desc))
> | ((eq format 'latex)
> | (format \"{\\\\color{%s}%s}\" path desc)))))
> | ;; org-mode highlight
> | (org-add-link-type
> | \"hl\" nil
> | (lambda (path desc format)
> | (cond
> | ((eq format 'html)
> | (format \"<font style=\\\"background-color:%s;\\\">%s</font>\" path desc))
> | ((eq format 'latex)
> | (format \"\\\\colorbox{%s}{%s}\" path desc))))) ;; require \\usepackage{color}
> |
> | Examples:
> | [[color:blue][test this out]]
> | [[hl:yellow][highlighted text]]
> |
> | Remarks:
> | * Pros
> | - don't need to modify org-mode source (just edit your .emacs)
> | - use the existing links syntax
> | * Cons
> | - cannot be used concurrently or with other formatting
> | * To Do
> | - Hopefully it will be implemented via extensible syntax in the
> | future ($[options mytext])
> | - highlight and color paragraph or region
> |
> |
> | -- Vinh
> |
> |
> |
> | On Thu, Aug 5, 2010 at 1:42 PM, Vinh Nguyen <vinhdizzo@gmail.com> wrote:
> | > Dear list,
> | >
> | > I was wondering if there is an easy way to markup the color of the
> | > text for html output (and highlight as well). When I prepare meeting
> | > minutes I'd like to color some things and highlight certain things.
> | > Right now, I am using emphasizing a major portion of the text. It
> | > would be great to have colors and highlights to draw attention to
> | > certain items.
> | >
> | > Thanks.
> | > Vinh
> `----
>
> I wonder whether there is a way to achieve the requested feature without
> too much of elisp programming.
>
> [[color:blue][test this out]]
> ^^^^^ ^^^^^ ^^^^^^^^^^^^^
>
> If one imagines this as a macro call
>
> color => babel srcname [accessible through %0 in srcbody]
> blue => param1 for srcname [accessible through %1 in srcbody]
> test this out => text param for the macro ['this' param for text mashup]
>
> In my earlier post, I tried to argue that if headlines could be srcnames
> then the text content of the headline could be considered as an implicit
> 'this' param (which the 'headline macro' works upon)
>
> Now if link syntax could be used as a macro call (as seen above) then
> the description part of the link i.e., text contained within "inner []"
> could be considered as the 'this' param for link-oriented
> srcnames. (Think of links as mini, inline headlines and desc as headline
> body)
>
> It is important to note that the user still works with text documents
> which are very much like existing org documents.
>
> Note also that having positional params and having them canonically
> accessible as %0, %1, %2 etc could have it's uses [1]. It is left to the
> reader how color macro could be defined with above redefinitions.
>
> Let me reiterate (and I think it is important) Babel's macro expansion
> if tweaked and designed for 'text mashups and massages' then much of
> user requirements (like the one above) could be implemented by the user
> himself without any help from expert elisp programmers.
>
> Footnotes:
> [1] I believe babel as of this writing only permits named param list.
>
> Jambunathan K.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-08 16:22 ` [BABEL][PROPOSAL] headlines as executable srcnames Jambunathan K
2010-09-08 21:30 ` Sébastien Vauban
2010-09-09 15:38 ` Jambunathan K
@ 2010-09-20 4:15 ` Eric Schulte
2 siblings, 0 replies; 21+ messages in thread
From: Eric Schulte @ 2010-09-20 4:15 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Jambunathan K <kjambunathan@gmail.com> writes:
[...]
>
> If headlines are considered as code blocks one actually inflate
> headlines and execute them for interesting side-effects.
Rather than create new syntax allowing headlines to be interpreted as
Org-mode code blocks, we could implement this ability of finding and
extending headlines into a code block through the library of babel.
This would allow headlines to be expanded easily and concisely from
inside of other code blocks without having to make any changes or
extensions to Babel.
So for example
#+source: headline
#+begin_src emacs-lisp :var headline=top :results org
(org-open-link-from-string (org-make-link-string headline))
(save-restriction
(org-narrow-to-subtree)
(buffer-string))
#+end_src
could then be called from inside of a code block to insert the body of a
headline in the same file, e.g.
#+begin_src org
<<headline(headline="body")>>
#+end_src
This should be useful for easily including large portions of org-mode
files into code blocks for generating letters.
If this looks good, I'll add it to the library of babel so it's
universally available.
Best -- Eric
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [BABEL][PROPOSAL] headlines as executable srcnames
2010-09-20 4:03 ` Eric Schulte
@ 2010-09-20 7:39 ` Jambunathan K
0 siblings, 0 replies; 21+ messages in thread
From: Jambunathan K @ 2010-09-20 7:39 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
Eric
> Hi Jambunathan,
>
> So, if I'm understanding correctly, what you are proposing includes two
> separate things, first, a new link-style syntax for calling code blocks,
> and second, the ability to provide un-named arguments to code blocks.
>
> I'm less sure about expanding link syntax into a means of calling code
> blocks. There has been some recent discussion on the list about
> expanding link syntax (in fact related to the thread your referenced
> below) and my impression was that there is far from unanimous support
> for changing the semantics of links in Org-mode. Maybe this would be
> appropriate as an optional extension to org, i.e. something in the
> contrib directory.
>
I think I am converging towards having a new 'babel: ' URL scheme.
Requests like colorization, inserting version control information etc on
export rightfully falls under one-off request and a babel: URL scheme
would help achieve all these without any hassles.
In 'babel: ' URLs, the 'path' param is likely to contain a call-site
(srcname) and key,val pairs (for named params). I think one can use or
draw inspiration from standard http URL encoders that posts HTML forms.
My ideas are not fully formed and I refine as I go along... Please be
tolerant.
Jambunathan K.
>> ,----
>> | "*Article*" #("From: Vinh Nguyen <vinhdizzo@gmail.com>
>> | Subject: Re: text color + highlight
>> | Newsgroups: gmane.emacs.orgmode
>> | To: emacs-orgmode@gnu.org
>> | Date: Thu, 9 Sep 2010 09:15:05 -0700
>> | Message-ID: <AANLkTinr_ZoRpygJPkSkYUo6pt1t3-ztOtHo32fnhscd@mail.gmail.com>
>> | Archived-At: <http://permalink.gmane.org/gmane.emacs.orgmode/30143>
>> |
>> | I'd like to write a concluding email for this thread for future
>> | searchers to find. This easy solution is brought to you by Eric
>> | Schulte and Christian Moe.
>> |
>> | Place the following in your .emacs or init.el file:
>> | ;; org-mode color
>> | (org-add-link-type
>> | \"color\" nil
>> | (lambda (path desc format)p
>> | (cond
>> | ((eq format 'html)
>> | (format \"<span style=\\\"color:%s;\\\">%s</span>\" path desc))
>> | ((eq format 'latex)
>> | (format \"{\\\\color{%s}%s}\" path desc)))))
>> | ;; org-mode highlight
>> | (org-add-link-type
>> | \"hl\" nil
>> | (lambda (path desc format)
>> | (cond
>> | ((eq format 'html)
>> | (format \"<font style=\\\"background-color:%s;\\\">%s</font>\" path desc))
>> | ((eq format 'latex)
>> | (format \"\\\\colorbox{%s}{%s}\" path desc))))) ;; require \\usepackage{color}
>> |
>> | Examples:
>> | [[color:blue][test this out]]
>> | [[hl:yellow][highlighted text]]
>> |
>> `----
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2010-09-20 7:40 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-07 11:36 Composing letters using Org mode and the LaTeX isodoc class Sébastien Vauban
2010-09-07 18:46 ` Jambunathan K
2010-09-07 19:45 ` Sébastien Vauban
2010-09-08 0:56 ` Eric Schulte
2010-09-08 1:52 ` Thomas S. Dye
2010-09-08 4:39 ` Jambunathan K
2010-09-08 11:48 ` Sébastien Vauban
2010-09-08 15:15 ` Eric Schulte
2010-09-08 16:22 ` [BABEL][PROPOSAL] headlines as executable srcnames Jambunathan K
2010-09-08 21:30 ` Sébastien Vauban
2010-09-09 15:38 ` Jambunathan K
2010-09-09 16:30 ` Jambunathan K
2010-09-10 4:51 ` Jambunathan K
2010-09-20 4:03 ` Eric Schulte
2010-09-20 7:39 ` Jambunathan K
2010-09-20 4:15 ` Eric Schulte
2010-09-08 11:45 ` Composing letters using Org mode and the LaTeX isodoc class Sébastien Vauban
2010-09-08 15:38 ` Eric Schulte
2010-09-08 21:26 ` Sébastien Vauban
2010-09-10 8:51 ` Eric S Fraga
2010-09-10 9:13 ` Sébastien Vauban
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).