>>>>> "S'P" == Sean 'Shaleh' Perry <[EMAIL PROTECTED]> writes:
S'P> The problem is we now have a piece of a fairly common package
S'P> using script(s) in a language few understand. So if you get
S'P> hit by a bus someone WILL have to reverse engineer that script.
S'P> This is the same reason I dislike build-essential requiring
S'P> Haskell. It is a fine language but the number of people in
S'P> Debian who speak it is probably about 20 or 30.
S'P> In essential we have sh, sed and awk guaranteed. Just beyond
S'P> that is perl and python. Then there is C(++). Once you move
S'P> beyond these the chances of the typical developer being able to
S'P> debug, help, or rewrite is small. elisp is even more
S'P> specialized then just lisp. And yes it is annoying when you do
S'P> 'apt-get --build python' to discover suddenly that emacs is
S'P> going to be installed if for no other reasons than the build
S'P> system just gained another 50+mb in size (some of us use
S'P> chroots on smaller drives).
A few years ago, there was no Python Info documentation and all that was
available was a no longer working Perl conversion script. I just needed
Python Info documentation with as low work invested as possible.
I understand the `apt-get --build' argument. I encourage anyone to
rewrite the script to whatever he wants if he is going to *maintain* it.
Don't expect me to maintain anything requiring more work than the Elisp
script -- I'm busy with too many things. I need Python documentation in
the Info format and that is a big priority over all other practical
matters. If anyone implements a better solution, I'll be happy, since I
won't have to care about the issue anymore. But I wouldn't like to end
up in the original situation -- no Info documentation and an obsolete
Perl script or so.
As Florent has already pointed out, the Elisp solution is quite easy.
You know, Emacs is a powerful text processor, has got an excellent
interactive debugger and some Texinfo support. I think implementing and
maintaining the task in Python would require much more work, but as I've
said that's completely OK for me as long as it's not my work.
S'P> Once you move beyond these the chances of the typical developer
S'P> being able to debug, help, or rewrite is small.
Please note that at the time I wrote the first version of py2texi.el,
*nobody* was going to debug, help, or rewrite the obsolete Perl script.
So your argument is valid only if more than one person cares *seriously*
about the issue.
BTW, if you're looking for a really nice and practical solution, you
should convince/help Python documentation team to switch to another
source format. LaTeX is really bad choice for such a documentation.
Regards,
Milan Zamazal
--
http://www.zamazal.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
