Re: Don't set coding-system in shell-mode
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Yoshiki" == Yoshiki Hayashi
<t90553(a)m.ecc.u-tokyo.ac.jp> writes:
>> 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.
If we implement that to shell-mode, I think we need same
mechanism for all buffers. You open a file with wrong
coding-system that might lose data and then you removed the
original file...
Will this be easily generalizable to other process-oriented modes?
Since what I changed is comint.el, all modes that use comint
will do the same. I think network-oriented modes does
recieving raw-data from process and then do something with
it to avoid data loss.
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.)
That would be really great.
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.
As you have written, data that looks like two escape
sequences in a row will get lost. Some data might be lost
or some garbage will be added if eol conversion is CRLF or
CR since newline is normalized to LF internally.
I'll think about it, and inform you on it if it looks feasible.
Thanks.
--
Yoshiki Hayashi