From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: Ignoring keyboard modes for key chords Date: Sun, 16 Oct 2016 14:52:02 +0600 Message-ID: References: <8360os22j6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1476607976 4556 195.159.176.226 (16 Oct 2016 08:52:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Oct 2016 08:52:56 +0000 (UTC) Cc: Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 16 10:52:52 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bvhBI-0006Xh-E8 for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2016 10:52:32 +0200 Original-Received: from localhost ([::1]:55486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvhBK-0004Lr-EZ for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2016 04:52:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvhBE-0004Lm-3P for emacs-devel@gnu.org; Sun, 16 Oct 2016 04:52:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bvhBD-0004Xz-5l for emacs-devel@gnu.org; Sun, 16 Oct 2016 04:52:28 -0400 Original-Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]:34348) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bvhBA-0004UM-PV; Sun, 16 Oct 2016 04:52:24 -0400 Original-Received: by mail-lf0-x244.google.com with SMTP id x23so14993916lfi.1; Sun, 16 Oct 2016 01:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Z/jC5hbtL15ZvEZCfGe0GYBR14dQ7aPQZvUPxrxtkjo=; b=hEaWVVM7UtaLzIcWbxe5XfctvsE/NZQomOCnbbDBO2VvRL6AUsjHZjUCalObrx1Z1/ E6nut38l8/vRUfQvvyZbi8cDeqx69RZnc2eKmlwqO5xQyQ54T71vr0+VxOE8GSn/caKG 5cfFgTH5jZ0z26tUZHaiqPjxBen81NaAr+iHm2cX9tr6VPZDtBtGO2Y3vUEmMGm03Xd+ ez84x/oViv4wYGTwwViwIL1cN61wAuOOHp1QTYf4cwIarTjO5HSQoCHW9z3SFcstLoBS zyPZXgeRmbeecEHT2YVAqmazh1kH3+eD0b0YEYUpOXVCSTxji0kA8MTLtLCx2zAOb+3z ta/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Z/jC5hbtL15ZvEZCfGe0GYBR14dQ7aPQZvUPxrxtkjo=; b=DO0ptJN531V8OUs4bsUDpvm0WN42U5lS5E0co9M/BfeLYA78BMRT5+oZ90WZbCwpBX 1InYtBrf1eXW2Pk7VYTfb9xHtgZrsLlAWaEdxL2yUSFjvE6gffiUanMnwRkVAe73/rnv ItgoWGJE9nLxZsslScc0L6YIDDmu6xuUuUGmVWK7e9WiVlTTYbCk/iJJpJQsfbB0Vz2O eeeEINvgk64DrGigoTN3AWEDMfjRysdSrFvQQ79sv2zc7cxqTapwAdXR0+obWveYyRAJ s4gwckLxynKrv0iZcxNuZFMXjFC877KxBlb5KWHLL9Txx2GkhwEebFw4YDPDDEev7xop ORlA== X-Gm-Message-State: AA6/9RlogHUGnQlPHWCLooAwRjWlbqkbP25ZdCTaBRgj6conmrKoyrej61F+KdbsRMK4LiF0dBcLznkZdDsJXw== X-Received: by 10.25.195.209 with SMTP id t200mr8799188lff.172.1476607942874; Sun, 16 Oct 2016 01:52:22 -0700 (PDT) Original-Received: by 10.114.80.163 with HTTP; Sun, 16 Oct 2016 01:52:02 -0700 (PDT) In-Reply-To: <8360os22j6.fsf@gnu.org> X-Google-Sender-Auth: nsuL7IMpUatF3BmbP2d-2BKgAyI X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::244 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208323 Archived-At: On Sun, Oct 16, 2016 at 2:09 PM, Eli Zaretskii wrote: > Why is this expected to be solved by Emacs, and not by some option on > the level of the OS keyboard driver? I'm guessing that doing this in > Emacs would require messing with low-level keyboard interfaces, > something Emacs is better off without, IMO. Because none of the other Gtk+ applications exhibit the problem? > Moreover, the expected behavior, if implemented in Emacs, will have at > least 2 disadvantages: > > . it will disallow keystrokes with modifiers that use non-ASCII > characters, such as C-=D1=8B Does anybody actually want or use this? > . it will not solve the case of multi-key sequences, such as > "C-x =D1=8B" It would be nice to solve these, too. And single-key non-modified keys such as those in dired and ibuffer. > . it may not be possible at all on a TTY, or at least I expect the > problems there to be more prominent, since on many terminals M-x > is sent to Emacs as "ESC x", which are 2 keys Yes. The shoehorning of keystrokes into a character stream model is a fundamental limitation of the current TTY protocol. It is most unfortunate but it should not discourage us from solving a problem on toolkit where it can be solved. > So it could only be a partial solution at best. > > I would expect solutions for this to exist already for GNU/Linux and > other free OSes, isn't that so? If such solutions exist, why not use > them instead? Here is the output of xev(1) when pressing C-s with US and Russian layouts installed, Russian layout active: KeyPress event, serial 33, synthetic NO, window 0x2a00001, root 0x4b9, subw 0x0, time 292017728, (-1382,-332), root:(449,621), state 0x2004, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (13) "" XmbLookupString gives 1 bytes: (13) "" XFilterEvent returns: False No traces of =D1=8B here. However, a simple Gtk+3 program which listens for keyboard events and dumps them to terminal shows me this: {'group': 1, 'string': '=D1=8B', 'length': 2, 'time': 293166884, 'type': , 'sent_event': 0, 'keyval': '0x6d9', 'is_modifier': 0, 'hardware_keycode': 39, 'state': '0x2004', 'window': } According to , keyval 0x6d9 is called GDK_KEY_Cyrillic_yeru. And looking at the hardware_keycode is suboptimal because that would presumably break Dvorak, Colemak and AZERTY. However, Gtk also has a notion of accelerators, which is the mechanism most Gtk programs use to bind shortcut keys to UI commands. I coded a test program which creates a window and a signal, adds Ctrl+s as an accelerator on that window that invokes that signal, and handles the signal by printing =E2=80=9CHello=E2=80=9D on the standard output. The hand= ler gets invoked when I press Ctrl+s no matter which layout is active. So, the root cause of the issue is that Emacs is not integrated with Gtk=E2=80=99s accelerator system. And it=E2=80=99s not clear if it could, w= hile staying cross-toolkit. I also wondered whether the issue is Gtk-specific. It=E2=80=99s not; emacs24-lucid exhibits the same behavior.