From: Yuri Khan <yurivkhan@gmail.com>
To: andlind@gmail.com
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: input-decode-map: Silently ignore certain sequences
Date: Sun, 16 Dec 2018 21:35:00 +0700 [thread overview]
Message-ID: <CAP_d_8VNQhNiQ5kcOLiYvdiHkAnj=J0vj549fpguaKbYo9FxBQ@mail.gmail.com> (raw)
In-Reply-To: <CABr8ebaKsyDGh2X9hpY59v7c=BRRLrtBDxotjQ0Q-YyMPFmRfA@mail.gmail.com>
On Sun, Dec 16, 2018 at 7:20 PM Anders Lindgren <andlind@gmail.com> wrote:
> 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.
I did not consider calling ‘read-key’ from a function bound in
‘input-event-map’. Instinctively, I’d try to avoid side effects and
especially recursion in any of the key translation maps. Too
complicated for me :)
I had tried binding nil and #'ignore; neither worked. So I dived into
reading C code to get some superficial understanding how
‘input-event-map’ operates.
The short gist of it is that:
* A nil binding is treated, as usual in keymaps, equivalently to no
binding at all. That is, the sequence is not remapped.
* A function gets called with one argument (optional text of the
prompt) and its return value is used as if it was the binding (except
that if it’s again a function, it will not be called).
* A string is treated the same way as a vector of characters.
* The ultimate resolution of input-decode-map is a vector of keys,
which are stuffed in place of the original subsequence and the
resulting sequence is re-interpreted.
> 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.
That is interesting, although not directly leading to a solution to my case.
I wanted to know when and why the echo area gets cleared, and I found
out that it happens when any prefix key is pressed and it’s pretty
much a feature. So my current idea of a solution is to save and
restore the echo area at appropriate times. I drafted a patch to that
effect:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33749#17
next prev parent reply other threads:[~2018-12-16 14:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 19:10 input-decode-map: Silently ignore certain sequences Yuri Khan
2018-12-13 22:43 ` Stefan Monnier
2018-12-15 8:18 ` Yuri Khan
2018-12-16 12:20 ` Anders Lindgren
2018-12-16 14:35 ` Yuri Khan [this message]
2018-12-17 3:24 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAP_d_8VNQhNiQ5kcOLiYvdiHkAnj=J0vj549fpguaKbYo9FxBQ@mail.gmail.com' \
--to=yurivkhan@gmail.com \
--cc=andlind@gmail.com \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).