lapce
lapce copied to clipboard
lapce
Dead keys not being handled
Lapce Version
0.2.0
System information
Arch linux
Describe the bug
The key related to key code 48 is not being handled by text editor. It is also not being handled by builtin terminal.
The number 48 was extracted using the command "xinput test":
key press 48
key release 48
Additional information
In the keybindings settings dialog, when I press 48, I get the name "Dead" for the key:
If I assign the key 48 to the command palette command, when I press the key 48, the command palette does open.
Remarks: On my keyboard, which is english qwerty layout, key code 48 refers to double quote / single quote.
Upon further investigation I understand now that the problem is lack of dead keys handling. If a dead key is pressed, nothing happens. Nothing specific about "key code 48" but it being a dead key on my keymap.
Workaround: to change the keymap to a layout without dead keys.
Related issue: https://github.com/lapce/lapce/issues/530
More information, this seems to be related to the feature of dead key preview:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3815
I have the same issue on Arch Linux with an US keyboard set to US intl.
It does seem like the editor is simply not handling dead keys at all, they don't even enter the characters on the key.
here with Lapce v0.2.1 over 5.19.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24) x86_64 GNU/Linux hitting same issue with key ` with spanish layout
Same here. Happening with single and double quotes, and tilde and backtick. I'm currently using a 66% keyboard configured as En(intl)+deadkeys .
Love the idea of using Lapce as my main code editor, but it's plainly useless without the capability of typing a single or double quote.
I'm experiencing the same issue here, which is unfortunate as I really liked the overall experience of Lapce... I hope Druid UI fixes this in linebender/druid/issues/1040. Subscribing here to get notified.
Is Druid still being used in the nightly builds, or is some kind of changed handling in Floem victim to the same problem as the old codebase?
Latest lapce release doesn't use Druid anymore, it's Floem and keyboard events are provided by Winit.
I was going to post an edit, but that was a surprisingly fast response.
A friend of mine that's much more knowledgeable about key handling than me is looking through Winit now and they're drawing the conclusion that Winit is breaking stuff here by calling ToUnicode a second time on dead keys. I'll try and see if this can be sorted on that end
Uh, false alarm there, the code I was looking at did call ToUnicodeEx, but turned out to be using it to inspect keyboard layouts rather than processing actual input. I haven't managed to find where the actual input processing is messed up (it appears to call TranslateMessage in the main loop, which should just work unless something else is calling ToUnicode somewhere)
ok, after installing lapce myself (i know, lazy), i observed the following:
- contrary to my interpretation of reports, actual accented letters entered via the US-Intl layout dead keys on windows work fine
- dead key + space enters ~~nothing~~space
- dead key + other dead key enters nothing
- dead key + letter with no corresponding accent enters only the letter.
All expected WM_CHAR messages do get generated (presumably by winit's call to TranslateMessage)
The above image is the event sequence from typing '''a'b, which results in only the text áb being typed in to the file [each on the respective letter keydown], not ''á'b as expected.
The WM_CHAR messages for the ' character do have the lparam flag 02000000 set, which may be an undocumented [other flags in this value are documented at https://learn.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input#keystroke-message-flags, 0x0200 is missing from this table] flag intended for this scenario, but the second one in the '' sequence and the one generated by '<space> does not have this set, but are still ignored.
I think I have finally figured out what is going on.
The keypress function https://github.com/lapce/lapce/blob/592cbc7b6f672d2ee56447668a25a271d05877bb/lapce-app/src/keypress.rs#L181 is discarding the text from the event, leaving its caller (key_down https://github.com/lapce/lapce/blob/592cbc7b6f672d2ee56447668a25a271d05877bb/lapce-app/src/keypress.rs#L201) to infer characters from only the key being a Key::Character or NamedKey::Space (I am still unsure why this means it discards doubled dead keys or why accented characters work, but this is the only thing that can explain a space character being entered when a dead key is followed with the spacebar) The entire key_down function will have to be rewritten.
It is worth mentioning that (assuming that winit supports it correctly) KeyUp events can also have text, in the case of the event corresponding to Alt being released after entering an alt+numpad code. Other event handlers further up the chain may need to be reworked to accommodate this, if support for windows native alt+numpad codes is desired.
I have a basic fix that seems to work, replacing the contents of the if mods.is_empty() block with
if let EventRef::Keyboard(keyevent) = event {
if let Some(text) = &keyevent.key.text {
focus.receive_char(text.as_str());
self.count.set(None);
return true;
}
}
[and into-ing the event at the top of the function, since otherwise it can't be used both here and in the call to keypress], but I only have the ability to test it on Windows, and it also seems like a bit of a messy solution since fundamentally the problem is that the KeyPress type does not retain the text from the winit/floem keydown event, and I am not sure whether it should or not or even why this KeyPress type exists at all.
With Lapce v0.3.1 (Flatpak) dead keys seem to finally be working on my machine, both with and without IME running. When running IME, the phantom text is now also rendered.
