On Sat, Jun 07, 2008 at 01:40:42AM +0200, gregor herrmann wrote:
> > > > OK, yes, this is another aspect of these locale bugs that I didn't yet
> > > > address - joe's code is fixating on LC_CTYPE only.
> > > Until the recent version it worked just fine, so I guess it must have
> > > been introduced in 3.5-2.
> > The problem is that it the de.po was being activated before, too, but it
> > used English strings, and sometimes just broken strings. :)
>
> Ah, that makes things clearer for me.
> Thanks for taking the time to explain this issue!
I've went back and investigated that code once again, and I can't say
I really understand what the hell it is doing, that is, why it's doing it :)
I checked the documentation for setlocale(), and cross-checked the
implementations in vim, nano, jed, and none of them do what joe seems to be
doing - joe is trying to read a "non-UTF8 but local" codepage by checking
the environment and switching to that locale, and then reading a "UTF8 but
local" codepage by doing the standard setlocale(LC_ALL, "") call.
During the first part of that process, joe checks these variables in turn:
LC_ALL, LC_CTYPE, LANG. It seems that others either don't do that, or they
check LC_MESSAGES instead of LC_CTYPE.
The codepages it goes to so much pain to extract are used to read
the /etc/joe/charmaps/* files, but there's only "klingon" in there.
I tested the process with various inputs, and every the time the first part
of the process would return the default C codepage, except in your case, and
the second part would do the right thing.
This sounds like a classic case of too much pain for too little gain...
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
