Re: Non-ASCII characters in @include search path

[Patrice Dumas]

On Sun, Feb 20, 2022 at 02:53:46PM +0000, Gavin Smith wrote:
> On Sun, Feb 20, 2022 at 02:42:04PM +0100, Patrice Dumas wrote:
> > On Sun, Feb 20, 2022 at 12:45:59PM +0000, Gavin Smith wrote:
> > > 
> > > I made a similar change in commit e11835b62d.
> > 
> > I propose another plan:
> > * decode arguments on the command line arguments based on the
> >   locale
> > * if on windows use the locale to determine the encoding
> >   for the file names, otherwise use utf-8.  Encode file names
> >   as late as possible, just before calling -e, stat, open...
> > 
> > The first point is important in general, I think, not only for
> > file names, but also for customization variables strings in case
> > one use accented characters in those.
> 
> Decoding command-line arguments might be a good idea for everything
> EXCEPT file names.  Why go to the bother of decoding file names when
> they have to be encoded again to use them?

Because it is the best way to be able to combine strings from diverse
origins, and with diverse encodings, from the command line, from Texinfo
code.

> I'm happy for there to be special handling for Windows where file
> names are not just byte sequences.

That would probably add quite a bit of code to have two paths.

-- 
Pat