It would be cool if we added syntax highlighting to the docs with source-highlight: http://www.gnu.org/software/src-highlite/

1. we'd need to add lilypond to their list of languages.
2. we'd need to make lilypond-book put [verbatim] portions of @lilypond into a separate file (like 9a/lily-b462395f.texidoc or 9a/lily-b462395f-systems.texi)
3. we'd need to add it to the build system

Estimated times: 1. (Frog) 5 hours, assuming familiarity with syntax highlighting definitions 2. (Frog) 10 hours, assuming familiarity with python but no previous knowledge of lilypond-book 3. (me) 10 hours, assuming that the above two tasks were done correctly and that I don't run into any unforseen problems in the build system, hahahaha sob.

If other people do #1 and #2, then I'll treat #3 as a personal priority-High task.

I'm starting #1. Will post my language file here before submitting it upstream.

It seems that Valentin has dropped this issue, right? I'd like to do #1. I've already started the basics (comments, strings, operators).

I'll post a draft of the file here as soon as it's ready.

Final draft here: http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00682.html

source-highlight now supports lilypond synthax, here's the commit: http://git.savannah.gnu.org/cgit/src-highlite.git/commit/?id=7356b4a61659d2031034eff21c9ca2745e2a1e21

Maybe we'd better use python-ly, once syntax highlight is supported (it's in the TODO list): https://pypi.python.org/pypi/python-ly/

you can install it with: pip install python-ly

ly --help shows how to use it

Wilbert is fast :-) Version 0.3 of python-ly supports highlighting, example: ly highlight *.ly -o 'html/?.html'

We'll have to figure out how to include it in lilypond-book.. Our documentation pages should include only the text within the body tags and the CSS rules should be included in a linked file (currently the CSS rules are embedded in each file).

In my old and outdated html-export branch of Frescobaldi you can select whether to export a full document or only the body. That's what we use for code examples on lilypondblog.org, and the output is enclosed in a tag.

It should be possible to implement such a switch in python-ly, which should be better than coming from the other end and try to extract only the body part.

I think LilyPond-book extracts the LilyPond pieces from HTML and then calls LilyPond on it. It could also call a command to created highlighted source from the same pieces.

You can also import ly.colorize from within your python script and have more fine-grained control over how the HTML is generated.

Recent comment from Urs:

For lilypond-devel: We had talked about this option for the LilyPond manuals. Having had my first experience I think we should give that another thought. Have a look at the commit https://github.com/openlilylib/openlilylib/commit/568c3ef1c70dfa5619ae3a5c20ff78e1cc5a6eb2 to see how "much" code was necessary to achieve that.

I don't know the documentation build process, so I don't know where one could put that step in. What's necessary is to run python code to convert simple

This approach seems reasonable to me (but i don't really have experience with such issues).

Personally, I think it more important to link the sources to the images using the point-and-click information. Of course, that is an entirely orthogonal issue. Perhaps highlight the respective click area in the image when you have a mouse-over on the corresponding text? No idea what HTML/CSS might make feasible here.

Yes, definitely a different issue. You suggested using image maps to link from image to text (issue 2578). I don't know if linking from text to image would be possible

See comment 2578#6 I think that 2578 is more useful than syntax highlighting. Can we avoid any conflict? Should we block this issue until 2578 has been fixed?

I also think 2578 as more useful than syntax highlighting but I don't currently see that the implementation of one would interfere with the implementation of the other.

The worst that can happen is that we have implementations of both and then need to choose which of the two to use for which format of our manuals.

But frankly, I think that integrating either with the manual producing process is probably trickier than combining the two.

So I don't think that we should bother blocking either issue for the other. If anybody wants to work on either, that's going to be an improvement.