Re: Non-ASCII characters in @include search path

[pertusus]

On Sun, Feb 20, 2022 at 03:45:37PM +0200, Eli Zaretskii wrote:
> > 
> > I do not think that it is a good solution either.  On Linux, unless I
> > missed something, the file name encoding should be utf-8 irrespective of
> > the locale, or the Texinfo document encoding.
> 
> No, that's incorrect.  Linux filesystems don't care about the
> file-name encoding, so any byte sequence will do; it just assigns
> special meanings to 2 bytes: the null byte and the slash.
> 
> However, most users specify file names in the locale's encoding,
> because otherwise they might be unable to see them correctly, type
> them on the keyboard, etc.  And since most users use UTF-8 as the
> locale's codeset, you get the effect that you thought is enforced by
> the filesystem; it isn't.

It is not enforced by the filesystem, but I was under the impression that
the tools used utf-8.  I actually tested, and you are right, the locale
seems to be a better default.  If there is no encoding found with the
locale, utf-8 can probably be used as a default.

> On Windows, file names on disk are actually encoded in UTF-16
> (assuming NTFS filesystem).  However, since makeinfo and Perl are
> console programs, their Windows builds can generally only use the
> single-byte encoding of the locale (the so-called "system codepage");
> Widows file-related API calls, like 'open', 'rename', 'delete', etc.,
> convert the locale-encoded file names into UTF-16 internally.

Ok.

> > In any case, I do not think that letting the user specify the file-name
> > encoding would be any good, we should manage to get it right.
> 
> The next best solution is IME to use the locale's codeset.

There probably will be a customization variable anyway, but we really
should not need to have to use it.

-- 
Pat