Re: Don't set coding-system in shell-mode

Ben Wing <ben(a)666.com&gt; writes: > Martin Buchholz wrote: > > > I approve the patch, if this really works (it somewhat surprises me). > > It did not work when I originally wrote this code. Does this also > > work correctly for ttys? I mean, is the tty coding system properly > > autodetected using determine_real_coding_system? > > > > Blue Sky: Can > > > > cat test.euc > > cat test.jis > > > > possibly work `correctly'? Yes, because you can always distinguish that two coding-system. When escape sequence `ESC [ $ B' is found, it's most likely that coding-system is iso-2022-jp. When two byte sequence has its MSB set, then it is probably euc-jp. > > We know that the Latin equivalent > > > > cat test.iso8859-2 > > cat test.iso8859-1 > > > > cannot. Because there's no particular characteristics in that coding-system. It's just 8bit byte sequences. So it depends on what language-environment you are in. If you only use those two, it may be possible to disguinsh them with some good heuristics. > Why not? Shell mode could reset things so as to force autodetection for the > output of each command issued. Even your second example could work if those > files had proper ISO2022 or X-Compound-Text or whatever escape sequences in > them, or magic XEmacs coding-system: stuff, etc. to indicate the coding > system. (Granted, not likely.) Here's a list of candidate to Mule-izing shell-mode. 1. autodetect every time. 2. autodetect only first time. 3. set default coding-system and allow C-x RET c to alter default value. Now I found doing this cat test.ascii cat test.sjis will set process-output-coding-system to raw-text, I don't think 2 is a good plan (my original one). I think 3 is best as most user use only one coding-system. I'll send patch to do this.

Besides that, it would be nice to have convenience way to set coding-system of next command in shell-mode. Maybe command to change process coding-system for permanently would be nice, too. -- Yoshiki Hayashi