Bug 114807 - RFE: detect the terminal coding system
RFE: detect the terminal coding system
Product: Fedora
Classification: Fedora
Component: xemacs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2004-02-02 21:19 EST by Akira TAGOH
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 21.4.15-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-02 07:17:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2004-02-02 21:19:01 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:
(condition-case nil
     (intern (let ((target (shell-command-to-string "locale charmap")))
               (downcase (substring target
                                    0 (1- (length target)))))))
Comment 1 Jens Petersen 2004-02-04 21:59:27 EST
Perhaps I'm missing something, but even after setting say

  (set-terminal-coding-system "EUC-JP")

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?
Comment 2 Akira TAGOH 2004-02-05 02:03:45 EST
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
the gnome-terminal.

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.
Comment 3 Akira TAGOH 2004-02-05 02:07:46 EST
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.
Comment 4 Jens Petersen 2004-04-02 03:58:15 EST
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.
Comment 5 Akira TAGOH 2004-04-02 07:17:19 EST
It looks good and works fine. it's worth closing this bug then.

Note You need to log in before you can comment on or make changes to this bug.