Unable to input Unicode alt-codes #1116

Closed
opened 4 months ago by cyanreg · 11 comments
  • foot version: 1.12.1 -pgo +ime -graphemes -assertions
  • sway
  • no IME

The issue is that inputting alt-codes via Ctrl+shift+u doesn't work.
I've already reassigned the conflicting show-urls-launch shortcut and inputted echo -en "\033[?737769h" to enable IME escape codes, yet still the code flashes for a moment with nothing actually printed.
The same method works in gnome-terminal and any existing GUI application I use.

I use no IME like ibus or fcitx5 because I don't need them, I've setup my keyboard to macro out ctrl+shift+u codes for international characters.

- foot version: 1.12.1 -pgo +ime -graphemes -assertions - sway - no IME The issue is that inputting alt-codes via Ctrl+shift+u doesn't work. I've already reassigned the conflicting show-urls-launch shortcut and inputted `echo -en "\033[?737769h"` to enable IME escape codes, yet still the code flashes for a moment with nothing actually printed. The same method works in gnome-terminal and any existing GUI application I use. I use no IME like ibus or fcitx5 because I don't need them, I've setup my keyboard to macro out ctrl+shift+u codes for international characters.
cyanreg changed title from Unable to input alt-codes to Unable to input Unicode alt-codes 4 months ago
Owner

I use no IME like ibus or fcitx5 because I don't need them, I've setup my keyboard to macro out ctrl+shift+u codes for international characters.

How exactly does that work? How are the "codes" macro:d out? As simulated key presses, or are via the Wayland IME protocol?

> I use no IME like ibus or fcitx5 because I don't need them, I've setup my keyboard to macro out ctrl+shift+u codes for international characters. How exactly does that work? How are the "codes" macro:d out? As simulated key presses, or are via the Wayland IME protocol?
Poster

As simulated key presses. Unfortunately, it's the only way to get Unicode out of a keyboard direcly, but it works pretty well everywhere else, and I completely avoid needing to install and setup IMEs on every single machine I use.

As simulated key presses. Unfortunately, it's the only way to get Unicode out of a keyboard direcly, but it works pretty well everywhere else, and I completely avoid needing to install and setup IMEs on every single machine I use.
Owner

Ok, in that case IME in foot is not involved at all (meaning the 737769 sequence is useless).

