On Wed, Jun 24, 2026 at 03:03:58PM +0200, Patrice Dumas wrote: > On Tue, Jun 23, 2026 at 10:00:16PM +0100, Gavin Smith wrote: > > I thought I would try to make a start on rewriting the Plaintext converter > > in C. I thought it should be simple when compared with the HTML converter > > that already exists. For one thing, there should be no customization API > > for the Plaintext converter. All the conversion is done with straight > > function calls rather than via hooks that can be overridden. > > Eli mail made me realize that I had not commented on Plaintext versus > Info. In the Perl implementation, the Info converter inherits from the > Plaintext converter. It has a separate output() (converter_output in > converter_format_data in C), but calls the _convert Plaintext function > (and many other functions from the Plaintext module, but it is easy to > do that in C). Then, all the functions with name like format_*, such as > format_contents or format_image are replaced in the Info converter, such > that the functions in the Plaintext code call the Info functions if the > converter is the Info converter. There is a need for an explicit > information that Info is converted to in one function only, > process_printindex, otherwise this object-oriented technique is the only > one used to obtain Info rather than Plaintext. > > I have no idea if this is the right way to go, but the trick I use to > emulate inheritance and function overriding in C is to have a table of > functions, such as converter_format_data in converter.c and select the > function to call based on an enum corresponding to the format stored in > the C converter, like COF_html, which is also the index in the functions > table.
I don't think the Info/plaintext split will be a major problem. It can be done as you describe or even just with a simple conditional based on the output format.
