[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 <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()).
- Re: Unicode input on Windows Emacs: any plans?, (continued)
- Re: Unicode input on Windows Emacs: any plans?, Eli Zaretskii, 2014/03/25
- Message not available
- Re: Unicode input on Windows Emacs: any plans?, Ilya Zakharevich, 2014/03/28
- Re: Unicode input on Windows Emacs: any plans?, Ilya Zakharevich, 2014/03/28
- Re: Unicode input on Windows Emacs: any plans?, Eli Zaretskii, 2014/03/28
- Message not available
- Re: Unicode input on Windows Emacs: any plans?, Ilya Zakharevich, 2014/03/28
- Re: Unicode input on Windows Emacs: any plans?, Eli Zaretskii, 2014/03/29
- Message not available
- Re: Unicode input on Windows Emacs: any plans?, Ilya Zakharevich, 2014/03/29
Message not available
Message not available
Message not availableRe: Unicode input on Windows Emacs: any plans?, Ilya Zakharevich, 2014/03/28
Re: Unicode input on Windows Emacs: any plans?, Eli Zaretskii, 2014/03/29