Re: Bug#435452: emacs22: `set-keyboard-coding-system' fails in non-X11 mode]

[Kenichi Handa]

In article <address@hidden>, address@hidden (Ludovic Court$(D+2(Bs) writes:

> Hi,
> Sven Joachim <address@hidden> 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
address@hidden