On Sun, Jan 26, 2025 at 02:07:02PM +0200, Eli Zaretskii wrote: > Suppose a project using Texinfo for its documentation does want to > support older versions of makeinfo -- what would you suggest to use > for that? It seems to me like makeinfo, being the tool that parses > the Texinfo source, is in the best position to produce such warnings.
I think that TREE_TRANSFORMATIONS could be used for that as I propose in the other mail. I see no trouble accepting code that fits in that scope, if somebody volunteers to write it in Perl and in C. > This is a broader subject. Indeed, makeinfo lacks version-checking > directives, so one cannot safely use new language features if one > wants to support older Texinfo releases. This causes very slow > acceptance of new features, and consequently sub-optimal output. It > would be good if Texinfo had such version-checking directives added at > some point. For example: > > @ifversion @atleast 10.1 > ... stuff that only Texinfo 10.1 and newer supports ... > @end ifversion It seems to me that it can be done with @ifset and -D on the command-line. It could be @ifset version-atleast-10-1 ... stuff that only Texinfo 10.1 and newer supports ... @end ifset Then the user running texi2any/makeinfo would have to know whether to add -D version-atleast-10-1 on the command-line by looking at the version of the program. It would probably be better to use a flag name that corresponds to a feature, and document which flag corresponds to which version in the manual. For example @ifset no-automatic-menu @menu * ... @end menu @end ifset And at the beginning of the manual or something like that, a comment saying @c -D flags to set on the command-line for old versions: @c no-automatic-menu: < 5.0 > The benefit is that projects which want to support old releases of > Texinfo will be able to adopt the new features much faster. And in > some cases, the detection of violations of the older language rules > will be more reliable. I am not really convinced, given that the Texinfo language pace of change is quite slow, and we keep the possibility to use features needed by old versions for long times. It happens that we remove completly some @-commands, but it can be handled by @ifcommanddefined as Gavin said, since 5.0 in 2013. There are also rare cases of non-backward compatible changes (I found two by browsing the NEWS, "@-commands are now recognized in raw format blocks" and "@url becoming a synonym for @uref"). It is not possible to use TREE_TRANSFORMATIONS to readd commands, but it is possible to readd warnings and errors, or substitute @-commands (for the @url/@uref case) if there are volunteers to write the code. -- Pat
