Re: Broken link at http://www.gnu.org/software/texinfo/

[John Mandereau]

On 2008/07/05 18:50 -0500, Karl Berry wrote:
> Indeed.  It is not an easy problem, though.  Every space in the input is
> potentially significant.  Macros complicate things enormously.  Backward
> compatibility has to be 100%.  The current code fundamentally intermixes
> reading and writing (it was never designed to output anything but Info),
> and so is extremely hard to use as a model or even generally comprehend
> (at least for me).  And so on and so forth ...

I'm not sure it would be a reasonable effort to make a 100 % backward
compatible reimplemention at first go.  A more reasonable primary goal
is a clean and well-designed implementation that parse without errors
almost all existing valid Texinfo documents, and that has only roughly
has the behavior as current makeinfo.  Only when this is done, it is
reasonable to start resolving incompatibilities.  I may be wrong, but
IMHO it's only possible to tackle the huge task of reimplementing a big
program and simultaneously dealing with backward compatibility with a
lot of development resources.


> I made some abortive efforts at starting a rational reimplementation
> years ago (long-time members of the mailing list may remember previous
> discussions on the subject) but never got anywhere significant.  It
> seems I'd have to stop everything else I'm doing to have enough time and
> focus to write such a thing, and I don't see that happening, ever.

I'm prepared to stop everything else in a part of my holidays, but not
more than two weeks per year :-p  I hope I'll have enough view on the
long term to be able to make continuous progress.


> Non-English documents are another huge unsolved problem with the overall
> Texinfo system.  But I digress.

That's precisely what motivates a reimplementation of makeinfo : we need
a Texinfo parser that builds data trees that represent Texinfo
documents, to play with for managing translations. Even if I (or we)
fail at writing a fully backward compatible program, we'll have at least
a parser that can be used in these situations, which is far better than
using Python regular expressions :-p


> FYI, another contributor sent me a --internal-links option, to dump out
> index/toc terms as a tsv file.  It probably wouldn't be impossible to
> dump out the node/section tree too.  Not that I've looked into it, and
> since you've already switched it doesn't matter.

No, we haven't switched on out Git master branch, but nearly 80 % of the
work has been done by Patrice and Reinhold, and this work will probably
be useful for a couple of years :-)


>     3) is precisely what is making us switch to texi2html.
> 
> Oh?

Some people among LilyPond users and contributors want eye-candy, "bells
and whistles" that texi2html can provide with least effort :-p.  More
seriously, the main motivation to switch to texi2html is that we want to
split HTML documentation at arbitrary levels, and at different levels
depending on each chapter.  That might sound a bit unreasonable at first
sight, but so much effort is done on Lily docs these days that we must
find a way to organize a growing number of pages of docs -- more than
1100 pages in PDF format currently, including music scores samples.


>     it will take years to achieve if I'm the only (programming amateur)
>     guy on this.
> 
> Given that I've wanted to rewrite it from scratch for over a decade now,
> "years" doesn't sound so bad :).

It partly depends on what discipline I'm going to study and work in the
coming years: math, or other disciplines including IT.  Working on
makeinfo will be easier if I study IT of course.  I'll know more about
this in a few weeks.


> A "call for help" has existed for years in various places.  The effort
> required requires so much dedication to get started so "random"
> contributors aren't likely to help much, IMHO.  The core has to exist,
> and I think it can only work if it's the vision of a single person, or
> at most a couple people working very closely.

I don't have a precise vision right now, though I've already written
paper drafts.  Here's a list of possible development stages (that will
probably overlap in time):

1) write a parser, which would generate a data tree in Scheme for a
Texinfo document -- this stage already involves GUILE interfacing with
the main compiled language;

2) write a rough text output backend in the main compiled language --
and maybe an Info backend based on the text backend -- without any
possibility of customization at this stage, but keeping in mind
customizability will be added later;

3) write some sample scripts showing possible usage of parsed Texinfo
source (outputting a tree of nodes, rewriting some tools I wrote in a
ugly way in Python for translation

4) Write support for customizing formatting of a backend, and start
writing a customizable HTML backend.

Of course all this needs to be elaborated and refined as it goes.  The
"main compiled language" probably refers to C++: it's the language I
know best besides Python, even if I'm far from being a master, and it is
probably nearly as widely implemented as C.


> Well, it can't hurt to do a copyright disclaimer in any case,

Yes, please.


>  though I
> fear I've been too discouraging ...

It seems you haven't been enough :-)

John