Bug 114807 - RFE: detect the terminal coding system
Summary: RFE: detect the terminal coding system
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xemacs
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-02-03 02:19 UTC by Akira TAGOH
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: 21.4.15-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-04-02 12:17:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Akira TAGOH 2004-02-03 02:19:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4.1)
Gecko/20031114

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
    (set-terminal-coding-system
     (intern (let ((target (shell-command-to-string "locale charmap")))
               (downcase (substring target
                                    0 (1- (length target)))))))

Comment 1 Jens Petersen 2004-02-05 02:59:27 UTC
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 07:03:45 UTC
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 07:07:46 UTC
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 08:58:15 UTC
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 12:17:19 UTC
It looks good and works fine. it's worth closing this bug then.
Thanks!


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