"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > The problem is we now have a piece of a fairly common package using > script(s) in a language few understand. So if you get hit by a bus > someone WILL have to reverse engineer that script. This is the same
Well, I guess you mean "py2texi.el's upstream maintainer" instead of "you". Has someone had problems contacting him? Does his script often break? The home page, <http://www.zamazal.org/software/python/py2texi/>, is mentioned at the beginning of py2texi.el. Now, for "reverse engineer", I think you are a bit harsh. I read py2texi.el from top to bottom, and I must say it's quite tidy for that kind of hack (as I already said, converting (La)TeX to something else without using the TeX engine is not an easy task if you want it a bit robust). At least, it is not so "ugly" as mentioned in the Commentary. Judging from the source not-so-bad-quality and (FWIW) from the "Copyright (C) 1998, 1999, 2001, 2002 Milan Zamazal", I think py2texi.el is maintained. Am I wrong? > I understand you not feeling the need is high to change now. But bear these > thoughts in mind in the future. I understand the chroot issue. I won't accept arguments about Emacs or py2texi.el sucking: py2texi.el looks well written for what it is supposed to be; I think it performs a reasonably good job. I thought a bit about a python implementation while reading it. It would probably be a *bit* tedious, for the following reasons: - regexp lookup/insertion/edition capabilities in Emacs buffers are heavily used. Efficient insertion in Python would probably mean using lists to represent the document (because strings are immutable, so repeatedly inserting/replacing small strings into the whole document's string, having all the includes recursively expanded would be quite bad) or something like (c)StringIO. But then you have to do heavy regexp matching on the whole doc, so your list idea is not so great any more. StringIO seems to do the trick, though. Then you have to adapt carefully all the regexps and their context of operation. Tedious, for sure. - py2texi.el uses /text properties/ to protect verbatim environments from being fscked up by later processing. These would have to be hacked into or emulated on top of StringIO, I think. - py2texi.el is not completely self-contained, but calls texinfo-all-menus-update from the 50Mb-or-so Emacs package you've happily installed. This is used to build the individual menus for each node of the info file that has menu entries as well as for updating all the nodes references to each other. Doesn't look very hard conceptually, I think you just have to be able to parse the doc and get its structure (the nodes have to refer to each other in the info file as previous, next, up, etc.; yes, this leads to somewhat redundant informations). These are the implementation quirks. Now: - is it the only .el file used in the whole Python build? - are you sure the locally-and-not-installed python binary would be able to use modules like re, StringIO, etc.? - does someone actually use these info files, which are not supported by upstream and may be incorrect: "The result code is ugly and need not contain complete information from Python manuals. I apologize for my ignorance, especially ignorance to python.sty" due to the difficult nature of such a conversion? -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
