* elx-common.c: new file for common file handling and token / symbol
output.
* elx.h: expanded for new functions in elx-common.
* elx-java.c: switch to using a context for the files, and rely on the
common functions to open/close and output stuff.
* elx-python.c: switch to using a context for the files, and rely on
the common functions to open/close and output stuff. the
identifier that we fetch is now null-term'd, so don't bother with
a bunch of stuff to null-term it.
* scanner.c: null-term the identifier.
* elx_html.py: generate a full page, not just a body. use buffers to
reference slices, rather than constructing slices. (and some test
code to try binary files)
* add a couple .cvsignore files
git-svn-id: http://viewvc.tigris.org/svn/viewvc/trunk@504 8cb11bc2-c004-0410-86c3-e597b4017df7
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
cmpilato