Josh Goebel

> Are the triggers really not in the right context that they could emit output? The condition functions are all evaluated BEFORE the keymap to be used for output is...

I'm also considering more of a high-level callback: ```py def do_keymap_enter_and_exits(keymaps): # check global state and if certain keymaps are not # present we should fire their "exit" handlers add_callback("after_decide_keymap",...

> But there are multiple places where the tab nav shortcut ... different output combos depending on context. Right, so you could just wrap all those places. I was pointing...

I think I'm coming back around on modality as an explicit concept... so you could have a modal keymap with different exit behaviors rather than the current "one and done"...

Yes please, making this a pointer would be super helpful. Seconded.

Run with -V9 and look really carefully when all the schemes are loaded to make sure you aren't missing a python library you need to install.... if you are msising...

And does it matter whether this matches the "already held, part of combo" behavior... ie, this test: ```py async def test_sticky_combo_with_sticky_inkey_in_output_combo(): keymap("Firefox",{ K("C-j"): [bind, K("Alt-C-TAB")], }) boot_config() press(Key.LEFT_CTRL) await asyncio.sleep(2)...

I lean slightly towards the re-suspend behavior... because otherwise (in the case of one-of combos, which most combos are) the result is a LOT of wasted/false keypresses of the original...

> I'm not sure the current defaults are "appropriate". For example I'm not sure input should be silently discarded... perhaps the default is for a miss is to send the...

Are there other desirable behaviors one might want here that couldn't be modeled on the two hit/miss callbacks?