bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: info --apropos should decode/encode nodes/index entries


From: Gavin Smith
Subject: Re: info --apropos should decode/encode nodes/index entries
Date: Sat, 20 Aug 2022 12:16:49 +0100

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]