On Wed, Sep 10, 2025 at 09:21:29AM +0200, Patrice Dumas wrote: > Hello, > > This is a follow-up on the discussion here, for a feature change that > was too late for the previous release: > https://lists.gnu.org/archive/html/bug-texinfo/2024-11/msg00127.html
Also later: https://lists.gnu.org/archive/html/help-texinfo/2025-03/msg00000.html > The plan as described in the discussion above is to have HIGHLIGHT_SYNTAX > specify a command, which has input fragment and output fragment taken > from stdin/stdout and highlighted language prepended to the > commmand-line. That sounds like a sound design to me but let's consider all options. I suspect if users have to maintain a separate wrapper script the feature is less useful. (I haven't gotten to looking at the syntax highlighting issue up to now as it was a low priority for me and never had the time to look at in detail.) > At the same time, I would like to keep the possibility to use the > current code, which adds checks on languages, possibly, mappings of > language, as well as default command line options. Also for > source-highlight, the processus is quite different, with separators and > counts and only one file. It is hard to comment without knowing in detail what highlight_syntax.pm does and how it works. The functions are missing any comments explaining what they do or the data structures they access. I am am looking at highlight_syntax.pm to understand how it works better. Some notes: * The language name mapping is extremely rudimentary: my %highlight_type_languages_name_mappings = ( 'source-highlight' => { 'C++' => 'C', 'Perl' => 'perl', }, 'highlight' => { 'C++' => 'c++', }, 'pygments' => { 'C++' => 'c++', } ); Is this useful or necessary for us to maintain on a program-by-program basis? * I am cautious about "generic" code that ends up not being generic at all. Currently highlight_syntax.pm has three options ("source-highlight", "highlight" and "pygments") with checks throughout the code which one is being used. In 'highlight_process', there is one block of code for "highlight" and "pygments" with further conditionals inside for which one is being used. Presumably what follows is the code for "source-highlight". This kind of code is not easily extensible to further options. It is often yields more straightforward code to duplicate code and eliminate the conditionals. (You may remember the C implementation of makeinfo which had conditionals for Info, HTML and XML throughout the code, which although it was before I was involved with Texinfo, seemed to me one of the problems with the maintainability of that program, with code originally written for one output format (Info) complexified to deal with other output formats.) * The purpose of 'highlight_preformatted_command' (one of the callbacks) is not easy to understand without reading the entire function line-by-line. I would have appreciated a comment explaining at a high level what it does. It appears to save information and retrieve information from the module variable %commands (which is an array of complex data structures, which are not documented), and do checks and issue warnings. There is no option-specific code in this function. If as you say, the "source-highlight" option uses more of the code in highlight-syntax.pm perhaps it is more useful to keep most of the code for that option? There is another approach which is for the syntax highlighting program to post-process the HTML output from texi2any. This should be possible as the @example blocks are marked with appropriate classes. > Therefore, it would be nice to have a way to specify the the built-in > code should be used. The syntax could be, for the HIGHLIGHT_SYNTAX > customization option: > > default:highlight > txi:highlight > preset::source-highlight > > or also with another separator than :. > > Any idea, preference, comment? I am not a fan of overloading a single variable with special syntaxes. I prefer the idea of having multiple variables, as in Carlos Maniero's orignal patch, if we are providing a feature that is not simply implemented with a variable with a value of a shell command. In the thread I linked above, somebody wanted to pass extra flags to pygmentize. So there you have a mixture, using the existing code but adding command-line options. Would the existing code be useful for this use case or is it mainly for "source-highlight"?
