Dirk Laurie wrote: > Recently something has happened to TeX that should change the way we > are thinking. This is the fact that LuaTeX has reached Version 0.50.
<Introduction to LuaTeX snipped> > Currently an M-Tx user relies on: > - A preprocessor written in Pascal, compiled to be a stand-alone > executable, which is different for every operating system > - PMX, which is written in Fortran, compiled etc, different etc > - musixflx, which is written in C, compiled etc, different etc > > I have on two occasions asked on this list whether anybody wants to > help me convert M-Tx to Python. Christian Mondrup convinced me that > we shouldn't, as outside the Unix world people don't already have Python > anyway. > > The objection does not apply to LuaTeX. All recent TeX distributions > have it, maybe at this stage only as an optional extra, but it is being > billed as the "next generation TeX engine". +1 Although I haven't played with it yet, LuaTeX is now in MiKTeX (since 2.9), so Windows is covered, and TeXlive, so the rest of the world (!!) is covered. > If we had LuaTex in 1992, musixflx could have been implemented in Lua > and there would be only one TeX pass. > If we had LuaTeX in 1996, PMX could have been implemented in Lua and > there would not have been pmxa and pmxb passes. > If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and > there would not have been a prepmx pass. Absolutely - this is the greatest potential strength of LuaTeX - a proper programming language rather than a slightly weird (and fun!) macro language. Note that your utopia of one pass is not necessarily a given - admittedly MusixTeX can probably be structured to do musixflx "as it goes" but for other auxiliaries (such as makeindex or LaTeX cross-references) it would be very hard to do this. You need to be able to reset TeX (and ensure that in the first pass your \output routine isn't emitting any pages). > Now it is 2010 and we do have LuaTeX. > > We can go on as we used to: regard musixflx as cast in concrete, rely > on Don to keep maintaining PMX (nobody else except me, as far as I know, > has contributed even one line of Fortran code to it) and hope that someone > occasionally tweaks M-Tx to take account of some recent PMX feature (that > person is no longer me). musixflx is not a big program - it really shouldn't be necessary to leave it cast in stone in C. > Or we can gradually convert more and more of the functionality of these > packages into LuaTeX, thus taking advantage of the fact that the next > generation of TeX package writers will be fluent in it and will be able > to maintain the software. A single package luamusix.sty will do everything. > > I think the choice is obvious. Don't you? Wholeheartedly agree! Frankly, I think that much of the internals of the more complex TeX packages will gradually be moved to Lua (as an infinitely more sane language!). David ------------------------------- [email protected] mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
