Currently, input-mapper expresses keymaps as nested hashmaps.
This has a few very key limitations:
It doesn't allow us to match on arbitrary keys by some property (as evidenced by the fact that we already have a special cased fallback "any_printable" case)
It means that for numbers and anything like that, we need to basically store all keymaps 10x
the api is kinda eh
Optimally, every keymap would just consist of a function that takes an input, does whatever to it, and returns a new submap (-> another function) or the leaf value.
This would simplify a lot of the more complex logic here, and should be possible to express relatively cleanly through a parser-combinator style API. However, it's not yet clear how we'd do descriptions with that...
This is a followup to the implementation of #86 done in #100
Currently, input-mapper expresses keymaps as nested hashmaps. This has a few very key limitations:
Optimally, every keymap would just consist of a function that takes an input, does whatever to it, and returns a new submap (-> another function) or the leaf value. This would simplify a lot of the more complex logic here, and should be possible to express relatively cleanly through a parser-combinator style API. However, it's not yet clear how we'd do descriptions with that...
This is a followup to the implementation of #86 done in #100