bug#5235: 23.1; Unibyte keyboard input problem

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

Hi,
In Emacs 23.1, in unibyte mode (emacs --unibyte) and with windows-1250
coding I can't write Polish chars with right Alt key.  For example right Alt 
+ 'a' gives ^E on the screen. In Emacs 22.3 it works fine (I see polish 
char 'ą'), but there there is other problem that buffer is printed in 
iso-8859 even if I configure Language Environment to use windows-1250.  In 
23.1 with such Language Environment (configured to use cp1250) polish special 
chars read from file are printed correctly (I see them) but I can't write 
them using right Alt key (or even input mode polish-slash).

I checked it on GNU/Linux and also on MS Windows XP (pure NT-Emacs and 
EmacsW32), it's the same problem.

Regards
Tomek

In GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2009-08-15 on scianagoryczy
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: pl_PL.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  gud-tooltip-mode: t
  global-hl-line-mode: t
  global-auto-revert-mode: t
  display-time-mode: t
  auto-insert-mode: t
  yas/minor-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<send-emacs-bug-report>

Recent messages:
Loading /home/tomek/emacs/color-theme-6.6.0/themes/color-theme-library.el 
(source)...done
Loading autoinsert...done
Loading time...done
Loading autorevert...done
Loading hl-line...done
Loading gud...done
Loading paren...done
Loading which-func...done
For information about GNU Emacs and the GNU system, type C-h C-a.
call-interactively: Text is read-only

Re: bug#5235: 23.1; Unibyte keyboard input problem

[Jason Rumney]

Tomasz Zbrożek wrote:
> Hi,
> In Emacs 23.1, in unibyte mode (emacs --unibyte)
Does it work as expected if you remove the --unibyte?

Re: bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

Thanks for reply!
In multibyte mode (I mean no --unibyte) Emacs 23.1 works great for me :)
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). 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.. 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). 
That's why I decided to use unibyte mode. But as I described I found it's a 
problem with writing polish native chars in unibyte mode in Emacs 23.1. 
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.

Here is how I configure Language Environment:
 '(current-language-environment "Polish")
 '(language-info-custom-alist (quote (("Polish" (charset cp1250) 
(coding-system cp1250) (coding-priority cp1250 cp852) (nonascii-translation . 
cp1250) (unibyte-display . cp1250)))))
'(unibyte-display-via-language-environment t)

--
tomek

On Thursday 17 December 2009 17:47:29 Jason Rumney wrote:
> Tomasz Zbrożek wrote:
> > Hi,
> > In Emacs 23.1, in unibyte mode (emacs --unibyte)
>
> Does it work as expected if you remove the --unibyte?



-- 
tomek

bug#5235: 23.1; Unibyte keyboard input problem

[Stefan Monnier]

> In multibyte mode (I mean no --unibyte) Emacs 23.1 works great for me :)

--unibyte is deprecated, so rather than try and "fix" it, we want to fix
the problem that caused you to use --unibyte.

> 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)?


        Stefan

bug#5235: 23.1; Unibyte keyboard input problem

[Jason Rumney]

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.

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> Date: Thu, 24 Dec 2009 23:21:41 +0800
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Tomasz Zbrożek <scianagoryczy@wp.pl>,
> 	5235@emacsbugs.donarmstrong.com, bug-gnu-emacs@gnu.org
> 
> The problem here is the files, not Emacs.

I'd say, more accurately: the problem is that Emacs does not support
such use-cases.  It would be nice if we did: having comments in one
encoding and strings in another is not such a corner case.

> 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

We would also need a way to encode different regions differently.
Perhaps adding special text properties to guide the encoding process
would be a way of doing that (we already have charset properties for
similar reasons).

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

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

[Jason Rumney]

Tomasz Zbrożek wrote:
> 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 ?

Keyboard input on Windows is Unicode in 23.1.  In previous versions it 
was in the system default codepage.



>  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 ?
>   

What is "correct" is undefined in unibyte mode, since unibyte deals with 
bytes, not characters.

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

On Friday 25 December 2009 12:23:42 Jason Rumney wrote:
> Tomasz Zbrożek wrote:
> > 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 ?
>
> Keyboard input on Windows is Unicode in 23.1.  In previous versions it
> was in the system default codepage.
Is this why I get '^E' code instead of 'ą' when I press right ALT + 'a' in 
unibyte mode with codepage set to cp1250 (emacs version 23.1) ?
I checked it on Windows and GNU/Linux and it works the same.

