Re: Unicode input on Windows Emacs: any plans?

[Ilya Zakharevich]

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