This is the same as
I wanted to bring to attention since it seems unhandled since October.
Logged In: YES
Explicitly assigning to jhallen. (BTW, Is not your tracker set up to do that automatically?)
Here's a patch, please include.
BTW, why do you all need those "unsigned char" in the code?
File Added: joe-3.5-fix_locale.diff
Logged In: YES
I will start working on JOE again soon- so keep the bug reports and patches coming. As long as they are in the tracker I will see them.
I use 'unsigned char' because I want conversions from char to int to not result in negative numbers, which is almost always a bug. Although initial coding with unsigned char is a pain, I can mechanically verify that this bug does not exist this way.
Logged In: YES
This is related to:
I investigated that code a bit, 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 when the user
sets LC_CTYPE to e.g. de_DE, and the second part would do the right thing.
This whole codepage business sounds like a classic case of too much pain
for too little gain...
The patch in here seems to be redundant. It adds another discovery procedure
for the locale_lang variable (which gets passed into init_gettext(), the function
which seeds the joe custom .po implementation), just because the existing
procedure fixates on LC_CTYPE. We should fix the old procedure rather than add
yet another new one which further complicates the code for no apparent reason.
CVS history shows that there has been considerable ambiguity on this front in the
past - Joseph has actually left in a broken version of the CODESET getting procedure
in the latest commit:
The ifndef CODESET -> undef HAVE_SETLOCALE calls *must* go after the loading of <langinfo.h>,
because otherwise the CODESET from that file is always ignored.
Most if not all the other commits in this part of the code show the back-and-forth:
It would be good if we had an explanation of what the code is actually trying to do. :)
This is now fixed in CVS.
Cf. Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453310
Please let me know if this in JOE 3.6.
Yeah, it's fixed now.
(Fixed in 3.6 and up, though I only tested 3.7 because it was released shortly after 3.6.)