>>>> "Yoshiki" == Yoshiki Hayashi
> Second, the point of having a shell-mode is that the behavior
> of the shell is volatile; you cannot count on repeating it.
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.
> I thought we were discussing autodetection, not recovery from
> autodetection failures?
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
> How do you define "every input/output"? Suppose the
> `cat thisfile.euc thatfile.sjis' in a shell-mode?
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.
> Something more flexible is appropriate, I think. In
> particular, if C-x C-m c is used to set the process coding
> system, then on incompatible input (ie, with euc-jp default the
> process sends a high-bit-set/high-bit-clear pair of bytes) the
> autodetect mechanism should still be used, but rather than set
> the coding system it should signal the user that the default is
> probably inappropriate (as less does on encountering an
> apparently binary file).
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.
> Be careful about backward compatibility here.
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
> I don't understand this.
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."