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

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