On Sat, Jul 04, 2026 at 11:11:29AM +0000, Werner LEMBERG wrote:
>
> >> I couldn't find anywhere in the documentation that `@include` does
> >> not accept file names containing spaces. AFAICS, since `@include`
> >> needs a line of its own, such a limitation is not necessary.
> >> Compare this to LaTeX's `\input{...}` command, which also accepts
> >> file names with spaces.
> >
> > My recommendation is just to avoid spaces in Texinfo file names.
>
> Mhmm, Windows users might not be happy about this :-)
>
> > So if we added double quotes (or curly braces) around the file name in
> > texinfo.tex all the time, this may not be 100% reliable as it is not a
> > standard feature of TeX.
>
> Using braces sounds promising. Regarding reliability: what TeX system
> do you have in mind that is not based on Web2C, or which doesn't have
> the standard extensions provided by Web2C? AFAIK, recent versions of
> LaTeX require them.
The only one I had in mind was MikTeX but I have no reason to know
more. I was just aware that there might be others.
I found this release notice:
https://miktex.org/announcement/miktex-2-9-7300
Group-delimited \input argument
MiKTeX adopted the forthcoming TL 2020 \input enhancement which allows
you to specify file with spaces in the name:
\input{my stuff}
\input{"my stuff"}
To quote Karl Berry:
For TL 2020, I think we're going to be able to extend \input so that it
can take a grouped argument (\input{...}), and thus allow any character
in the name -- except that " characters will still be eliminated, at
LaTeX's request. This won't affect the standard space/token-delimited
use of \input in any way.
So based on that, TeX programs from before 2020 might have problems.
> > I've made an attempt at wrapping braces around the file name only if
> > it has a space. I've implemented this in a way that it should be
> > easy to remove if it turns out to cause problems.
> >
> > This will not work if the file name has two spaces or more in a row,
> > however.
>
> Thanks.
>
>
> Werner
