GNU bug report logs - #5235
23.1; Unibyte keyboard input problem

Previous Next

Full log

Message #41 received at 5235 <at> debbugs.gnu.org (full text, mbox):

From: Tomasz Zbrożek <scianagoryczy <at> wp.pl>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 5235 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#5235: 23.1; Unibyte keyboard input problem
Date: Fri, 25 Dec 2009 12:03:29 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.