Can you do the following:

  • Start foot with WAYLAND_DEBUG=1 (you'll also want to redirect to a log file), then enter a few Unicode characters. Please try to avoid any other key presses, if possible. When attaching the log, please describe which Unicode codepoints you entered (and in which order).

  • In a running foot (can be, but doesn't have to be the foot instance from above), run showkey -a and then enter a couple of Unicode characters. Repeat, but with cat - instead of showkey -a.

Ok, in that case IME in foot is not involved at all (meaning the 737769 sequence is useless). Can you do the following: * Start foot with `WAYLAND_DEBUG=1` (you'll also want to redirect to a log file), then enter a few Unicode characters. Please try to avoid _any_ other key presses, if possible. When attaching the log, please describe which Unicode codepoints you entered (and in which order). * In a running foot (can be, but doesn't have to be the foot instance from above), run `showkey -a` and then enter a couple of Unicode characters. Repeat, but with `cat -` instead of `showkey -a`.
Owner

I've already reassigned the conflicting show-urls-launch shortcut

Btw, I assume ctrl+shift+u is hooked either directly in the keyboard firmware, or by your compositor? Then you shouldn't have to unbind the shortcut in foot, as foot should never receive the combo at all.

> I've already reassigned the conflicting show-urls-launch shortcut Btw, I assume <kbd>ctrl</kbd>+<kbd>shift</kbd>+<kbd>u</kbd> is hooked either directly in the keyboard firmware, or by your compositor? Then you shouldn't have to unbind the shortcut in foot, as foot _should_ never receive the combo at all.
Poster

Yes, ctrl+shift+u is built into the firmware. It's not all that uncommon for QMK users to bind emoji and such as a macro that uses that combination, I just take it further.

I've attached the logs below. The sequence of buttons pressed is always 'асдфг', with no other inputs, which in hex is U+0430, U+0441, U+0434, U+0444 and U+0433.
cat - is empty, as foot erases the hex code that gets briefly echo'd.

Yes, `ctrl+shift+u` is built into the firmware. It's not all that uncommon for QMK users to bind emoji and such as a macro that uses that combination, I just take it further. I've attached the logs below. The sequence of buttons pressed is always 'асдфг', with no other inputs, which in hex is U+0430, U+0441, U+0434, U+0444 and U+0433. `cat -` is empty, as foot erases the hex code that gets briefly echo'd.
Owner

I'm not seeing anything obviously wrong here. Looking at the wayland log, there are quite a few keyboard.key() events. Possibly more than I would have expected.

What exactly is the keyboard emitting for these characters? I'm asking since the key events from the compositor are for key codes (not Unicode code points). The key codes are translated to XKB symbols (and then to utf-8) through the current XKB layout.

It would also be helpful if you could do a debug build of foot, with this patch applied, and then run ./foot -d debug, and re-do the showkey experiment.

diff --git a/input.c b/input.c
index d4598cf6..fd52110a 100644
--- a/input.c
+++ b/input.c
@@ -21,7 +21,7 @@
 #include <xdg-shell.h>
 
 #define LOG_MODULE "input"
-#define LOG_ENABLE_DBG 0
+#define LOG_ENABLE_DBG 1
 #include "log.h"
 #include "commands.h"
 #include "config.h"

You should see log output like:

 dbg: input.c:1441: adiaeresis (228/0xe4): seat=default, term=0x620000002080, serial=9742, mods=0x00000000, consumed=0x00000083, repeats=1
 dbg: input.c:933: term->modify_other_keys=0, count=2, is_ctrl=0 (utf8=0xc3), sym=228
 dbg: input.c:1441: adiaeresis (228/0xe4): seat=default, term=0x620000002080, serial=9743, mods=0x00000000, consumed=0x00000083, repeats=0
 dbg: input.c:1441: Control_L (65507/0xffe3): seat=default, term=0x620000002080, serial=9744, mods=0x00000000, consumed=0x00000000, repeats=0
I'm not seeing anything obviously wrong here. Looking at the wayland log, there are quite a few `keyboard.key()` events. Possibly more than I would have expected. What _exactly_ is the keyboard emitting for these characters? I'm asking since the key events from the compositor are for key **codes** (not Unicode code points). The key codes are translated to XKB symbols (and then to utf-8) through the current XKB layout. It would also be helpful if you could do a **debug** build of foot, with this patch applied, and then run `./foot -d debug`, and re-do the showkey experiment. ```diff diff --git a/input.c b/input.c index d4598cf6..fd52110a 100644 --- a/input.c +++ b/input.c @@ -21,7 +21,7 @@ #include <xdg-shell.h> #define LOG_MODULE "input" -#define LOG_ENABLE_DBG 0 +#define LOG_ENABLE_DBG 1 #include "log.h" #include "commands.h" #include "config.h" ``` You should see log output like: ``` dbg: input.c:1441: adiaeresis (228/0xe4): seat=default, term=0x620000002080, serial=9742, mods=0x00000000, consumed=0x00000083, repeats=1 dbg: input.c:933: term->modify_other_keys=0, count=2, is_ctrl=0 (utf8=0xc3), sym=228 dbg: input.c:1441: adiaeresis (228/0xe4): seat=default, term=0x620000002080, serial=9743, mods=0x00000000, consumed=0x00000083, repeats=0 dbg: input.c:1441: Control_L (65507/0xffe3): seat=default, term=0x620000002080, serial=9744, mods=0x00000000, consumed=0x00000000, repeats=0 ```
Poster

Attached the new log.
Makes sense to me, the reason why it creates so many events is that it needs to signal key release events.

Attached the new log. Makes sense to me, the reason why it creates so many events is that it needs to signal key release events.
Owner

It looks like everything gets sent as-is directly to foot. I.e. foot receives first the ctrl+shift+u combo, and then your 0 4 3 x key presses.

I thought your keyboard was supposed to intercept this? I.e. that your actual key presses weren't supposed to reach foot, but instead be intercepted by your keyboard, which then macros out the Unicode character? Am I missing something here?

It looks like everything gets sent as-is directly to foot. I.e. foot receives first the ctrl+shift+u combo, and then your `0 4 3 x` key presses. I thought your keyboard was supposed to intercept this? I.e. that your actual key presses weren't supposed to reach foot, but instead be intercepted by your keyboard, which then macros out the Unicode character? Am I missing something here?
Poster

No, that's how alt codes work. Applications are meant to interpret ctrl+shift+u as the start of a Unicode character, with the hex code of the character following, and are supposed to output a single Unicode character.
It's ugly, messy, platform-dependent (shortcut is different on Windows and OS/X) but sadly, it's currently the only way to get Unicode directly out from a keyboard.

No, that's how alt codes work. Applications are meant to interpret ctrl+shift+u as the start of a Unicode character, with the hex code of the character following, and are supposed to output a single Unicode character. It's ugly, messy, platform-dependent (shortcut is different on Windows and OS/X) but sadly, it's currently the only way to get Unicode directly out from a keyboard.
dnkl referenced this issue from a commit 4 months ago
dnkl referenced this issue from a commit 4 months ago
Owner

I see. I misunderstood your initial request/report.

I'm aware many programs implements this. My standpoint has always been that this is better implemented by an IME. It's better to spend time implementing a minimal IME if fcitx5 is too bloated, than implementing fancy Unicode input in every single program.

That said, I think there's room in foot for a (very) simple Unicode mode where we provide no menus, no previews, or any other visual cues for that matter. It should work pretty well in your use case I think.

See #1124, and please do test it, if you get a chance.

I see. I misunderstood your initial request/report. I'm aware many programs implements this. My standpoint has always been that this is better implemented by an IME. It's better to spend time implementing a minimal IME if fcitx5 is too bloated, than implementing fancy Unicode input in every single program. That said, I think there's room in foot for a (very) simple Unicode mode where we provide no menus, no previews, or any other visual cues for that matter. It should work pretty well in your use case I think. See https://codeberg.org/dnkl/foot/pulls/1124, and please do test it, if you get a chance.
dnkl referenced this issue from a commit 4 months ago
dnkl referenced this issue from a commit 4 months ago
dnkl referenced this issue from a commit 4 months ago
Poster

Tested it, works pretty well. No flickering either.
I think changing the default show-url shortcut and binding this on by default would be better, but I have no strong opinion. Users already have to read the wiki to find out how to make other important features work.

Tested it, works pretty well. No flickering either. I think changing the default show-url shortcut and binding this on by default would be better, but I have no strong opinion. Users already have to read the wiki to find out how to make other important features work.
dnkl closed this issue 4 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dnkl/foot#1116
Loading…
There is no content yet.