From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ilya Zakharevich Newsgroups: gmane.emacs.help Subject: Re: Unicode input on Windows Emacs: any plans? Date: Fri, 28 Mar 2014 22:08:14 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1396044611 3074 80.91.229.3 (28 Mar 2014 22:10:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2014 22:10:11 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Mar 28 23:10:20 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WTeyi-0004Jg-0N for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Mar 2014 23:10:20 +0100 Original-Received: from localhost ([::1]:36138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTeyh-0005jJ-DV for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Mar 2014 18:10:19 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 57 Injection-Date: Fri, 28 Mar 2014 22:08:14 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="06ab0fed6ae52f560e1f8417db1ec81f"; logging-data="12317"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+iNM+/P9e1O9GEn6WcTM01" User-Agent: slrn/pre1.0.0-18 (Linux) Cancel-Lock: sha1:rBeBx0+RdTy6J6asgAxAQqiGfCw= Original-Xref: usenet.stanford.edu gnu.emacs.help:204554 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:96823 Archived-At: On 2014-03-28, Eli Zaretskii 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()).