[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 ?
--
tomek
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.
--
tomek
- bug#5235: 23.1; Unibyte keyboard input problem, Tomasz Zbrożek, 2009/12/17
- Re: bug#5235: 23.1; Unibyte keyboard input problem, Jason Rumney, 2009/12/17
- Re: bug#5235: 23.1; Unibyte keyboard input problem, Tomasz Zbrożek, 2009/12/17
- bug#5235: 23.1; Unibyte keyboard input problem, Stefan Monnier, 2009/12/23
- bug#5235: 23.1; Unibyte keyboard input problem, Jason Rumney, 2009/12/24
- bug#5235: 23.1; Unibyte keyboard input problem, Eli Zaretskii, 2009/12/24
- bug#5235: 23.1; Unibyte keyboard input problem,
Tomasz Zbrożek <=
- bug#5235: 23.1; Unibyte keyboard input problem, Jason Rumney, 2009/12/25
- bug#5235: 23.1; Unibyte keyboard input problem, Tomasz Zbrożek, 2009/12/25
- bug#5235: 23.1; Unibyte keyboard input problem, Tomasz Zbrożek, 2009/12/30
- bug#5235: 23.1; Unibyte keyboard input problem, Eli Zaretskii, 2009/12/26
- bug#5235: 23.1; Unibyte keyboard input problem, Eli Zaretskii, 2009/12/25
- bug#5235: 23.1; Unibyte keyboard input problem, Stefan Monnier, 2009/12/30