GNU bug report logs -
#5235
23.1; Unibyte keyboard input problem
Previous Next
Full log
Message #26 received at 5235 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 4 years and 301 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.