From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4.1) Gecko/20031114 Description of problem: 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)))))))
As Bug#114807 has already been closed, perhaps is this issue already fixed too?
Hmm, I guess not. I just tried to login to the remote machine from my laptop pc working on EUC-JP, and change the locale to ja_JP.eucjP on the remote machine, run emacs -nw, type M-x info, find out Mew-J info page. look at that then. This steps works on xemacs, but not emacs. probably emacs is needed same fix as you did for Bug#114807.
Hmmm, with auto-compression-mode the gzipped ja info pages display ok, not without. Perhaps we shouldn't compress them or turn on auto-compression-mode by default? Or is there a better way to fix this?
indeed. are there any problem to turn on auto-compression-mode by default?
Ok, let's try turning on auto-compression-mode in default,el.
It should be in 21.3-12.
confirmed the fix, Thanks!