Re: coding-system lossage with eterm

Glynn> Previously, I got the same results for undecided-unix Glynn> (left-justified mojibake), which I though was odd. However, Glynn> I've tried it again and now undecided-unix gives me Glynn> left-justified Japanese, which is what I would expect. Mule is not deterministic.... Was it the same file? I was cat'ing the same file every time, which just happened to be HTML code. So Mule saw several lines of ASCII before seeing any Japanese. I bet that is enough to defeat the heuristic. No that's wrong... see below. Glynn> Presumably the ^M results in the coding system being Glynn> assumed to be <something>-dos. *smack* Of course. I'm not used to thinking about the CR there.... Glynn> I would guess that undecided-unix would be the right thing, Glynn> _if_ it worked consistently. I don't think it can; it depends on how smart Mule is about making decisions. _If_ the HTML file is cat'ted first into a new terminal buffer, I get Japanese staircase. _If_ I do say `pwd' first, I get mojibake staircase. With 'undecided-dos as default I get left-justified, same results. If it were possible to get Mule to make decisions incrementally, eg undecided -> (see ^M) undecided-dos (continue several commands) -> (see ESC $ B) -> ISO-2022-7, it could be pretty reliable. But it looks like Mule makes its decision on the first command. So it's going to depend on usage patterns, and if we want users to be happy we're going to need to come up with some smarter heuristics.