I remember this exact issue has happened before with Gnulib, and I
remembered that it was going to stop using the file from ftp.gnu.org,
By "stop" you mean "start", right :)? Yes, I also remember saying I
would make that change (use the file from ftp.gnu.org instead of git),
but then failed to ever do so :(.
It seems better to wait for confirmation that this fix worked before
uploading the newer version to ftp.gnu.org.
Ack.
Advancing it to the latest commit
Yep, that is already done. I guess I will leave it that way and start
the "use the ftp.gnu.org version" with the next release of the file.
Unless you think it would better to backdate the texinfo.tex in Gnulib
and Automake to the June 1 version.
> https://lists.gnu.org/archive/html/bug-texinfo/2026-10/msg00042.html
> There's no quick easy way of making all the sequences defined with
> \mathchardef expand to a list of character tokens, as far as I know.
As far as I know too, in this case, the only robust solution is what you
did, to explicitly define the control sequences in question. I suspect
more macro and @macro kludges could make it possible to work as it did
before, but that doesn't seem like a fruitful path to follow.
Avoiding having to (re)define every math command (hundreds) as a Texinfo
command is exactly why I originally adopted the approach of
(essentially) allowing \ as an escape character inside @math. People
would rather to type backslashes for their math commands anyway, or
copy/paste from existing TeX documents, etc. And for non-PDF output, in
general the "TeX" source is as readable as anything can be (IMHO),
barring people using literal UTF-8, which is up to them. -k
