[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unicode input on Windows Emacs: any plans?

From: Ilya Zakharevich
Subject: Re: Unicode input on Windows Emacs: any plans?
Date: Fri, 28 Mar 2014 22:08:14 +0000 (UTC)
User-agent: slrn/pre1.0.0-18 (Linux)

On 2014-03-28, Eli Zaretskii <address@hidden> 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


=============================================== lispy_function_keys[] (named 
non-main-island “unprintable” keys)       (SPACE, 
ABNT_C1, ABNT_C2 considered “printable”; OK!)
        comment may be improved: KEYPAD stuff, actually, comes from the 

=============================================== map_keypad_keys()

=============================================== 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 
  Otherwise:    LCONTROL & RMENU & !user_disabled_this: translate;
  Otherwise:    has recognized modifiers (except shift and CapsLock): manually 
                        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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]