From: Ilya Zakharevich <ilya@math.berkeley.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23251@debbugs.gnu.org, jjezina@hotmail.com
Subject: bug#23251: 25.0.92; M-< and M-> don't work with Croatian keyboard
Date: Sat, 16 Apr 2016 20:47:05 -0700 [thread overview]
Message-ID: <20160417034705.GA13745@math.berkeley.edu> (raw)
In-Reply-To: <83wpo0dxmv.fsf@gnu.org>
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 */
next prev parent reply other threads:[~2016-04-17 3:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-09 15:17 bug#23251: 25.0.92; M-< and M-> don't work with Croatian keyboard Josko
2016-04-09 16:33 ` Eli Zaretskii
[not found] ` <SN1PR10MB0655320C4FC1DAF4D6656B10B6920@SN1PR10MB0655.namprd10.prod.outlook.com>
2016-04-10 2:38 ` Eli Zaretskii
2016-04-10 19:27 ` Ilya Zakharevich
2016-04-10 19:46 ` Ilya Zakharevich
[not found] ` <SN1PR10MB0655807651B404FEE9568C41B6940@SN1PR10MB0655.namprd10.prod.outlook.com>
2016-04-12 17:59 ` Ilya Zakharevich
2016-04-12 18:43 ` Ilya Zakharevich
2016-04-14 5:37 ` Ilya Zakharevich
2016-04-14 15:21 ` Eli Zaretskii
2016-04-17 3:47 ` Ilya Zakharevich [this message]
2016-04-17 3:56 ` Ilya Zakharevich
2016-04-17 14:48 ` Eli Zaretskii
[not found] ` <SN1PR10MB065553E636A5FED800084045B66C0@SN1PR10MB0655.namprd10.prod.outlook.com>
2016-04-21 16:12 ` Eli Zaretskii
2016-04-23 15:56 ` Josko
2016-04-23 17:56 ` Eli Zaretskii
2016-04-23 21:34 ` John Wiegley
2016-04-21 16:10 ` Eli Zaretskii
2016-04-17 3:40 ` Ilya Zakharevich
2016-04-09 16:37 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160417034705.GA13745@math.berkeley.edu \
--to=ilya@math.berkeley.edu \
--cc=23251@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=jjezina@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.