Is there possibility to change emacs configuration somehow to get proper 
polish chars when writing in unibyte mode ?



-- 
tomek

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]


>I think Emacs developers are much more motivated to improve the
>multibyte mode than to fix the unibyte mode.  I cannot speak for the
>head maintainers, but that is certainly my opinion: the unibyte mode
>should simply die, as a mode for interactive editing.
ok, I will not use unibyte mode :)

>You received several suggestions for trying things in multibyte mode.
>Perhaps you could try them and see if they allow you to edit your
>programs without screwing up the cp852 characters.  If something is
>still wrong, please describe the problems here: we are much more
>likely to find a solution for multibyte mode editing than for unibyte.
so, my only problem (in multibyte mode) is annoying question for safe coding 
when saving buffer, I attach a new screenshot:
- on the most upper buffer you see my file which has originally some cp1250 
chars and also cp852 chars, 
- on the middle buffer you see that I have cp1250 set to save this buffer, 
- and below there is a buffer with information that there is no possibility to 
encode \210 char (originally cp852) to cp1250 (because cp1250 is my codepage 
to save, but of course after saving this char in the file should be cp852 
coded and it will be when I force cp1250 - this is ok)

I can't find any way to force emacs not to prompt me with codepage selection, 
I understand emacs treats it like an error (in his opinion \210 char is 
wrong) but I would like to set somehow that cp1250 is safe,
"-*- coding: cp1250 -*-" or modify-coding-system-alist function is not 
solution

my only question is: how to configure emacs to omit this codepage selection in 
such situation? 

I would be thankful for help!

[-- Attachment #2: emacs.png --]
[-- Type: image/png, Size: 160570 bytes --]

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> From: Tomasz Zbrożek <scianagoryczy@wp.pl>
> Date: Sat, 26 Dec 2009 13:45:53 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  5235@emacsbugs.donarmstrong.com,
>  Eli Zaretskii <eliz@gnu.org>
> 
> encode \210 char (originally cp852) to cp1250 (because cp1250 is my codepage 
> to save, but of course after saving this char in the file should be cp852 
> coded and it will be when I force cp1250 - this is ok)
> 
> I can't find any way to force emacs not to prompt me with codepage selection, 
> I understand emacs treats it like an error (in his opinion \210 char is 
> wrong) but I would like to set somehow that cp1250 is safe,
> "-*- coding: cp1250 -*-" or modify-coding-system-alist function is not 
> solution
> 
> my only question is: how to configure emacs to omit this codepage selection in 
> such situation? 

Does it help to evaluate the expression below?

   (aset latin-extra-code-table ?\210 t)

Please do that _before_ visiting files which have the \210 character.
Then try to save such a file and see if this helps.

The above only handles the \210 character, so please don't try to use
any other characters whose code is between 128 and 160.  If this
works, it is trivial to cover the entire range, of course.

If the above does not help with cp1250, please try the same with
latin-2 instead (you will have to modify the `coding:' cookie for this
to work).

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> From: Tomasz Zbrożek <scianagoryczy@wp.pl>
> Date: Fri, 25 Dec 2009 12:03:29 +0100
> Cc: 5235@emacsbugs.donarmstrong.com, bug-gnu-emacs@gnu.org
> 
> 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 think Emacs developers are much more motivated to improve the
multibyte mode than to fix the unibyte mode.  I cannot speak for the
head maintainers, but that is certainly my opinion: the unibyte mode
should simply die, as a mode for interactive editing.

You received several suggestions for trying things in multibyte mode.
Perhaps you could try them and see if they allow you to edit your
programs without screwing up the cp852 characters.  If something is
still wrong, please describe the problems here: we are much more
likely to find a solution for multibyte mode editing than for unibyte.

bug#5235: 23.1; Unibyte keyboard input problem

[Stefan Monnier]

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

That would be a bug: a file visited as `binary' (or as `raw-text')
should be placed in a unibyte buffer, so it should not screw anything up
more than was already the case to start with.

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

Of course, but if you start with such files and can't (or don't want to)
recode the parts consistently, we can't do much better.

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

I'm not sure what would be the best approach in general or in particular
cases, but we could certainly provide a command that recodes comments.
Or another one that looks for invalid byte sequences (i.e. decoded as
eight-bit-bytes) and tries to re-decode them with a secondary coding system.


        Stefan

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

