Consider reverting #37940

[timholy]

#37940 (comment)

[jonas-schulze]

Would it be possible to instead move keypress further up, such that the menu is able to intercept even standard inputs? This might however introduce other failures depending on how third-party menus handle standard inputs. 😕

[timholy]

I don't see an easy way, because if a package has already handled ' ' you wouldn't want AbstractMenu doing something else with it. keypress only returns a shouldbreak::Bool, and I think it would need a alreadyhandled::Bool to work properly. Unless you see a way?

I think this can come back (I totally get why you'd want this, it's a great feature to have), but we'd need to introduce some kind of key-configuration. It's unclear to me whether that should be a global or an option to the menu constructor. Overall, giving TerminalMenus a decent interface while also not breaking anything is a hard problem, I had to go to considerable heroics in #35915.

[jonas-schulze]

keypress only returns a shouldbreak::Bool, and I think it would need a alreadyhandled::Bool to work properly.

You are right, my suggestion wouldn't work. I made a draft for opt-in vim bindings. TreeMenu could then opt-in to only support j and k but not Space by defining:

# check for julia version here...
accepts_jk(::TreeMenu) = true

If you like, I can prepare a PR to FoldingTrees as well.

[jonas-schulze]

FYI: The keybindings introduced in #41576 also clash with vim bindings.

[timholy]

#41576 is completely optional so won't affect any existing users, and doesn't specify any particular keys. It merely adds the facility to customize keys. You could probably mimic that approach and add a navigation_keys keyword argument or something.

I'll go ahead and revert #37940, thanks for your willingness and the discussion! Yes, I'd be happy to receive a PR for FoldingTrees once the replacement for #37940 merges.