Re: Emacs in build-depends of python2.1
"Sean 'Shaleh' Perry" <shalehperry@attbi.com> 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 debian-python-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: