grammar. Forget it for now, and checkpoint what I've done.
The elx-python and elx-java programs produce "element" text files
which can then be consumed by elx_html.py to produce syntax-colored
HTML output. elx_page.sh is a little wrapper around that to produce a
full page.
The Python stuff seems quite fine, and is blazing fast (the scanner
runs over 100k lines/second). The Java grammar is horked, so it does
work (the Java scanner seems fine; just the grammar).
Lots more to do on this, but I'm out for the weekend, so this it's
time to check point this. Maybe someone will have better ideas on how
to fix the Java parser. Note that this stuff requires the 'msta' and
'shilka' programs from the 'cocom' toolkit.
I still need to package this up nicely (some copyright/license
notices, better makefiles, some minimal doc, etc). I also want to mess
around with profiling the syntax coloring. It appears to be a bit
slower than enscript right now, but it shouldn't be since we've
already parsed the file by that point (gonna try binary element files,
and some perf improvements to elx_html.py).
General theory: write elx-* for any language needing cross-referencing
capabilities (things that only need hiliting can continue to use
enscript). The elx-* programs can be implemented in any fashion, as
long as it produces the element description file. Python, Perl, pure
C, automated scanner/parser, whatever.
Future steps include using the element description file to get
function names, to index them, and to feed that into the HTML
generation. It would also be quite possible to feed the element
descriptions right into a database and query from there.
git-svn-id: http://viewvc.tigris.org/svn/viewvc/trunk@498 8cb11bc2-c004-0410-86c3-e597b4017df7
gstein