Bug 114807
| Summary: | RFE: detect the terminal coding system | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Akira TAGOH <tagoh> |
| Component: | xemacs | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | Keywords: | FutureFeature |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 21.4.15-1 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-04-02 12:17:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? 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. 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. Thanks! |
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)))))))