[Orgmode] Re: Composing letters using Org mode and the LaTeX isodoc class

[Eric Schulte]

Hi,

Jambunathan K <address@hidden> 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.