Re: Unicode input on Windows Emacs: any plans?

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

On 2014-03-28, Eli Zaretskii <eliz@gnu.org> wrote:
> No, I meant that the input loop now gets Unicode codepoints on systems
> that support that.

Yes, this is a major simplification!

>  More often than not, ToUnicode is not needed.

AFAIU, getting any kind of close-to-correct behaviour requires either
calling TranslateMessage() on all Down/Up events, or calling
ToUnicode() explicitly on all events.

>> This matches my experiments with 24.3: the simplest cases of Unicode
>> input work, the more complicated ones fail.¹⁾
>
> Please report those cases as bugs, and please include all the
> necessary details to reproduce the problems.  Thanks.

Too much work…  But here is a copy of my notes of today (reading
  http://fossies.org/dox/emacs-24.3/w32fns_8c_source.html
).

Ilya

=============================================== lispy_function_keys[] (named non-main-island “unprintable” keys)
http://fossies.org/dox/emacs-24.3/keyboard_8c_source.html	(SPACE, ABNT_C1, ABNT_C2 considered “printable”; OK!)
	comment may be improved: KEYPAD stuff, actually, comes from the following:

=============================================== map_keypad_keys()
http://fossies.org/dox/emacs-24.3/w32fns_8c_source.html#l02209

=============================================== Logic of TranslateMessage() for non-special-cased keys:
			[Basically, all cases when TranslateMessage()
			 is not called are WRONG!]
  Convert numpad-vk to special values near 0x90;		(breaks translation, but translation is disabled anyway)
  If vk < 0x100 and has Emacs’ key-name: do not translate;	(SPACE has no name!)
  Otherwise:	LCONTROL & RMENU & !user_disabled_this: translate;
  Otherwise:	has recognized modifiers (except shift and CapsLock): manually translate:
  			if 'A' … 'Z': ————? WM_CHAR with 'A' … 'Z' or 'a' … 'z';
  			otherwise:	Using only SHIFT/CTRL/ALT/CAPSLOCK modifiers (chiral, and tuned for AltGr too!),
  					  call ToUnicode() (with correct limit on the length of the buffer);
  					  convert to ASCII (with wrong limit on the length of the buffer).
  						(Should return complete gibberish if output is of length>1:
  							See ansi_code[2] and no treatment for dead_key > 2)
  					  Post (Windows/Emacs???) messages for the ASCII chars.
  Otherwise:	translate

=============================================== WM_INPUTLANGCHANGE
Complete nonsense

=============================================== Treatment of WM_CHAR

BUG: The modifiers (Alt/Ctrl) are passed downstream.  Ctrl should not
be passed at all (unless the delivered char is in 0..0x20 or 0x7f);
Alt/Win/etc should be passed only if their presence is not changing
the result of ToUnicode() (this requires a non-destructive call of
ToUnicode()).