nuweb.py Files

I've been frustrated by trying to fix problems in nuweb[1]. It can be
really hard to work out how to make a change - for example, how to fix
bug 2965157[2] - if it is indeed a bug!

Part of this is down to the fact that nuweb is implemented in C, but I
think that mostly it's because we developers haven't treated it as a
proper Literate Programming project. There ought to be some
explanation of why (referring to 2965157 again) there's a scrap
reference inside the parameter list. I think (from discussions on the
nuweb-users mailing list) that it was deliberate, but I see no clue as
to the intention.

As another problem (far from the only one!), what is a block comment?

Anyway, to scratch this itch I've been reworking nuweb in Python.

There are no files to download yet, but you can access the code
repository ubder the Code tab.

So far, the parts implemented are:

* files (@o and @O, but no flags)
* fragments (@d and @D, but no flags)
* scraps (delimited by @{ @} only)
* user-defined identifiers
* old-style fragment parameters
* indices @f, @m and @u (I've laid @u out a little differently)
* @% (anywhere in the document, not just in scraps)
* @# (put code line at left margin)
* @@ handling (this one was tricky, and I may not have caught all the cases)
* switch -r (generate hyperlinks), aliased --hyperlinks.

It won't handle the current nuweb.w, because that web uses new-style
parameters. However, it will process it and generate LaTeX. nuweb.w
reveals one shortcoming in the Python version, which is that it's slow
at processing user-defined identifiers. It takes 8s on this Macbook
Pro to process nuweb.w, against 0.07s for the C version. The fix for
this (if it's worth it; the other webs I have take about a second
overall, which isn't very painful) may be to implement the string
search which nuweb.w uses [3], though a quick trial of acora[4]
suggests that a pure Python implementation will be slower than the
current re-based implementation in nuweb.py.

So why haven't I written nuweb.py as a web? I suppose the answer is,
that I've been exploring the problem while writing the code, which
doesn't seem to be a very `literate' approach. Now that the overall
structure is reasonably clear, maybe it can be webified. That would at
least force me to provide some user-oriented documentation!

[1] http://sourceforge.net/projects/nuweb/
[2] http://sourceforge.net/tracker/?func=detail&aid=2965157&group_id=7449&atid=107449
[3] http://en.wikipedia.org/wiki/Aho–Corasick_string_matching_algorithm
[4] http://pypi.python.org/pypi/acora