In article <87hcmi2jj8.fsf@chbouib.org>, ludo@gnu.org (Ludovic Court$(D+2(Bs) writes: > Hi, > Sven Joachim writes: >>>> Invoking `set-keyboard-coding-system' in an "emacs -nw" session fails. >>>> For instance, asking it `no-conversion' (which is needed so that dead >>>> keys work as expected) fails: >>> >>>> Unsupported coding system in Encoded-kbd mode: no-conversion >>> >>> I don't understand why you have to set >>> keyboard-coding-system to no-conversion for dead keys. Dead >>> keys must be handled by terminal, and Emacs just receives >>> the resulting character (encoded in your locale) from the >>> terminal. So, setting keyboard-coding-system to what is >>> appropriate for your locale should work well, and that >>> should be done automatically. > Indeed, using "C" as my locale fixes the problem (I used to have > "LC_CTYPE=fr_FR"). > Strangely enough, Emacs 21.4.1 with "LC_CTYPE=fr_FR" doesn't have the > problem (i.e., dead keys are usable). Does it mean that you have a problem with Emacs 22 with LC_CTYPE=fr_FR? In that locale, "emacs -nw" should automatically set keyboard-coding-system to latin-1 and the input mode to (t nil 0 7), and thus it should accept latin-1 characters sent from a terminal correctly. What happens when you type some latin-1 character with dead-key method under LC_CTYPE=fr_FR? > Checking the "Meta Sends Escape" box of the xterm in which I run Emacs > 22 also fixes the problem, even with a non-C locale. It seems that your Emacs' input mode is set not to accept 8-bit input. Please tell me what is shown by ESC : (current-input-mode) RET > I guess I'm just displaying my lack of familiarity with how terminals > work... >>> What other choices were tried? utf-8, latin-X should all >>> work. What is your locale? > With a "C" locale, utf-8, latin-1, and others are accepted, whereas > `no-conversion' yields the above error message. That is because setting keyboard-coding-system to no-conversion is useless. --- Kenichi Handa handa@m17n.org