Eli,
is something going on with case 5235 on emacs bug list ?
I mean, will your patch (as I remember it needs some improvement ;) be 
implemented to the emacs current version ?

best regards!
-- 
tomek

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> From: Tomasz Zbrożek <scianagoryczy@wp.pl>
> Date: Fri, 26 Feb 2010 21:42:34 +0100
> 
> Eli,
> is something going on with case 5235 on emacs bug list ?
> I mean, will your patch (as I remember it needs some improvement ;) be 
> implemented to the emacs current version ?

I didn't yet have time to work on the improvement, sorry.  So I guess
it will not be in Emacs 23.2.

bug#5235: 23.1; Unibyte keyboard input problem

[Lars Ingebrigtsen]

Tomasz Zbrożek <scianagoryczy@wp.pl> writes:

> In Emacs 23.1, in unibyte mode (emacs --unibyte) and with windows-1250
> coding I can't write Polish chars with right Alt key.

The --unibyte switch has been removed, so I can't reproduce the bug in
question here, so I'm going to go ahead and guess that this is no longer
relevant, and I'm closing this bug report.  Although skimming this bug
report, I'm wondering whether this is still relevant if you're
explicitly (set-buffer-multibyte nil) and entering text, but...  I'm not
sure?  If it is, please respond to the debbugs address, and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

>Does it help to evaluate the expression below?
>
>  (aset latin-extra-code-table ?\210 t)
>
>Please do that _before_ visiting files which have the \210 character.
>Then try to save such a file and see if this helps.
>
>The above only handles the \210 character, so please don't try to use
>any other characters whose code is between 128 and 160.  If this
>works, it is trivial to cover the entire range, of course.
>
>If the above does not help with cp1250, please try the same with
>latin-2 instead (you will have to modify the `coding:' cookie for this
>to work).

(aset latin-extra-code-table ?\210 t) does not help with cp1250 and when I try 
to save buffer in latin-2 there is no need to use latin-extra-code-table 
because in this case there is no problem with \210 char encoding

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> From: Tomasz Zbrożek <scianagoryczy@wp.pl>
> Date: Sat, 26 Dec 2009 18:03:27 +0100
> 
> >Does it help to evaluate the expression below?
> >
> >  (aset latin-extra-code-table ?\210 t)
> >
> >Please do that _before_ visiting files which have the \210 character.
> >Then try to save such a file and see if this helps.
> >
> >The above only handles the \210 character, so please don't try to use
> >any other characters whose code is between 128 and 160.  If this
> >works, it is trivial to cover the entire range, of course.
> >
> >If the above does not help with cp1250, please try the same with
> >latin-2 instead (you will have to modify the `coding:' cookie for this
> >to work).
> 
> (aset latin-extra-code-table ?\210 t) does not help with cp1250 and when I try 
> to save buffer in latin-2 there is no need to use latin-extra-code-table 
> because in this case there is no problem with \210 char encoding

So does this mean using latin-2 solves your original problem as well?
That is, are you able to edit the source files without the annoying
questions from Emacs when you save the files?

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

>So does this mean using latin-2 solves your original problem as well?
>That is, are you able to edit the source files without the annoying
>questions from Emacs when you save the files?

No, latin-2 does not solve my problem:) I do not want to read/write file in 
latin-2 but cp1250! 
But yes, when saving in latin-2 then there is no problem (I mean, no annoying 
question) which exists when saving with cp1250. I understand that's 
because "convertion tables" are different for these both codepages and e.g. 
\210 code is differently converted.

Once again, I want to load my file with cp1250, edit it (writing polish chars 
and see them properly on screen) and save buffer with cp1250. (Of course all 
the strange chars which comes from cp852 should be unchanged.) When I load 
file with cp1250 and then save this buffer with latin-2 then all the polish 
chars that were originally in cp1250  will be now in latin-2 and this is not 
what I want.

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> From: Tomasz Zbrożek <scianagoryczy@wp.pl>
> Date: Sat, 26 Dec 2009 20:19:38 +0100
> 
> >So does this mean using latin-2 solves your original problem as well?
> >That is, are you able to edit the source files without the annoying
> >questions from Emacs when you save the files?
> 
> No, latin-2 does not solve my problem:) I do not want to read/write file in 
> latin-2 but cp1250! 

