Re: `texindex` output depends on locale settings

[Werner LEMBERG]

>> > > >   I consider it very bad that `texindex` is locale-dependent.
>> > > >   IMHO the proper solution is to make `texinfo.tex` emit a
>> > > >   document encoding statement to the (unsorted) index file
>> > > >   that in turn gets acknowledged by `texindex`.
>>
>> Sure? No. But I have some thoughts.
>>
>> > FWIW, I don't even understand how can this be accomplished,
>> > unless the program reinvents all the library functions that deal
>> > with characters from scratch, instead of using libc functions
>> > (which are locale-dependent).  And Gawk does use libc functions
>> > for that.
>>
>> The current islower() is
>>
>> function islower(c)
>> {
>>      return index("abcdefghijklmnopqrstuvwxyz", c) > 0
>> }
>>
>> It could instead be
>>
>> function islower(c)
>> {
>>      return c ~ /[[:lower:]]/
>> }
>>
>> And similar for the others.  That would work for any unicode
>> character.
>
> Sure, but is the issue only with lower-case letters?  What about
> collation order or even determining what is and isn't a character
> (as opposed to incomplete byte sequence)?

Two remarks.

* I think it would be OK if the documentation says that i18n support
  for sorting only works with awk programs that understand `LANG`.

* Let's assume that GNU awk behaves similar to, say, GNU sort.  The
  collation order and input encoding gets controlled with `LANG` –
  looking into the awk info manual this seems like a reasonable
  assumption.

  As far as I can see, my two issues could be resolved by a shell
  wrapper around the awk program that analyzes the (yet to be added)
  `@documentencoding` and `@documentlanguage` settings in an unsorted
  index file.  From those two settings it synthesizes a proper `LANG`
  argument that gets passed to GNU awk, et voilà.

  Am I missing something?


    Werner