"Gavin Smith" <gavinsmith0...@gmail.com> writes: > On Sun, Jan 26, 2025 at 12:29:38AM +0000, Pip Cet via Bug reports for the GNU > Texinfo documentation system wrote: >> This isn't as helpful a bug report as I would have liked. I tried >> understanding this problem, but for reasons I cannot quite grasp yet it >> was too hard for me. >> >> My understanding is that old versions of texinfo produce the warning >> >> `.' or `,' must follow \@xref, not %s >> >> when an @xref is followed, after its argument, by a space and then an >> alphabetic character. >> >> It appears this behavior was changed to permit ordinary text to follow >> an @xref directly, without punctuation. > > Yes, the reason was for processing with texinfo.tex, in order to provide > punctuation in the output that looked like:
Thanks for the response, and thank you in particular for including references! > 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. >> 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. 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. > 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. > 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 understand the decision to drop the warning was deliberate, but >> wouldn't it be possible to make it an optional warning, disabled by >> default? The warning could indicate which version of texinfo stopped >> warning about this by default and when it was released, so there would >> be an incentive to disable the option at a future point. > > It seems like a lot of work and complexity for little benefit. Thank you for explaining. I think it's obvious that I disagree. Pip
