Re: Fwd: 23.0.50; can't input chinese punctuation on w32 platform

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Fri, 01 Feb 2008 16:05:56 +0000, Jason Rumney <jasonr@gnu.org> said:

>>> AFAICT, CJK punctuation, Kana, Jamo, Kanbun, Bopomofo, CJK
>>> radicals, Thai and possibly Greek and Cyrillic are potentially
>>> problematic.
>>> 
>> 
> I thought mule-unicode-* covers Greek and Cyrillic quite well.
>> Doesn't it?
>> 

> mule-unicode-* covers all the above. The issue is whether files
> containing such characters can be written in the relevant non-UTF
> coding systems.

Even for Greek and Cyrillic, a user may want it mapped to
japanese-jisx0208 rather than mule-unicode-* in some situation.

FWIW, the Mac Carbon port handles Unicode keyboard events in the
following way:

* ASCII character, with or without modifiers
  -> ASCII_KEYSTROKE_EVENT

* Non-ASCII character with some modifiers
  -> MULTIBYTE_CHAR_KEYSTROKE_EVENT with either CHARSET_8_BIT_CONTROL,
     charset_latin_iso8859_1, or charset_mule_unicode_* code.

* Non-ASCII character without any modifiers
  -> The event comes with some script/language information.  So we can
     distinguish mule-unicode-0100-24ff Greek from japanese-jisx0208
     Greek in principle even though they have the same Unicode
     codepoint.  Likewise for CJK characters.  Because the usual Emacs
     keyboard events cannot carry such script/language information, we
     pack the raw Unicode text input data and the script/language info
     into a special event MAC_APPLE_EVENT instead.  Then it is decoded
     at the Lisp level.

     (define-key special-event-map [mac-apple-event] 'mac-dispatch-apple-event)
     (define-key mac-apple-event-map [text-input unicode-for-key-event]
       'mac-ts-unicode-for-key-event)

     (defun mac-ts-unicode-for-key-event (event)
       "Convert Unicode key EVENT to Emacs key events and unread them."
       (interactive "e")
       (let* ((ae (mac-event-ae event))
	      (text (cdr (mac-ae-parameter ae "tstx" "utxt")))
	      (script-language (mac-ae-script-language ae "tssl"))
	      (coding (or (cdr (assq (car script-language)
				     mac-script-code-coding-systems))
			  'mac-roman)))
	 (if text
	     (mac-unread-string (mac-utxt-to-string text coding)))))

As for the W32 port, Emacs 22.2 should avoid drastic changes in
general.  How about using the new code (i.e., mapping to
mule-unicode-* etc.) only for the with-modifier case, and leaving the
without-modifier case to encoded-kb as in Emacs 22.1?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp