Re: bug: set-terminal-coding-system doesn't work?

Kazz> My terminology: Kazz> * conversion server, conversion engine: Wnn6, ATOK, etc Kazz> * input server: kinput2, htt, etc Kazz> * input method: XIM, egg-its, etc OK, I'll go by that. Kazz> What I intended to say is "input methods" not XIM. There Kazz> will be a difference on input methods between Kurosaka-san's Kazz> and Steve's, XIM and egg-its. Kazz> <description_of_solaris_xim> Kazz> I think (1). But if you mentioned "input method" as Kazz> shelltool's input method, I think it's not input method Kazz> problem, but XEmacs's input stream on tty, unfortunately. You're right on both counts as far as I can tell. I wasn't thinking clearly. What I meant was that vi working doesn't necessarily mean that it's an XEmacs problem, because the two programs can use different henkan strategies. Kazz> The XIM feature of XEmacs isn't so buggy except the time Kazz> when XIM has died ;-} I meant XIM itself is buggy, as implemented in XFree86 libX11, anyway. Kazz> I have no idea with why the "-nw" of XEmacs can't accept Kazz> multi-byte input from terminal right now... I don't know either. As of late March Martin claimed it should work properly, and it did work fine for my 21.2.9 under Linux + kterm + kinput2. All I had to do was set LANG=ja and make sure that kterm's idea of kanji code matched that of XEmacs (normally this is OK on startup, but XEmacs does not follow kterm if you change it in the menu). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."