* 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 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
* [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: [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: [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-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
* 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: 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: 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
* 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: 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
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).
