bug#5235: 23.1; Unibyte keyboard input problem

[Jason Rumney <jasonr@gnu.org>]

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.