Red Hat Bugzilla – Bug 114807
RFE: detect the terminal coding system
Last modified: 2007-11-30 17:10:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4.1)
Description of problem:
To avoiding the different encoding output easily, how about adding the
elisp to autodetecting terminal-encoding-system according to the locale?
I'm often loggin into the remote machine which has the different
locale and run it with -nw then. (e.g. local machine is ja_JP.UTF-8
but remote machine is ja_JP.eucJP). so the terminal is running as
ja_JP.UTF-8, and output from the remote machine is EUC-JP. basically
such output is broken. so if it's set according to the current locale,
it would be great.
Here is what I actually use:
(intern (let ((target (shell-command-to-string "locale charmap")))
(downcase (substring target
0 (1- (length target)))))))
Perhaps I'm missing something, but even after setting say
in the remote xemacs session, ja still doesn't display
correctly in the utf-8 terminal, right?
So is the underlining complaint that in the ja_JP.eucJP locale,
the xemacs coding-system should be euc-jp and not iso-2022-jp?
Well no, (set-terminal-coding-system 'euc-jp), such remote xemacs
session doesn't display correctly in the UTF-8 terminal. even the
locale on the remote host is changed to UTF-8 locale.
well, my request is, terminal-coding-system shouldn't assume any
encoding. instead, it should be decided from the current locale.
basically terminal-coding-system affects only -nw. even if unknown
encoding is specified, it uses the value as default-coding-system;
e.g. when you run xemacs on LANG=C.
Why this problem appears, you know gnome-terminal doesn't take care
iso-2022-jp unless you change the terminal encoding to iso-2022-jp on
Perhaps I should file a way to reproduce it for you:
1. run gnome-terminal with ja_JP.UTF-8.
2. ssh to the remote host.
3. make sure the locale is ja_JP.eucJP on the remote host.
4. run xemacs -nw on the remote host.
5. input Japanese.
you should see the broken Japanese. so if you change
terminal-coding-system to UTF-8 to fix this,
1. run gnome-terminal on the remote host.
2. run xemacs -nw on that terminal.
assuming the remote host is still using ja_JP.eucJP. on such
environment, gnome-terminal can't display correctly because xemacs
outputs the characters as UTF-8, but gnome-terminal is assuming the
output is EUC-JP.
my request is to the flexible use on the terminal.
erstwhile terminal like kterm supports both of encoding; EUC-JP and
ISO-2022-JP. so almost applications were no problem as long as they
supports ISO-2022-JP output. and it was most safe to handle the output.
However gnome-terminal doesn't take care such special case. so it
means we are missing safe encoding to output Japanese.
This should already be somewhat better in xemacs-21.4.15-1
and later, since I ported "lang-coding-systems-init.el" from
the emacs package into site-start.el: it now sets
terminal-coding-system for utf-8 and CJK native locales.
It looks good and works fine. it's worth closing this bug then.