Ar an naoú lá is fiche de mí Bealtaine, scríobh Richard:
often using 'gnuclient -nw' thorugh a ssh connection and
never
had problems until I tried UTF8 chars eg äöü. Hitting such char
invokes some ESC sequences instead of inserting the char as
expected.
The settings are LANG=en_US.UTF-8 on both ends. The UTF chars
work perfectly in an xterm. What am I missing?
xemacs-21.5.29
A couple of things can go wrong:
— XEmacs looks at LC_CTYPE, not LANG. Setting LANG to en_US.UTF-8 may make
setlocale(LC_CTYPE, NULL) to return en_US.UTF-8, or it may not. If it has
worked, M-x describe-language-environment RET RET will say English (UTF-8),
and the TTY will behave correctly. There are ways to configure the TTY
encoding independent of the language environment, but it’s probably simplest
and most constructive to get the language environment correct.
— The default input mode is actively unhelpful for Western Europeans who
speak languages that are not English. If this is your problem, typing ü will
bring up a prompt “Shell command on region: ”, whereas typing č or € will
insert those characters. To fix this, you need the following in your init
file:
(set-input-mode nil nil 'character)
(push #'(lambda (console)
(and (eq 'tty (console-type console))
(set-input-mode nil nil 'character nil console)))
create-console-hook)
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta