From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: input-decode-map: Silently ignore certain sequences Date: Sun, 16 Dec 2018 13:20:28 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003b261c057d22b110" X-Trace: blaine.gmane.org 1544962726 20485 195.159.176.226 (16 Dec 2018 12:18:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Dec 2018 12:18:46 +0000 (UTC) Cc: emacs-devel To: yurivkhan@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 16 13:18:41 2018 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 1gYVNZ-0005Ei-9V for ged-emacs-devel@m.gmane.org; Sun, 16 Dec 2018 13:18:41 +0100 Original-Received: from localhost ([::1]:42145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYVPf-000070-LI for ged-emacs-devel@m.gmane.org; Sun, 16 Dec 2018 07:20:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYVPZ-00006b-5h for emacs-devel@gnu.org; Sun, 16 Dec 2018 07:20:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gYVPX-0007FV-3H for emacs-devel@gnu.org; Sun, 16 Dec 2018 07:20:45 -0500 Original-Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:36567) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gYVPW-0007Eh-JW for emacs-devel@gnu.org; Sun, 16 Dec 2018 07:20:43 -0500 Original-Received: by mail-lf1-x133.google.com with SMTP id a16so7459816lfg.3 for ; Sun, 16 Dec 2018 04:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ScoU8SAyXi2f7fbJJXo+Ipwqr7HPjuT1aOSBN9BxcOo=; b=ueKVn+C1oxqd+N2w2dhSORqwncVrkP7bjSc7UfQtqTcbBBtjp4ZDive4iN5YYm5Are wan5KHZFdaXp7/CPcCgdxaYoTOiTJiaOxzyMeRpO3EbmPxKaOOCE066GxtefkGIoef0y cZAiPmdVEyfTvMH5SO2BZFLCmhY+5LvnXWGWwGqsFeHmB8Z0U6arcviTJqS2tcZG1mP8 jHvxArvk1nLVMfNuACYtz0jTX5mFtNXLDPDZlFcstnOd1WUX2Wu+oZxtnstgc1zYMDbT eZuZQSdT3IJ4/r+N0/OEXLjjhlFDFwPYrCUfycCupioIHC4BKr8YGQZwIb9rDEXkJmOy 9e3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ScoU8SAyXi2f7fbJJXo+Ipwqr7HPjuT1aOSBN9BxcOo=; b=mKMG9iVsv1v4P93hB4lSfb9V8OFn0w3XL1ZsMuvnfK3lzh7jJyi7TJYUaDFQJ5qJ9v jgYw2igwkgvqm/Qiry9TdFtVIZqoi0LgjMWf2OHFE50rlQAUnvsY0hF0alh8YY2rwjNx WX2yNnu6AlRzAqgwtZH60nFQ1EZy3IuSE8WbSS+HGw1Z5pbdSVADWN2ymQ0LauM6FTz+ F17376DfLDPtGxj4l83Glao4H4wNSP3G/G9Kb4JQABCioPwkIxZjLQ/nH7O4uYRg70Pf Ysay3wXK0IEv7IuMydmIxgHZY9l4+VZawHYRgyuvjZJW5LHXjD3df1x17IfsYKHXgFO0 NmTA== X-Gm-Message-State: AA+aEWagj2XjR6rHMYTNN57ioh6yI6x6u7hkanag7gzDEcCd8Z8OS1ng bwGXX2BxhaAAZAYyTp+H7mMgV3GHEOJOyo0EID0= X-Google-Smtp-Source: AFSGD/WoOfL57rkfQUr6LfejEf7uAGaWZNp8retsK8Ese1MrJs/uNg/nxCWzv/a4k96yRbY1kz1ACHzHgmM3eIWDPZM= X-Received: by 2002:a19:8c1b:: with SMTP id o27mr5101889lfd.90.1544962839355; Sun, 16 Dec 2018 04:20:39 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::133 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:231849 Archived-At: --0000000000003b261c057d22b110 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! I found myself in a similar situation with an experimental package I've been working on, mode-line-keyboard [1]. In this package I need to ignore event, like key down, all together. My solution is to bind functions to input-event-map that calls `read-key` recursively, as I found that returning nil breaks a key sequence. I just realised that I haven't tried [] so I might need to revisit this. Anyway, I found the key map handing in Emacs really confusing. To help me out I put together a companion package, keymap-logger [2], that logs most things that is passed to and transformed by the various keymaps like input-key-map and key-translation-map. Maybe it can help you to gain some insight of what is going on. -- Anders [1]: https://github.com/Lindydancer/mode-line-keyboard [2]: https://github.com/Lindydancer/keymap-logger On Thu, Dec 13, 2018 at 8:11 PM Yuri Khan wrote: > Hello emacs-devel, > > I am trying to implement an input-decode-map for the Kitty terminal > emulator [1], specifically, for its full keyboard mode extension [2]. > This would solve one of the two major deficiences of Emacs in a > terminal emulator, namely, the inability to distinguish many > keystrokes. (The other one, lack of full color, is also solved by > Kitty, with the right terminfo modifications.) > > In the full keyboard mode, the terminal passes to the application > *all* keystrokes, in a very machine-friendly format. That is, for > events other than character input (i.e. normal characters, shifted > characters, Enter, Tab, and Backspace), it sends an escape sequence > containing a key code, a modifier bit mask, and whether the key was > pressed, released, or autorepeated. > > This is a bit too much for an application such as Emacs; in > particular, it is not interested in key release events, or events > regarding modifier keys. > > To give an example, Kitty sends the sequence =E2=80=9CESC _ K p A B b ESC= \=E2=80=9D > for the event =E2=80=9CLeft Alt pressed=E2=80=9D. > > I can get Emacs to ignore this sequence by doing this: > > (define-key input-decode-map "\e_KpABb\e\\" []) > > However, input decoding is accompanied by echoing the current key > sequence prefix, and when the sequence is complete, Emacs clears the > echo area. With key release events, this happens *a lot*. This is > suboptimal because sometimes Emacs asks a question in the echo area > and waits for a key. > > For example, when the user presses C-x C-c, (kill-emacs) may ask > whether to save files. Then the release event for C-c comes, and the > echo area is cleared. > > Is there a way to turn off echoing for prefixes of sequences matched > against input-decode-map, so that echoing still works for =E2=80=9Cmanual= =E2=80=9D key > sequences but not sequences sent by the terminal? > > If not, would such an option be considered useful? > > > [1]: https://sw.kovidgoyal.net/kitty/ > [2]: > https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handlin= g > > --0000000000003b261c057d22b110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

