Re: kinput and kterm SOLVED!!!!!

[Tobias Diedrich <ranma@example.com>]

Martin Baehr wrote:

> > It should not. AFAIK only LC_ALL overrides the other settings.
> 
> LC_ALL only overrides LC_*;
> but maybe i didn't test it properly...

That should have read "LANG and the other LC_* settings"...

> > BTW is there a canuum package for Debian out there somewhere ?
> 
> canna supports canuum

ranma@example.com:~$ apt-cache search canuum
canna - A japanese input system (server and dictionary).
ranma@example.com:~$ dpkg -l canna
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  canna          3.5b2-41       A japanese input system (server and
dictiona
ranma@example.com:~$ dpkg -L canna | grep canuum
ranma@example.com:~$ su
Password:
melchior:/home/ranma# apt-get install canuum
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package canuum

Thats on Debian unstable...

> > My guess is that vim always uses LC_CTYPE encoding whereas jvim tries to
> > be smart about the encoding used... OTOH I would not expect it to write
> > iso-2022-jp if LC_CTYPE is set to euc-jp...
> 
> could be, but it should at least read them and tell me about it,
> and not give me garbage.

Of course that would be nice, but it ain't easy...
...or probably it is impossible to reliably to detect a file's character
encoding with the number of different encodings out there.
It is easier for jvim because it is localized and only has to worry
about japanese encodings.

-- 
Tobias								PGP: 0x9AC7E0BC