Re: input-decode-map: Silently ignore certain sequences

[Yuri Khan]

On Sun, Dec 16, 2018 at 7:20 PM Anders Lindgren <address@hidden> 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