X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil] ["3408" "Mon" "8" "February" "93" "21:42:33" "CET" "Frank Mittelbach" "MITTELBACH@MZDMZA.ZDV.UNI-MAINZ.DE" nil "63" "Re: Makeindex reimplementation" nil nil nil "2"]) Return-Path: Received: from sc.ZIB-Berlin.DE (mailserv) by dagobert.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 ) id AA26066; Mon, 8 Feb 93 21:41:59 +0100 Received: from vm.urz.Uni-Heidelberg.de (vm.hd-net.uni-heidelberg.de) by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/19.6.92) id AA02339; Mon, 8 Feb 93 21:41:56 +0100 Message-Id: <9302082041.AA02339@sc.zib-berlin.dbp.de> Received: from DHDURZ1 by vm.urz.Uni-Heidelberg.de (IBM VM SMTP V2R2) with BSMTP id 0621; Mon, 08 Feb 93 21:42:51 CET Received: from DHDURZ1 by DHDURZ1 (Mailer R2.08 R208004) with BSMTP id 6610; Mon, 08 Feb 93 21:42:47 CET Received: from DHDURZ1 by DHDURZ1 (Mailer R2.08 R208004) with BSMTP id 6608; Mon, 08 Feb 93 21:42:44 CET Reply-To: Mailing list for the LaTeX3 project Date: Mon, 8 Feb 93 21:42:33 CET From: Frank Mittelbach Sender: Mailing list for the LaTeX3 project To: Multiple Recipients of Subject: Re: Makeindex reimplementation Status: R X-Status: X-Keywords: X-UID: 958 > I'm not sure what Dominik's impersonator means by `running through open doors', > but when I read `Rewrite of Makeindex in WEB', I was overjoyed; if something is > written in Pascal-WEB, I can (a) understand it; (b) write or modify change- > files for it; and (c) fix it if it doesn't work (sometimes!). And, given the > existence of WEB-to-C, those sites that prefer to work and think in `C' can do > the same. But if something is written in CWEB, it is absolutely useless to me, > for there is no equivalent CWEB-to-Pascal. Given this distinct asymmetry, is it > not reasonable to regard Pascal-WEB as the standard, and to continue to use it > as the primary distribution medium, using WEB-to-C for those sites or systems > where a decent Pascal compiler does not exist, or where the received wisdom > dictates a preference for `C'? I do agree with Phil; my understanding of this task was not to port it to C-WEB but rather to integrate it into the standard web files that make up a good TeX system. I don't believe that anything else makes much sense. There is a big advantage of having all TeX programs written in the same language because this allows to easier maintence of change files because most of them have to deal with similar problems. If C-WEB would be used there would be no advantage at all except perhaps in making the code more transparent because of a better documentation. But on most systems one would need to maintain just another WEB system. However, if it would be rewritten in standard WEB (ie in PASCAL) then one can make use of the WEB to object system that has to be maintained anyway on that particular system, eg TANGLE and Pascal, or web2c and cc, or whatever. > Finally, the question of Makeindex 3.0.8. This exists, and includes > Joachim's *very important* sorting and multilingual extensions. But > I don't know that Joachim has ever made this version public. (I have > a copy.) These extensions are extremely powerful, useful, and have > a direct bearing on BibTeX. It would be absurd if BibTeX and > Makeindex handled custom sorting differently, and since Joachim's > extensions are powerful, general, and already written, I think they > should be merged into BibTeX as they are. (All subject to a > discussion of Joachim's paper on his methods, and an agreement that > this approach is suitable; I think it is.) I do agree with Dominik and I think Dave should contact Joachim and there should also contact with Oren (Joachim are you on this list?) Merging the sorting mechanisms of BibTeX and Makeindex or at least use the same algorithms seems very sensible (by the way another reason to keep everything in the same language, isn't it?) But before there is any rewrite, one clearly has to ask first what kind of syntax is necessary and what features need to be supported. This is very much related to the volunteer task about `research on indexing commands' which is unfortunately so far without any interest. I think that a lot of time could be saved and better results can be achieved if we first evaluate the needs and provide some syntax and functionality proposal and then discuss this with interested parties (this could be done using this list for example) and afterwards jump into the cold water and implementing the stuff. I will say more about the purpose and the idea behind all these volunteer tasks in my answer to Paul's mail. Frank