[Input] Fix Unicode character input with Alt / Ctrl modifiers.

[bruvzg]

• Add extra unhandled_unicode_input input processing step to process Unicode character input with Alt / Ctrl modifiers, after processing of shortcuts.

Alternative to #52452

This will prevent both shortcut and input to trigger simultaneously, by adding an extra processing step (shortcuts are handled in the unhandled_key_input). e.g., By default Alt + F won't input ƒ in the code editor (since it is a shortcut for Fold Line), but will work in any other Line/TextEdit.

Should not break any other input, since it's not changing existing code, new processing is done only if event is not handed.

Fixes #6851, fixes #54303, fixes #56319.

[bruvzg]

In addition to this, it might be a good idea to change Alt + F (Fold Line) and Alt + Ctrl + F (Go to Function) default shortcuts to something else. Alt + Letter and AltGr + Letter (which is equivalent to Alt + Ctrl on Windows) input combinations are common, and probably should be avoided for the text editor.

And maybe also replace Alt + Shift + S (Save All) and Alt + Shift + Q (Quit to Project List), which can be used for input as well.

[reduz]

Do you think we could do this in a way where we still have one function, even if it requires a boolean or extra field in InputEvent? I am afraid that having an extra function like this may be very confusing when looking at the API.

[bruvzg]

Do you think we could do this in a way where we still have one function,

Like calling unhandled_key_input twice (with an extra pass_nr argument) instead of adding new unhandled_unicode_input? Yes, this might be more clear variant.

With the single unhandled_key_input pass, I do not think so. The issue is in call order:

• CodeEdit receives unhandled_key_input first, we can't handle input here, since shortcuts are not processed (and there's no clear way to determine if there's any conflicting shortcuts that will trigger).
• Menu receives unhandled_key_input and processes shortcuts.
• Only after this, we can process remaining input, so another pass is necessary.

There's nothing special about InputEvent with the special character and one without it, just different Unicode values, so the extra field won't help. The only difference is there's a shortcut which is conflicting or not.

[reduz]

As discussed on IRC. I think if we want shortcuts to happen before, it seems like a cleaner solution to have a shortcut_input() call and then do unhandled_key_input. This would also help clean up that the later can receive shortcuts, which is pretty hacky.

[bruvzg]

Updated as discussed. Now, unhandled input is processed in the following order:

• shortcut_input (Key or Shortcut events, handled shortcuts)
• unhandled_input (all events)
• unhandled_key_input (Key events, handled Unicode input with modifiers)

[reduz]

@bruvzg Its a bit difficult to see in the PR to see if all the cases where the callback was replaced were only (or mostly) intended to process shortcuts, it does look OK it to me but just confirming that was your intention.

[bruvzg]

Its a bit difficult to see in the PR to see if all the cases where the callback was replaced were only (or mostly) intended to process shortcuts, it does look OK it to me but just confirming that was your intention.

All unhandled_input and unhandled_key_input used for the shortcuts or mostly shortcuts are replaced withshortcut_input.

[reduz]

@bruvzg Fantastic work!! Love how much cleaner everything is now.

[akien-mga]

Thanks!