On Wed, Oct 26, 2022 at 05:34:56PM +0100, Gavin Smith wrote: > On Wed, Oct 26, 2022 at 05:47:54PM +0200, [email protected] wrote: > > On Wed, Oct 26, 2022 at 03:14:26PM +0300, Eli Zaretskii wrote: > > > > Date: Wed, 26 Oct 2022 11:03:53 +0200 > > > > From: [email protected] > > > > Cc: [email protected], [email protected] > > > > > > > > Lets call LOC your locale. The setup is a manual encoded in Latin1, and > > > > an include file included_latîn1.texi. On your computer, the î in the > > > > include file is stored as 0x05DE, which is the conversion of 0xEE in the > > > > LOC codepage. > > > > > > For this to work, the non-ASCII character we use should be encodable > > > both by Latin1 and by the Windows codepages. This is a tough > > > requirement, but if you look at the tables of these encodings, you > > > will see that some codepoints between 0xA1 and 0xAF are identical > > > between many Windows codepages and Latin1. For example, 0xAB is > > > identical in many codepages. So maybe we could try such a character, > > > for these tests? > > > > I set the character to the Yen and Yuan sign which is in the range. > > > > It is not fully clear to me how this changes what we do with the tests, > > though... > > I thought we were going to skip these tests. > > I heard that ¥ was a forbidden character on Windows filesystems, > due to confusion with the backslash, so I can imagine that this could > easily cause problems. > > https://learn.microsoft.com/en-us/windows/win32/intl/character-sets-used-in-file-names
I'll replace with §. -- Pat
