On Sat, Aug 20, 2022 at 09:39:26AM +0200, Patrice Dumas wrote: > There is a specific issue with --apropos, I guess.
It's an issue with menu entries. In a UTF-8 locale, go to "(index_latin1)chap Index". Type m<TAB> to select a menu entry by name and there appears in the echo area: Menu item: latin1 caf\351 == \364 toto You can see that the label of the menu entry has not been converted. The menu entry is being correctly displayed as * latin1 café == ô toto: chap Index. (line 6) I've committed a fix for this, to convert the stored labels of menu entries as well. Let's hope it doesn't cause more problems than it fixes. It's very likely this breaks in some cases (malformed files, shift states...) Unless problems are likely to occur in practice it may be better to ignore them if fixing them makes the code more complicated, I tested my fix in both a UTF-8 and Latin 1 terminal. The results were fine. In the Latin 1 terminal, the index entry in the test file index_utf8.info wasn't found because it couldn't convert the Chinese characters, but it worked if I added another index entry which could be converted to Latin-1: * UTF-8 café ≡ 这常 toto: chap Index. (line 6) * UTF-8 café toto: chap Index. (line 6) In a Latin-1 locale with the adjusted file: $ ../../info/ginfo -v infopath-no-defaults=On --apropos café "(index_latin1)chap Index" -- latin1 café == ô toto "(index_utf8-2)chap Index" -- UTF-8 café toto I don't want to go to the same efforts that we went through for texi2any to get character encoding done right in info, as this could be too complicated and take too long to do. It's probably not a perfect fix as now we are running iconv twice over each label, once for internal storage, once for display. I'm going to check that in the common case, when everything is in UTF-8, iconv isn't called at all.
