Re: bad makeinfo slowdown

[Patrice Dumas]

On Sun, Nov 07, 2010 at 03:43:12PM -0800, Per Bothner wrote:
> 
> However, I'm not sure that being able to customize the HTML output
> (which Patrice indicated is the primary benefit of the rewrite)
> should be a goal of makeinfo.  That seems to require some new
> customization framework/language, that will have to be designed,
> documented, and tested.  One starts out with simple ways to
> customize the output - no problem.  Then people want more complicated
> re-writes, conditional processing, re-arranging of text, and you
> end up with a general-purpose text transformation system.  (At least
> if you give your users what they want!)

That's pretty much where we are heading to, with a tree which is rather
generic as the object that generalizes the texinfo language.  Yet it 
embeds the specificities of Texinfo.

An important constraint is to do the Info output.  It is a very different
language than XML.  So going down the road of something generic allows
to have a clean code that does both output.  makeinfo in C was centered
around Info, texi2html around HTML/XML, hopefully the new Parser will be
neutral and more general-purpose for generated output.

> could be used.  xhtml has the advantage that more people are
> familiar with it, and it is displayable as-is; docbook has the advantage
> that it is closer semantically to texinfo, and we have powerful
> tools for processing and customizing docbook.

The issue with docbook is that it is not completly compatible with
Texinfo.  In xml/xslt, there is the Texinfo XML which should be a better
mapping of the Texinfo language, though.  However somebody still has to 
do the xslt associated, and that won't be me...

> (You have probably already considered and rejected doing
> customization by post-processing, but I'll make a note of
> my reasoning for the record.)

No, it is not rejected, but an alternative, still possible pathway.

> longer than running the new makeinfo.  However, it would have
> the advantage that not everyone has to pay for it; only those
> doing customization.

The point is that doing a tree out of Texinfo documents and then
processing it also leads to a code that is much cleaner.  Once this
job is done, adding customization per se is not really complicated.
The overhead of doing the tree instead of just parsing the Texinfo
and converting on the fly is certainly very minor in any case.  The 
slowdown comes using perl, in my opinion, not from the possibility 
of customizing output.  I think that a C implementation should 
have the same organization than the Parser, which is, in my opinion, 
a clean and efficient one.

-- 
Pat