Jason Rumney wrote:
Lennart Borgman (gmail) wrote:
We have previously on the developers list discussed coding systems for
*Shell* buffers on w32. I have sent some suggestions, but I do not
think any changes have been done yet. Could we please try to fix this?
There are two parts to this. One part is to set the coding-system for
input in default-coding-system based on the user's language environment,
as is done on other platforms. The second is to consider whether we
should make shell on Windows a special case and also set it's output
coding-system. I disagree with the second part of this, as we do not
know what commands the user will run, and what coding-system the output
will be in. If the user is running commands like grep, diff, cat etc,
then the coding-system will match the contents of the files they are
processing. If they are mostly using dir, then the DOS codepage will
certainly be better, but I do not think that is the most common use case.
What is needed to fix this is to have shell-mode set the coding system
independantly for each command that is run, but I cannot think of a good
way to detect reliably what coding system the output should be read as,
unless we make a special exception for dir and any other commands we can
think of that will cause output in the DOS codepage. Such a change would
be for after the release.
Then I suggest that we set the coding-system for in and output to those
relevant to cmd.exe now. Code for that is in my earlier suggestion.
I think it is quite hard to autodetect when coding system should change.
I would suggest that the user have control over this by in some way
specifying that Emacs should detect the coding system from the output
from the next command. And I would suggest that this should by default
only apply to the output from that special command.
We have also discussed the tab file name completion in a cmdproxy
*Shell* buffer. This is currently broken. I sent a suggestion to fix
it, but I have got no feedback whatsoever on this.
Your suggestion must have been lost in the noise, that was a very long
thread that deteriorated into off topic arguments so many people may
have given up following it. Please send your suggestion again.
http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg01128.html
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
