On Sun, Jan 26, 2025 at 11:26:48AM +0000, Pip Cet wrote: > > We changed texinfo.tex to look ahead in the input and add a comma if one > > was missing, so input like > > > As far as I remember, the warnings didn't stop the Info file from being > > output. > > But the Info file would have (slightly) incorrect contents if the new > convention is used with an old texinfo, right? This would lead to an > argument about whether relying on the new behavior the moment a new > texinfo version is released might have been premature.
You would have to double-check with the old version of Texinfo, but I believe not. As far as I remember the warning was for the sake of the printed output. > >> I'm open to other suggestions for how to avoid this problem. There was > >> some confusion about whether this was a warning or an error, and whether > >> it was "build-breaking", but that's possibly not relevant. > > > > It is relevant, because if it is not "build-breaking", it is less important > > to add warnings to newer versions of Texinfo. > > There was a similar case with another commit, which was definitely > build-breaking. That is not very specific. > If there's any chance it might convince you to change > texinfo in any way, let me know, but it very much sounds like there > isn't. > > > It is not a "bug" as you label it, as there is nothing wrong with the > > Sorry. I called this a "bug report" because it went to a list called > "bug-texinfo", which is used loosely in this case to report a technical > concern. If I've used the term "bug" directly, that was sloppy and I > apologize. I see the confusion. bug-texinfo is used for development and general discussion, not just bug reports. > > input for newer versions of Texinfo and no need to warn about this input. > > It could be called a "feature request" for backwards compatibility. > > That appears to be a larger feature request; the current behavior of > texinfo appears to be this: > > Language features are added simultaneously with a new texinfo version, > which enables them unconditionally and does not attempt to warn in any > way when reading a texi file which would produce warnings, and possibly > errors, when run on the previous texinfo version. > > If that's an accurate summary, it'd be great if you could confirm > briefly, and then we can close this non-bug-report. Yes, that's right. By the way, we don't operate any kind of bug tracking system, with open/closed issues. You could say we will non-close the non-bug-report. :-) > > As far as I know texi2any has never tried to check if input files don't > > work with older versions of Texinfo. It is not just . and , following > > @xref. For example, from the same 6.1 release, the @setfilename command > > became optional, as well as @menu. A much older change was to determine > > node directions automatically, rather than giving them as extra arguments > > to @node. And of course, every new Texinfo command that is added does > > not work with older versions. I've never heard the suggestion that we > > should have optional warnings for any of these. > > That's a very different perspective from what I'm used to. For a > programming language, it would seem to me to be unacceptable to change > it in such ways, but I'll have to think about whether I really think > that applies to the texi case, too. Erroneously-generated documentation > may simply not be a problem. I suspect you will be familiar with similar changes in other software you use. It's the case with autoconf, for example. A new release (2.70) introduces a new macro (AC_CONFIG_MACRO_DIRS), but there is not anything in the package itself to mark the new macro as belonging to that version, or any way to warn about macros that are used from newer versions. It could be that the pace of Texinfo language change has been so slow that it has not really been an issue.