I= found myself in a similar situation with an experimental package I've = been working on, mode-line-keyboard [1]. In this package I need to ignore e= vent, like key down, all together. My solution is to bind functions to inpu= t-event-map that calls `read-key` recursively, as I found that returning ni= l breaks a key sequence. I just realised that I haven't tried [] so I m= ight need to revisit this.

Anyway, I found the key= map handing in Emacs really confusing. To help me out I put together a com= panion package, keymap-logger [2], that logs most things that is passed to = and transformed by the various keymaps like input-key-map and key-translati= on-map. Maybe it can help you to gain some insight of what is going on.

=C2=A0 =C2=A0 -- Anders




On Thu, Dec 13, 2018 at 8= :11 PM Yuri Khan <yurivkhan@gmail= .com> wrote:
Hello emacs-devel,

I am trying to implement an input-decode-map for the Kitty terminal
emulator [1], specifically, for its full keyboard mode extension [2].
This would solve one of the two major deficiences of Emacs in a
terminal emulator, namely, the inability to distinguish many
keystrokes. (The other one, lack of full color, is also solved by
Kitty, with the right terminfo modifications.)

In the full keyboard mode, the terminal passes to the application
*all* keystrokes, in a very machine-friendly format. That is, for
events other than character input (i.e. normal characters, shifted
characters, Enter, Tab, and Backspace), it sends an escape sequence
containing a key code, a modifier bit mask, and whether the key was
pressed, released, or autorepeated.

This is a bit too much for an application such as Emacs; in
particular, it is not interested in key release events, or events
regarding modifier keys.

To give an example, Kitty sends the sequence =E2=80=9CESC _ K p A B b ESC \= =E2=80=9D
for the event =E2=80=9CLeft Alt pressed=E2=80=9D.

I can get Emacs to ignore this sequence by doing this:

=C2=A0 =C2=A0 (define-key input-decode-map "\e_KpABb\e\\" [])

However, input decoding is accompanied by echoing the current key
sequence prefix, and when the sequence is complete, Emacs clears the
echo area. With key release events, this happens *a lot*. This is
suboptimal because sometimes Emacs asks a question in the echo area
and waits for a key.

For example, when the user presses C-x C-c, (kill-emacs) may ask
whether to save files. Then the release event for C-c comes, and the
echo area is cleared.

Is there a way to turn off echoing for prefixes of sequences matched
against input-decode-map, so that echoing still works for =E2=80=9Cmanual= =E2=80=9D key
sequences but not sequences sent by the terminal?

If not, would such an option be considered useful?


[1]: https://sw.kovidgoyal.net/kitty/
[2]: https://sw.kovidgoyal= .net/kitty/protocol-extensions.html#keyboard-handling

--0000000000003b261c057d22b110--