[Top][All Lists]

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

bug#5235: 23.1; Unibyte keyboard input problem

From: Tomasz Zbrożek
Subject: bug#5235: 23.1; Unibyte keyboard input problem
Date: Fri, 25 Dec 2009 12:03:29 +0100
User-agent: KMail/1.9.10

The multibyte mode and its prompts for correct codepage is not problem. I 
think it's definitelty CORRECT behaviour and it's not the case I wanted to 
submit  to you.  
I think that solution for the problem with two code pages in one file is 
unibyte mode.

I started this bug-case to get the answer to the question: why in unibyte mode 
when I try to write in cp1250 I get codes like ^E instead of proper chars in 
buffer ? This behaviour is not correct even when comparing to previous Emacs 
version (22.3). So, my question is how to fix this strange keyboard input 
behaviour in unibyte mode ?


On Thursday 24 December 2009 16:21:41 Jason Rumney wrote:
> 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]