Does the patch below give good results?

You will need to rebuild Emacs or manually load mule-cmds.elc, after
patching and compiling it.  Then set
select-safe-coding-system-respect-auto-coding to a non-nil value, and
see if the annoying question goes away while the files are saved
correctly without screwing up the cp852 characters.

Index: lisp/international/mule-cmds.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/international/mule-cmds.el,v
retrieving revision 1.386
diff -u -r1.386 mule-cmds.el
--- lisp/international/mule-cmds.el	9 Dec 2009 00:55:55 -0000	1.386
+++ lisp/international/mule-cmds.el	26 Dec 2009 21:21:17 -0000
@@ -807,6 +807,9 @@
     (set-window-configuration window-configuration)
     coding-system))
 
+(defvar select-safe-coding-system-respect-auto-coding nil
+  "If non-nil, always use coding system from coding cookies &c if possible.")
+
 (defun select-safe-coding-system (from to &optional default-coding-system
 				       accept-default-p file)
   "Ask a user to select a safe coding system from candidates.
@@ -976,7 +979,14 @@
 		(push (car elt) safe))
 	    (push (car elt) unsafe)))
 	(if safe
-	    (setq coding-system (car safe))))
+	    (setq coding-system (car safe))
+	  ;; If default-coding-system is in unsafe, and the user
+	  ;; insists, use it.
+	  (if (and select-safe-coding-system-respect-auto-coding
+		   default-coding-system
+		   (memq (caar default-coding-system) unsafe))
+	      (setq coding-system (caar default-coding-system)))))
+
 
       ;; If all the defaults failed, ask a user.
       (when (not coding-system)

bug#5235: 23.1; Unibyte keyboard input problem

[Tomasz Zbrożek]

Eli, it looks your patch works OK :D But...
On the default polish environment setting (latin-2), when I have -*- coding: 
cp1250 -*- in my file and when I try to save file with your feature I get 
such a message in minibuffer:

Selected encoding iso-latin-2-unix disagrees with windows-1250-unix specified 
by file contents.  Really save (else edit coding cookies and try again)? (yes 
or no) 

when I press yes the coding is gibberish in saved file.

If I use modify-coding-system-alist instead of "-*- coding:" result is the 
same, I mean gibberish but there is no question.

But when I change a little bit language enviroment to:

 '(language-info-custom-alist (quote (("Polish" (coding-priority cp1250)))))

then everything is OK and your patch works fine (no question when saving and 
coding is ok)! In this case I do not need to specify coding with "-*- 
coding:" or modify-coding-system-alist.

bug#5235: 23.1; Unibyte keyboard input problem

[Eli Zaretskii]

> From: Tomasz Zbrożek <scianagoryczy@wp.pl>
> Date: Sun, 27 Dec 2009 14:30:47 +0100
> 
> Eli, it looks your patch works OK

Thanks for testing.

> :D But...
> On the default polish environment setting (latin-2), when I have -*- coding: 
> cp1250 -*- in my file and when I try to save file with your feature I get 
> such a message in minibuffer:
> 
> Selected encoding iso-latin-2-unix disagrees with windows-1250-unix specified 
> by file contents.  Really save (else edit coding cookies and try again)? (yes 
> or no) 

This is expected, I think.  I could make it honor the `coding' cookie
even in that case, but I'd like first to know if this kind of solution
is acceptable (below).

> But when I change a little bit language enviroment to:
> 
>  '(language-info-custom-alist (quote (("Polish" (coding-priority cp1250)))))
> 
> then everything is OK and your patch works fine (no question when saving and 
> coding is ok)!

Good.

Handa-san, could you please tell if you see anything wrong with this
semi-kludgey solution?

Stefan and Yidong: assuming that Handa-san has no objections, is it
okay to commit the patch I sent yesterday?

bug#5235: 23.1; Unibyte keyboard input problem

[Stefan Monnier]

> This is expected, I think.  I could make it honor the `coding' cookie
> even in that case, but I'd like first to know if this kind of solution
> is acceptable (below).

This aproach looks OK, actually, yes.  Basially, the user would set

  -*- coding: cp1250; select-safe-coding-system-respect-auto-coding: t -*-

tho in such a context a shorter varname would make sense, like
`coding-cookie-force'.  And then it'd be OK to obey it no matter what
(i.e. regardless of the default coding system, locale, etc...).


        Stefan