From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ilya Zakharevich Newsgroups: gmane.emacs.bugs Subject: bug#23251: 25.0.92; M-< and M-> don't work with Croatian keyboard Date: Sat, 16 Apr 2016 20:47:05 -0700 Message-ID: <20160417034705.GA13745@math.berkeley.edu> References: <83a8l2ivxn.fsf@gnu.org> <83zit2gpd7.fsf@gnu.org> <20160410192754.GA11548@math.berkeley.edu> <20160410194605.GA11948@math.berkeley.edu> <20160414053713.GA29979@math.berkeley.edu> <83wpo0dxmv.fsf@gnu.org> 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 1460864903 10564 80.91.229.3 (17 Apr 2016 03:48:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Apr 2016 03:48:23 +0000 (UTC) Cc: 23251@debbugs.gnu.org, jjezina@hotmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 17 05:48:11 2016 Return-path: Envelope-to: geb-bug-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 1ardgw-0004r2-OX for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Apr 2016 05:48:10 +0200 Original-Received: from localhost ([::1]:38561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ardgw-0002go-2b for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Apr 2016 23:48:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ardgr-0002dN-Pk for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2016 23:48:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ardgo-0004m7-Hy for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2016 23:48:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ardgo-0004m3-De for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2016 23:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ardgn-00079V-Uk for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2016 23:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ilya Zakharevich Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Apr 2016 03:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23251 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23251-submit@debbugs.gnu.org id=B23251.146086483727439 (code B ref 23251); Sun, 17 Apr 2016 03:48:01 +0000 Original-Received: (at 23251) by debbugs.gnu.org; 17 Apr 2016 03:47:17 +0000 Original-Received: from localhost ([127.0.0.1]:37717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ardg5-00078V-G6 for submit@debbugs.gnu.org; Sat, 16 Apr 2016 23:47:17 -0400 Original-Received: from nm20-vm1.bullet.mail.gq1.yahoo.com ([98.136.217.32]:40531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ardg3-00078H-7k for 23251@debbugs.gnu.org; Sat, 16 Apr 2016 23:47:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460864829; bh=ROHRa039s8oyiHxDfi3lDzjp9gVYp+Eu4gp52tTY9z8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=UM8uSGAyYRtt8/QZ8dSa37LxuuPp797GUtdYCr+fgfrVKxC+gfEZDZ3aUrcm5mt3o4Sca685+AopIJVgAx4zJx/KOqI6LYyYL9w2lSc4tWia2rvEGyIe3JhAsFyOIZu6zs0Pp0u1T6PqMQnlEa9V9rx0HoATRWxi5UTeTtYV6ArwvV8816Bac4xEQggfWxh0pTu5Udy2ioKFqaOkXASTilkNM8ncufIp3y93DpcN1IBKi1tzbWyWyUGArujqndfuvU9UdedwD4MUmWQf/QErtULM3xe3tmL2myQhUSOPwat6lGwqrZ+zE4kC+CWYVeGA6JHe/SzBRlk87urtEft5Fw== Original-Received: from [98.137.12.190] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2016 03:47:09 -0000 Original-Received: from [98.136.164.68] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2016 03:47:09 -0000 Original-Received: from [127.0.0.1] by smtp230.mail.gq1.yahoo.com with NNFMP; 17 Apr 2016 03:47:09 -0000 X-Yahoo-Newman-Id: 525237.58065.bm@smtp230.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZYrM3m4VM1nGV.yXWOIxZVFaCxdq4uS8iVkVLNj8ncHY.7L 8iK0qYlhEBSkN7XsG8S.EU3Vr9FvqzIN_ZbaM21vYADv8u.DwgtoWKc1Xvqo 0dEw4BmCwRat1A_3yWikOIyNUM7mpaYdWTiDrhFQY9QbyIqMzL86sEfO1Ofs qsj8Sn8d2N7LDC0FuGZDZPbi2J9RgYlJsq5OAJn8ZiZYhz.CuEahwX581nP2 Y5aeVv.Yt_.bz8H8VSb_4HBtyUXaa2l_DyvowOmMpePkTzB.TyeG_CRPXtPE A4pFwZQF7yEac150aE7C8DqErVjJE4B_IZqMYfTzbAgisKe_hmeWKuaLeiVy v8auSulh63rAcS4f70JtII9H2.RVHMvompNbWo20ov8JpeThJNWkiMxUXiPX SZ4maL9rHFDj44t6S.VVm7vzN2mgmJpZ6kawQ9w.GlMmFs9n6WkvYWvIXYA1 99AH7.rr9Z8pNCCu3r_luc373eiA3c.Vmk3FutwVjBVD9pXyBgBaUT6eJIV2 ENToucc8JfuCt5ow- X-Yahoo-SMTP: oLSY3dWswBBqoBVzCkLl_RIsw6heKMxu8wpEbARv1SU- Content-Disposition: inline In-Reply-To: <83wpo0dxmv.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116554 Archived-At: On Thu, Apr 14, 2016 at 06:21:28PM +0300, Eli Zaretskii wrote: > Is it possible to devise a simple work-around that would depend on > some optional variable? The work-around doesn't need to handle all > usage scenarios, just allow using a particular keyboard layout with > reasonable results (e.g., it could break usage of some other layouts). > > If such work-around is possible, I think we should consider it for > the upcoming Emacs 25.1 as a temporary stopgap. I much prefer a simple heuristic which (hopefully) breaks orders of magnitude less things than what it fixes. Hopefully, this 2-LOC edit must be such! It affects ONLY the discussed case (“secondary” keys), and (if the heuristic triggers) changes it by ONLY falling back to pre-my-patch behaviour. I put a lot of comments explaining what happens, and REALLY hope that the cases where this patch HURTS would NEVER arise… Hope this helps, Ilya --- w32fns.c-pre-secondary 2015-08-16 18:53:58.569735600 -0700 +++ w32fns.c 2016-04-16 19:30:38.026157600 -0700 @@ -3149,6 +3149,42 @@ deliver_wm_chars (int do_translate, HWND wParam)); if ((r & 0xFF) == wParam) bitmap = r>>8; /* *b is reachable via simple interface */ + else + { + /* VkKeyScanW() (essentially) returns the FIRST key with + the specified character; so here the pressed key is the + SECONDARY key producing the character. + + Essentially, we have no information about the "role" of + modifiers on this key: which contribute into the + produced character (so "are consumed"), and which are + "extra" (must attache to bindable events). + + The default above would consume ALL modifiers, so the + character is reported "as is". However, on many layouts + the ordering of the keys (in the layout table) is not + thought out well, so the "secondary" keys are often those + which the users would prefer to use with Alt-CHAR. + (Moreover - with e.g. Czech-QWERTY - the ASCII + punctuation is accessible from two equally [nu]preferable + AltGr-keys.) + + SO: Heuristic: if the reported char is ASCII, AND Meta + modifier is a candidate, behave as if Meta is present + (fallback to the legacy branch; bug#23251). + + (This would break layouts + - delivering ASCII characters + - on SECONDARY keys + - with not Shift/AltGr-like modifier combinations. + All 3 conditions together must be pretty exotic + cases - and a workaround exists: use "primary" keys!) */ + if (*b < 0x80 + && (wmsg.dwModifiers + & (alt_modifier | meta_modifier + | super_modifier | hyper_modifier))) + return 0; + } if (*type_CtrlAlt == 'a') /* Simple Alt seen */ { if ((bitmap & ~1) == 0) /* 1: KBDSHIFT */