Steve, Actually, inputing Japanese characters *DOES* work from a terminal emulator on Mac. So this could be a terminal emulator problem, rather than XEmacs, or a problem in the terminal-specific lisp code. When I work with Mac emulator, I set TERM to vt100-w. At Sun, TERM is set to "sun", I believe. (I'll verify that tomorrow when I'm in office.) -kuro p.s. I'll be out of office today. I'm writing this from home. p.p.s. Highilighting the region still doesn't work from home either.

Kazz> "T. Kurosaka - Sun Professional Services" Kazz> <kuro(a)Japan.Sun.COM&gt; writes: Kazz> It doesn't matter of terminal emulator but input method, Kazz> doesn't it? Well, no. There are several ways that this can be implemented. (1) shelltool is XIM-enabled, filters everything, and sees only the events XIM chooses to give it. It passes Japanese to the app. Diagnosis: input method problem. (2) shelltool looks at the events and decides what to pass to XIM. It passes Japanese to the app. Diagnosis: shelltool or input method. (3) No XIM, but shelltool connects directly to an input server. It passes Japanese to the app. Diagnosis: shelltool, input method, or app may be confused. (4) No XIM in shelltool, which thinks it's passing a TTY representation of the keystrokes to the app, which actually implements XIM which steals the keystrokes. (I don't think this actually ever happens, as it would require a keyboard grab by the input server. Abomination. But that's the way that FEPs are implemented in DOS/Windose, at least up to 1994 or so.) Diagnosis: App or input method problem. (5) No XIM in shelltool, which passes a TTY representation of the keystrokes to the app, which directly connects to a henkan server. Diagnosis: App or input method problem. And of course all of these can be implemented as alternatives, as in XEmacs. I have no idea what the problem is, since I know nothing about the various tools (except XEmacs). If XIM weren't so buggy, consistently using it would make debugging a lot easier ;-) -- 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."

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."

T> Although I thought Japanese characters could be entered T> properly from a terminal emulator on Mac, I found a different T> problem - delete-char deletes a byte of a kanji, not two bytes. T> In addition, if I compose a mail message on Mew, it treats the T> contents as ISO-8859-1 text! Those two bugs are at least consistent with each other. T> I verified with describe-coding-system that the terminal and T> keyboard encodings are set to euc-jp. I'm not really sure what those settings are supposed to do if Mule thinks that the buffer contents are not Japanese. Does your coding-priority-list look like this? Priority order for recognizing coding systems when reading files: 1. shift_jis 2. iso-2022-7bit 3. ctext 4. iso-8859-1 5. euc-jp 6. iso-2022-lock 7. big5 8. no-conversion If so, what may be happening is that Mule is accepting characters and trying to guess the right encoding. It sees something that can't be shift-JIS, and can't be 7-bit JIS. So it expects either X Compound Text or ISO-8859-1.... Have you set language environment from the Mule menu? Your LANG is properly set to `ja' on a login via the Mac? Either of those should fix the coding-priority-list. -- 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."