|
From: | Jason Rumney |
Subject: | bug#5235: 23.1; Unibyte keyboard input problem |
Date: | Thu, 24 Dec 2009 23:21:41 +0800 |
User-agent: | Mozilla-Thunderbird 2.0.0.22 (X11/20090706) |
Stefan Monnier wrote:
I'll try to explain why I need unibyte mode. I'm maintener of a C/C++ source code which has comments coded in cp1250 (polish language) but strings in code are coded in cp852. So I have two different code pages in source code file. This is old source code and it was developed in Windows (that's why comments are in cp1250) but is compiled to work on MS-DOS (that's why strings are coded in cp852).So what happens if you read those files as binary (i.e. C-x RET r binary RET)?
At best, he'd end up silently screwing up his files even further, with cp1250, cp852 and now utf-8 encoded characters in them. More likely he would still get prompted when saving, just as if he'd used cp1250 or cp852 to read them.
The problem here is the files, not Emacs. Basically the reason for using unibyte is that it allows the user to bury their head in the sand and pretend the problem does not exist.
I work on similar files in my day job, with Japanese comments in ShiftJIS and Chinese comments in GB2312. An easy method of fixing such files would be nice, but the best I can think of would be to provide a recode-region function, which would still be too much manual work to be worth it to me given that I can barely make sense of the Japanese comments and can't make any sense of the Chinese ones. The original poster might be more motivated to make use of such a function if it existed though.
[Prev in Thread] | Current Thread | [Next in Thread] |