Re: Transforming XML or other intermediate representation of Texinfo; category system

[Vincent Breton]

On 13/12/2021 08:00, Robert Dodier wrote:
> The bad news is that it's implemented as a terrible conglomeration of
> bash scripting and regex matching. I am thinking about ways to make it
> less terrible.
That is a good start to adapt them in Perl. Texinfo uses Perl for some
parts of code and Perl is the first  -- or one of the first -- language
to include regexp. Perl is also a language to replace awk or to improve
awk if you use it. Bash scripting is a good exercice because it's more
easy to adapt scriptings in another language and the code is more
readable if their is an similar code in Bash. In my opinion, Python is a
very good language and easy to learn to write very quickly powerful
scripts easily readable. They are lot of interesting commands to
manipulate files and strings. To make a final version to improve
functionalities of Texinfo, you can at the end adapt your work for the
language used with Texinfo if you have time for that...
>
> First of all, am I reinventing a wheel here? Is there already an
> implementation of a category system for Texinfo? There wasn't when I
> got started but that was a long time (more than 10 years) ago. I
> searched again today but didn't find anything.
I don't know if they are an implementation of a category system for
Texinfo but I don't think you are reinventing the wheel for Texinfo: I
just know the goal of Texinfo is to generate differents formats with the
same initial content, more particularly for documentation of software or
simple others documents. Improving Texinfo can break the original goal
so it's seams more appropriate to make an extension for it or to make a
fork. For example they are most of the time no graphics or very simple
scheme inside final documents created with Texinfo. I think the reason
is plain text whoi is not able to  include photos or vectorial images
for example.
>
> Assuming there isn't such a system already, I am thinking a cleaner
> way to implement it would be to generate an intermediate
> representation of Texinfo documents, do some transformations on it,
> and then generate the output (info, html, pdf). Is it possible to use
> XML as an intermediate representation? I know that one can generate
> XML via --xml -- the crucial step would be to be able to input XML as
> well. Is it possible for makeinfo to read XML as input?
If you use the Texinfo format you can output XML to generate  HTML.
After that with your own script you can parse XML output and again your
Texinfo source including special comments -- to tag and define new
functionalities -- before generate another XML file and modifying
yourself the HTML. Don't blame me because I just suggest my own view to
not break Texinfo or to not loose so much time inside the code with the
final goal to upgrade Texinfo when all is working fine. For the PDF
file, it's build with a big TeX file generated by Texinfo.  I started to
sudy it and it's very impressive with so much definitions of new
functions. For the moment, I didn't take the time to make a test
building a new function inside texinfo.tex file. I think it's the
appropiate approach because Texinfo functions  are new TeX macros
defined in texinfo.tex file. Finally to implement directly HTML, you
will need to use your previous work and update Perl file (or/and C file
because if I understood in previous messages there is also a C version
of Texinfo ?)
>
> Failing that, is there any other structured intermediate
> representation (i.e., can be either output or input) of Texinfo
> documents?

I just know there is another  interesting Gnu tool as Flex: in few words
it associates code with words detected in a sentence. It could be used
as an intermediary tool to make tests and parsing more easily some
texinfo file before making a real implementation of new functionalities
without this too.

Vincent Breton