nuweb.py

************ * 20131112 * ************ Fixed bug 3 (see [1]) - (@% eats leading white space). Fixed bug 4 (see [2]) - (Multiple definitions shouldn't appear as uses). [1] https://sourceforge.net/p/nuweb/nuweb-py/tickets/3/ [2] https://sourceforge.net/p/nuweb/nuweb-py/tickets/4/ ************ * 20131013 * ************ Fixed bug 2 (see [1]) - (Hyperlinks always include the letter). [1] https://sourceforge.net/p/nuweb/nuweb-py/tickets/2/ ************ * 20130419 * ************ 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. 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