Support for setting extensible keystrokes (e.g. enter) through the keystroke handler

[Reinmar]

Currently handlers for (Shift+)Enter and (Shift+)Tab are defined directly on the editing view, so there's no way to redefine what keystrokes cause them. Actually, there is but it requires registering a handler (using editor.keystrokes.add()) which fires a proper keydown event on the editing view.

It's also unclear, which keystrokes have to be defined on the editing view and which through a keystroke handler.

So far, that would be easy to solve, however, as we agreed after a very long discussion, the list feature will listen on enter event on the editing view in order to tweak the default behaviour. Some features will be extending the enter command itself, but when the semantics changes, then we should handle it on the view.

However, this means that if we configure keystroke handler to execute enter command on Enter, the list feature will still need to modify this behaviour on the editing view level. So when someone decides to say that now Foo should behave like Enter and sets that through a keystroke handler, only the behaviour of the enter command will be used. The behaviour of the list feature will be ignored.

The only reasonable option that I see is:

1. Removing the EnterObserver from the editing view.
2. Use keystroke handler to set that on (???+)Enter (1) the enter command is executed.
3. The list feature will need to alter the enter command's behaviour (can you think of any cons of this, @scofalik?).

Ad (1) Currently we'd like to handle enter with all modifiers, so either we'll add keystrokes for all combinations (sad) or we'll add a notation for optional modifiers. Like [Ctrl]+[Alt]+[Shift]+Enter.

Now, you'll always be able to redefine which keystrokes trigger enter command and we won't need some magic in the keystroke handler (which seems to be the only alternative if we don't want to change 2.).

Finally, I feel that even keystrokes like Backspace should be defined using the keystroke handler. What I wrote above is very similar to how it works in CKE4 with this difference, that in CKE4 some features like list or tables were listening directly on the editable's events (our editing view):

• https://github.com/ckeditor/ckeditor-dev/blob/3876e730d418107f791eef517178b0048a2c9383/core/editable.js#L977
• https://github.com/ckeditor/ckeditor-dev/blob/3876e730d418107f791eef517178b0048a2c9383/core/editable.js#L1156
• https://github.com/ckeditor/ckeditor-dev/blob/3876e730d418107f791eef517178b0048a2c9383/plugins/list/plugin.js#L844

I think that we must avoid this. It's never been a big problem (although I recall that widgets had to deal with this), but just for the sake of being able to answer people's question – how should I handle xyz (that's how @scofalik provoked this ticket :D).

[Reinmar]

I've thought about an interesting conflict if we'll start to explicitly (through the keystroke handler) listen to too many keystrokes – we won't be able to seamlessly switch to the beforeinput event. Read more: #339.

[Reinmar]

This ticket needs to be reviewed in light of #340. However, I think that it's in line with that proposal.

[Reinmar]

See #340 (comment) – I mentioned a problem with optional modifiers that we can encounter later in the future.

[Reinmar]

Another reason for making keystroke handler a simple event dispatcher: #472 (comment).

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).