[latexrefman-discuss] Fwd: REVIEW REQUEST - user manual generation

[Vincent Belaïche]

Le 08/05/2016 01:10, Karl Berry a écrit :
> Indeed, I don't believe there is any perfect way to support filenames
> with spaces.

I agree, I have tried everything I could imagine (like replacing spaces
by \space, or catcoding 32 to 11 or 12) and nothing makes it with MikTeX.

> Double-quoted "foo bar.tex" is the most likely. I don't know if that works in miktex. 

IMHO this is *not* a good solution because double quote is a valid
character in filenames under Unix.

Furthermore this solution does not work fully with MikTeX --- it works
only w/o the -recorder option, but texi2dvi uses the -recorder option
when operated with MikTeX

> Multiple consecutive spaces is even harder, e.g., see thread starting
> at http://tug.org/pipermail/tex-live/2016-May/038331.html.
>

It seems that the problem is a MikTeX bug, replacing ' ' by '\space '
does not work with MikTeX, but in the thread people say that this works
with TL.

> I believe luatex has enhanced the \input primitive so that if the next
> character is catcode 1, the filename is terminated by the next catcode 2
> token.

It amounts to implement in the engine what LaTeX tries to do in TeX
language. Well, if I was Christian I would give to this less priority
than to handle '\space ' not as ' '.

I have not yet looked at the latest patch by Gavin, but I am not so sure
now which way is better : either change group-locally catcodes, or to
replace in filenames special characters by macros (e.g replace '~' by
'\string~'). The latter solution looks nicer to the extent that it makes
the command line more complex only on need. However it will break MSYS
path conversion algorithm in these cases : so it definitely needs that
current directory is changed to the one containing the file before etex
is run : but I am not sure what the implication are if we do so...

> I'd like to do this in all the engines (except "tex"), but even
> if we did, and got christian to do it in miktex, it would still be a
> hassle in texi2dvi to detect whether that support is present.

Let us see before if we can solve other special characters than space
just for the fun of it. Then we come out with a generic method and we
know better what to ask/expect from the engines.

> :(  -k

  V.