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
