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

Yoshiki> But why don't you save data to a separate file if you Yoshiki> can't repeat it again? I had exactly the same thought; I think I'd probably implement it as a buffer. Especially if we could somehow use indirect buffers to present a decoded view while maintaining the real transcript in raw form in the parent buffer. However, the point is that we don't do that now, and I don't think we have a robust implementation of indirect buffers although there was some traffic indicating people wanted to do it. Yoshiki> As long as you are doing autodetection, this case can't Yoshiki> be avoided. The only way not to lose any data is using Yoshiki> binary coding-system. But I don't think that is what Yoshiki> user wants as you have written in attached message. No, if you have the literal transcript of the raw stream as you have proposed, we lose no data and we do have the possibility to change the coding system view as in a Web browser. Yoshiki> I thought we were discussing what is a good default for Yoshiki> shell-mode. It includes whether we should do Yoshiki> autodetection at all. We must, on Asian-localized systems, especially partially localized ones like Linux. Also non-Latin European scripts. Probably Latin-X systems can live without. Yoshiki> I think [shell-mode's] purpose is to keep some output, Yoshiki> not saving binary data. But we don't know what is "output" and what is "binary data". I suppose you're right, that for now we need to do something. I'm sorry, I didn't realize you were proposing a patch specific to shell-mode. I thought shell-mode was an example where it would work. Will this be easily generalizable to other process-oriented modes? Yoshiki> Then you are proposing that until screenfull of data Yoshiki> arrives, users see raw data in shell-mode? Or save Yoshiki> output seperately? Ah, you're taking my "screenful" too seriously. I meant the same thing you do by "every command" (or less for a command with large amounts of output like `ls -lR /'). Yoshiki> 1. Try to autodetect every input/output by resetting Yoshiki> coding-system. Yoshiki> I meant every command. If you are using localized OS Yoshiki> such as Solaris 2.6, some commands output localized text. Yoshiki> Say you are using Japanese version of Solaris and types w Yoshiki> RET. Its output contains euc-jp text. Then execute Yoshiki> commands that outputs shift_jis. If autodetection is not Yoshiki> done, that will print garbage. Right, and I gave an example where a single command generates garbage. What I would like to see is a way to save the original data, set a region on the screen, and have a command `coding-revert-region' that grabs the region from the saved transcript, and then we can apply `decode-coding-region' to that region. (At the user level all this would be done with a single interactive command.) Coordination of the literal transcript buffer and the presentation buffer would be tricky; I think I know how to go from literal -> presentation but I don't know whather that would be invertible. I'll think about it, and inform you on it if it looks feasible. Yoshiki> That should be handled by lstream or some new general Yoshiki> commands, not shell-mode. Yes, with the caveat that the decision to keep using autodetection would be made by shell-mode, and the underlying layer (eg, lstream) would need to provide hooks so that autodetection can signal rather than trigger decoding. Yoshiki> OK. I'll create a new command. I think that's best; once you've implemented it and people can see how it works, we can decide whether the replace the old command with it. Yoshiki> 4. (Optional) Implement a way to change coding-system Yoshiki> permanently. Yoshiki> You start shell mode with autodetection, but now you know Yoshiki> you only get iso-8859-1. Then you can set coding-system Yoshiki> for input/output forever. Oh. I don't much like that. Often enough I cat or less the wrong file and find something interesting in it; even if I know that what I _want_ is Thai-XTIS, I don't want to lose the solution to the koan just 'cause it appeared in mojibake due to Devanagari that accidentally got into the buffer ;-) But if a user wants it, it might be useful. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."