Allow consumers to specify a set of key sequences to not be handled by the terminal and bubble up instead

[Tyriar]

See microsoft/vscode#7269 for context.

Some users want F1 to not be consumed by the temrinal and instead be bubbled up to be handled by the application (to toggle the command palette). I can see this being useful for other keys as well depending on specific the use case.

[parisk]

Sounds like a sane proposal. We could create a more declarative key binding API and export all current key handling to add-on like objects.

[parisk]

This way you will be able to choose which of them to include in your "xterm bundle".

[TDaglis]

As an alternative (or as a temporary) solution, the application could catch the key sequences on capturing instead of bubbling.

[protamail]

This is already pretty easy to achieve with very small modifications. The existing "keydown" event should be emitted with additional parameter "result". And its emit call should be moved up before if (result.cancel) and if (!result.key) blocks. Then the "keydown" handler could inspect event.keyCode and result.key and e.g. set result.key = "" to ignore key and let it bubble, or also set result.cancel = true to prevent bubble as well. It could even override result.key with a different escape sequence if required. The websocket sending code would still reside in the catch-all "data" handler...

[Tyriar]

This duplicates #118