[O] [BABEL][PATCH] ob-lilypond basic mode - was ob-lilypond

[Martyn Jago]

Hi

I've added functionality to make ob-lilypond act in a consistent org-babel way by default (think ob-dot).

The previous modus operandi is now known as arrange-mode and is selected by setting ly-arrange-mode to t

More details including examples are at http://github.com/mjago/ob-lilypond

Patch: 

basic-mode.patch
Description: Binary data

Included examples are as follows...

 - Export org file with lilypond fragments to pdf using eps (high quality vector graphics)

   - org source: https://github.com/mjago/ob-lilypond/raw/master/examples/basic-mode/pdf-example/pdf-example.org

   - resultant pdf: https://github.com/mjago/ob-lilypond/blob/master/examples/basic-mode/pdf-example/pdf-example.pdf?raw=true

 - Export org file with lilypond fragments to html using png

   - org source: https://github.com/mjago/ob-lilypond/raw/master/examples/basic-mode/html-example/html-example.org

   - resultant html: https://raw.github.com/mjago/ob-lilypond/master/examples/basic-mode/html-example/html-example.html

Regards

Martyn

On 1 Jul 2011, at 13:01, Christian Moe wrote:

On 6/30/11 8:10 PM, Eric Schulte wrote:

Martyn Jago<address@hidden>  writes:

(...)

Great, I've just moved this into the Org-mode core and added it to the

list of Babel languages.

Great!

One distinction that has occurred to me (especially following comments on

the mailing list) is that of "babel language" and "babel language work-flow".

In other words, I can visualise refactoring ob-lilypond to be no more than

a specification of the Lilypond syntax, and working in parallel, on a

work-flow implementation for Lilypond that is "opinionated" in terms of

adjusting org-babel settings away from their defaults / removing work-flow

noise etc. ( org-lilypond.el ) ? Would this make sense, and if so where would

it live (aligned to org-babel / a native Emacs mode perhaps)?

I hope that makes sense.

That sounds like a good idea.  Ideally ob-lilypond should include just

those elements expected by the code block interface, namely functions

for session/external evaluation, for expanding variables in code block

bodies, and for returning results to Org-mode.  I think that it would be

a good idea to develop an external org-lilypond to support a more

comprehensive workflow.

I like this.

I certainly see that the already complex task of making arrangements like those in Martyn's examples should be made as easy as possible.

As for the comparatively simple use cases I brought up, once they're supported by ob-lilypond I'd be perfectly happy to throw header arguments at them.

Yours,
Christian