On Tue, Aug 11, 2009 at 10:47:10AM +0200, Torsten Bronger wrote:
> Hallöchen!
>
> Because it doesn't need it. But it does need the nesting, so I
> think it's sensible to have nesting in the Texinfo XML. Otherwise,
> XML-based converters with nesting target formats will have to
> reconstruct it. It's much easier to flatten a structure than vice
> versa.
>
> I think Texinfo XML's nesting should reflect secioning only, and
> nodes should be just empty elements, as the optional first child of
> a section.
That could be an easy way out. The problem is that the opposite is more
consistent with the texinfo way, a section is within a node. But another
easy way out would be to have nodes as stand-alone elements, but not
first childs of sections, they should just be output where they appear.
Karl, does it look good to you?
> If I remember correctly, bad things (warnings/errors)
> happen anyway if the node and sectioning structures of a document
> are too much diverging. Unfortunately, the format allows this.
They have to be consistent, but this doesn't allow an easy nesting.
Unless I missed something, the document I attached at the start of the
thread is valid texinfo and can be processed as info, docbook, html
and tex. It gives no error message but something that looks like an
internal error when processed by makeinfo --xml.
> Visiting Texinfo after a long time, I wonder whether there is
> motivation and spare time to overhaul Texinfo, accepting *small*
> incompatibilities?
This is more or less happening at the software level, since
texi2html (written in perl) will replace makeinfo in C soon. But
it should be fully compatible (except that @macro would become
like @rmacro) at the input format level.
> As with Python 3 recently, one could create a converter to the new
> syntax. Makeinfo could even detect an old version and run the
> converter internally (emitting a warning about the waste of time).
>
> Some things that I find very important:
>
> (1) GIVE UP the tight binding to TeX!! Consider TeX a mere backend
> to which Texinfo must be converted.
It seems to me to be already the case (at least for me). I think that
there is Texinfo as a language which is distinct from the software
implementations that convert it to other formats. Binding Texinfo
to info is, in my opinion, also an error, since Info has some limitations
that, in my opinion, should not be taken too much in consideration
when defining the format (for example no comma in node names). Sure
this could lead to manuals that are not readable in info, and the
converter should say it, but it is different from an issue in the
Texinfo format itself.
The major advantage of switching to texi2html is that in texi2html
the distinction between the texinfo parsing and the output formatting
is better done than in makeinfo C, allowing to separate more the
language and the output backends (and allowing for easier backend
generation).
> (2) UTF-8 and localisation stuff. Almost impossible without (1).
UTF-8 basic is already done, and better localisation support (with a
gettext-like framework) It is the last thing that has to be done to have
the perl implementation replace the C implementation. There is still
work to do on the UTF-8 side, but using what recent perl provides should be
enough.
> (3) Floats and graphics sorted out for all backends. Very difficult
> without (1).
@float support could be much improved in the docbook output, but in
the other outputs, I can't really see how to do better.
> (4) Syntax improvements. Many commands have gathered too many
> arguments, there are too many cross reference commands, and the
> conditional processing should be put in question.
What do you mean with 'there are too many cross reference commands'?
Do you mean that xref, pxref and ref should be only one command?
Which commands has too many argument?
and what problems do you see with the conditional processing?
I personnally think that there are problems with the commands ended
by end of lines since it is not easy to have a proper nesting, mostly
@item in @(v|f)?table and @center. Also I think that removing spaces
after @anchor{} is inconsistent because it is a command with braces.
It also seems to me that the whole @def* is dubious because it has
a different syntax than other @-commands regarding arguments separation.
Overall, using only one way to give arguments to @-commands (and
certainly arguments separated by commas) would be better, in my opinion.
Karl is unhappy with the @macro stuff, too (and maybe with conditionals?)
> I have the impression that further work on Texinfo has become a
> rather unthankful task. Maybe the Gordian knot must be cut (and
> this is the connection to TeX ;-)?
>
> Apart from the work of an overhaul and the necessity to provide
> automatic conversion, generating Info files still must be fast,
> given the number of make files that make them. The other backends,
> however, can be programmed comfortably in various languages. Doing
> text-crunching in C is awful.
With the switch to perl implementation, generating info won't be fast
anymore (texi2html is awfuly slow), but doing other backends should
be fairly easy. makeinfo in C is still there anyway for those who want
something fast.
--
Pat
more_sections_than_nodes.texi (579 bytes) 