Re: Non-ASCII characters in @include search path

[Patrice Dumas]

On Sun, Feb 20, 2022 at 03:32:30PM +0000, Gavin Smith wrote:
> On Sun, Feb 20, 2022 at 2:55 PM Patrice Dumas <pertusus@free.fr> wrote:
> > > The byte sequences are just concatenated and used as the path to the file,
> > > even if it's not validly encoded.  This shouldn't cause a problem.
> >
> > It will cause a problem if the include file name itself is not ASCII.
> > To avoid any problem and mismatch, decoding at input, doing everything
> > in the code with internal perl unicode and encoding on output seems to
> > me the best.
> 
> It would make it impossible to build the Texinfo manual if it was
> being done from a directory that was in a different encoding. This
> could happen if a user had their home directory, for example, in
> Latin-1 and then they download and try to build a manual that is in
> UTF-8 in their home directory. The directory name could get into -I
> options via Makefile rules, as was the case with the original bug
> report for the Octave manual.

I don't get it.  If everything is decoded to internal perl encoding and
then the file name is encoded to the local, here Latin-1, everything
will be ok, as long as the characters in manuals can be output in
Latin-1.

-- 
Pat