-
Notifications
You must be signed in to change notification settings - Fork 909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KeyEvent::text should be None when Ctrl is pressed? #3038
Comments
Also related:
This is a control code, not text, so should it also be |
Sorry, turns out I did open a discussion on this topic already. Doesn't show up when searching issues. Note: I've only really been testing on Wayland, but given what Winit is I would expect all platforms to behave similarly (which may mean mapping some codes). |
XKB allows usage of various other keys as second/third/fifth layer selectors. When I try this, these are reported as e.g. There may, however, be utility in reporting control codes via |
Yeah, xkb has a
If OS tells us that it's not like that, I'm not sure that we should, but I know that some apps which can't handle regular control bindings (the
I think we explicitly decided to handle Line 1480 in a3cba83
|
My main concerns are documentation and platform consistency. To be honest, this goes way beyond Winit, e.g. KDE (Qt) apps will block all text entry while Ctrl is held but do not do the same for Alt or Super (which input text if no shortcut is matched). Also portability: Super is used more for shortcuts on MacOS than on other platforms. I'm tempted to set Control codes are a separate matter. My current perspective is that e.g. Enter is easier to deal with as a Event::Key(event, false) if event.state == ElementState::Pressed => {
if let Some(text) = event.text {
// This is not a control code and no modifier (besides Shift) is pressed, enforced by toolkit
self.received_text(cx, data, &text)
} else {
// handle event.logical_key ...
}
} This of course does not apply universally so Winit may not want to do the same regarding control codes. Maybe just adding
So |
Hm, maybe making Though, I'd agree that there's no need to have a text with control chars attached to And from what I can see the w3c stuff doesn't emit any text for the |
If text is none, then we need an alternative in Neovide, since it will no longer be possible to map special characters. We don't have access to the keymap so we can't know what character a specific combination produces. In Vim you always map by the resulting character, not the modifiers + base key. Actually, I think it should produce At the very minimum the Vim default |
@fredizzimo I think you should be matching |
I guess so, we already use the logical key as a backup if the text is empty. That is actually the case for some, but not all ctrl combinations on Windows for some reason, see #2898 But if we use just the logical key then we lose the ability to map dead key combinations, which is currently possible, at least in combination with other modifiers, like alt on Windows. So, it would be a regression for Neovide. But if logical key also included the resolved character(s), then everything should be fine. We also still need to deal with the text field for raw typing, those keys are sent exactly the same way to Neovim as the ones that are combined with modifiers. So, if this change is made, for us I think that it would mean to send, the text if it's set, otherwise send |
I assumed by this that you match the key used to start a dead-key sequence, but from your last reply it sounds more like you want to match the resulting symbol, e.g.
You're talking just text entry here IIUC — so why care about shift+space? Why even care about cases where |
In (neo)vim, there's not really any concept of shortcuts, we are talking about mappings. To borrow from the documentation:
In those terms it's entirely possible to map There's also another inconsistency, if we do it that way. The default mapping
The comment was a bit off-topic to the discussion, but we do need to handle that in Neovide. In (neo)vim, there's no difference between text entry and mappings, everything it sees is just a sequence of characters, you could even do Mapping shift+space, shift+enter, shift+F1 and so on are very useful mappings, since the keys are easy to hit. But we don't want to send
Using just |
The issue was purely about the |
|
@fredizzimo besides all of that, can't you communicate with neovim by the means of the kitty's keyboard protocol? |
I see, I think the issue is that we want shift levels exposed somehow, but I think it's more for a future work with keyboard stuff. I also needed that sort of thing, but resorted to use |
I don’t think that a neovim gui application can use the Kitty protocol. And we have Apart from a few bugs that I have reported here in the issue tracker, we do have everything we need from winit for the keyboard support right now. But if text, is removed in combination with modifiers, we loose proper deadkey support. I can see three alternatives.
|
Hm, this issue was mostly about non-printable text from what I can say and whether it should be reported. Honestly, I'm not even sure what clients really want from text, and compare it with text_with_all_modifiers, I know that |
At this point my thoughts are:
There is one reason to expose Possibly |
TLDR: should Winit force
KeyEvent::text
toNone
when:such that
text
is always printable? (We retaintext_with_all_modifiers
for use by terminals.)From the doc:
If, for example, I press Ctrl + U I get (Wayland with winit v0.29.1-beta):
My understanding is that the purpose of
text
is for text entry in an edit field. If someone presses Ctrl + U in an editor, this may or may not match some shortcut but should never enter "u". Therefore, Winit should always passtext: None
when theCtrl
modifier is held?Should this behaviour be extended to other modifiers?
The text was updated successfully, but these errors were encountered: