GNU bug report logs -
#5235
23.1; Unibyte keyboard input problem
Previous Next
Full log
Message #20 received at 5235 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Friday 18 December 2009 10:46:09 Eli Zaretskii wrote:
> > From: Tomasz Zbrożek <scianagoryczy <at> wp.pl>
> > Date: Thu, 17 Dec 2009 20:25:58 +0100
> > Cc: 5235 <at> emacsbugs.donarmstrong.com, bug-gnu-emacs <at> gnu.org
> >
> > 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 when you visit this file in "emacs --unibyte", the cp852 strings
> look like gibberish, right? Only the cp1250 comments are displayed
> correctly, right?
Right, I do not see cp852 correctly but it's all right. Of course I know I
will see only one code page correctly.
>
> > Of course in multibyte mode I am able to write in these code
> > pages (for example reloading file with C-x RET r) but when I select
> > cp1250 to save the buffer emacs often tells me that some cp852 coded
> > chars are not able to be saved in cp1250 and it wants me to select
> > between raw-text, no-conversion and emacs-mule. In this situation I have
> > to enter "cp1250" and force Emacs to save buffer in cp1250. So I do not
> > want to write "cp1250" again and again when saving buffer to file..
>
> You can put a coding: cookie in the file that forces Emacs to use
> cp1250 without asking any questions. In the first line of the file
> (in a comment) put this:
>
> -*-coding: cp1250 -*-
>
> Alternatively, add "coding: cp1250" to the file's Local Variables
> section at the end.
>
In multibyte mode it doesn't work. You see, Emacs detects that there is no
possibility to convert some of cp852 chars from emacs internal coding to the
cp1250. Thats why emacs prompts me for safe coding (raw-text, no conversion
or emacs-mule) and I have to force him to write file in cp1250. Find attached
screen-shot from such a situation. Remember, it's multibyte mode, not
unibyte. Coding system for saving the buffer is cp1250.
> > And additionaly I'm not sure
> > when I force to save my buffer in cp1250 what's going on exactly with
> > cp852 coded chars (I noticed both cp1250 and 852 chars are coded ok).
>
> So saving in cp1250 doesn't do anything bad with cp852-encoded
> characters, right? It shouldn't, IMO.
>
I'm not sure, but in fact it looks ok. I do not exactly know how it works. I
load cp1250 file to emacs internal coding. The file also has some cp852 chars
and I do not know how thay are coded to the emacs internal coding and then
how they are coded back to cp1250 when saving file :)
> > That's why I decided to use unibyte mode.
>
> Is that only because of those annoying questions in what encoding to
> save? Of are there other problems in multibyte mode that forced you
> to use --unibyte?
Yes, I want to use unibyte mode becasuse of annoying question in multibyte
mode. I do not know any way to force emacs not to ask me for coding system -
see attached screen-shot.
>
> > In fact I what to change mode when Emacs works, I mean not with --unibyte
> > but with set-buffer-multibyte to nil when cpp file is being loaded but it
> > seems this function does not work correctly or I do not undestand
> > something.
>
> Try visiting file with raw-text encoding:
>
> C-x RET c raw-text RET C-x C-f YOUR-CPP-FILE RET
Interesting, I see cp1250 polish native chars, but I can't write them using
right Alt key. It behaves exactly like in unibyte mode, instead of 'ą' I see
^E. Look at screen-shot.
It works "better" in emacs 22.3 but there the code page is iso-8859-2 even if
I use -*- coding: cp1250 -*- or other methods to set codepage, but I can
write polish natives with right ALT key (in iso-8859-2).
--
tomek
[emacs.png (image/png, attachment)]
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.