[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5235: 23.1; Unibyte keyboard input problem

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 (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]