Does foot support IME (Input Method Editor) like Ibus or Fcitx? #134

Closed
opened 1 year ago by 8cAKSsOJXxDr0InVuDi3V18yLnNILX0R8jHPQys2 · 22 comments

I am attempting to use Fcitx in foot, but it does not seem to be receiving the IME input. Fcitx is functioning with other applications, but not foot. Is this function available?

foot version 1.4.4-298-ga132e6c (Sep 09 2020, branch 'master')
sway version v1.5
fcitx version: 4.2.9.7

Environment variables set:

GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx

Let me know if additional information is necessary.

I am attempting to use Fcitx in foot, but it does not seem to be receiving the IME input. Fcitx is functioning with other applications, but not foot. Is this function available? foot version 1.4.4-298-ga132e6c (Sep 09 2020, branch 'master') sway version v1.5 fcitx version: 4.2.9.7 Environment variables set: ``` GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx ``` Let me know if additional information is necessary.
dnkl commented 1 year ago
Owner

I haven't used neither fcitx nor ibus, so I have some reading up to do. But, could you tell me if you have it working in any other Wayland native, non-QT/GTK application(s)?

I haven't used neither fcitx nor ibus, so I have some reading up to do. But, could you tell me if you have it working in any other Wayland **native**, **non-QT/GTK** application(s)?
dnkl commented 1 year ago
Owner

My understanding so far:

  • You need fcitx5 for native Wayland support.
  • Foot would need to implement the text input Wayland protocol.
My understanding so far: * You need fcitx5 for native Wayland support. * Foot would need to implement the [text input](https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/text-input/text-input-unstable-v3.xml) Wayland protocol.
dnkl added the
enhancement
help wanted
labels 1 year ago

OK, so I installed fcitx5(0.0.0.20200909.1-1 on Arch). I tested it on alacritty (and foot) and it did not work, although this is apparently a known issue for alacritty (only works w/ xorg). Honestly, I'm struggling to find a native non gtk/qt app to test with.

Thank you for taking the time to answer my question, and for introducing me to fcitx5.

OK, so I installed fcitx5(0.0.0.20200909.1-1 on Arch). I tested it on alacritty (and foot) and it did not work, although this is apparently a known issue for alacritty (only works w/ xorg). Honestly, I'm struggling to find a native non gtk/qt app to test with. Thank you for taking the time to answer my question, and for introducing me to fcitx5.
dnkl commented 1 year ago
Owner

I think this is something we should at least try to implement in foot. I've only looked briefly at the text input protocol, but it doesn't look hard, but it is potentially a fair amount of work.

I find this rather interesting, even though it's not something I'm using myself. I would start experiment with foot's implementation, but right now I'm focusing on fcft-2.3 and getting foot 1.5 ready.

After that I can hopefully come back to this. Of course, if someone else wants to give it a try, by all means, please do!

I think this is something we should at least try to implement in foot. I've only looked briefly at the text input protocol, but it doesn't look _hard_, but it is potentially a fair amount of work. I find this rather interesting, even though it's not something I'm using myself. I would start experiment with foot's implementation, but right now I'm focusing on fcft-2.3 and getting foot 1.5 ready. After that I can hopefully come back to this. Of course, if someone else wants to give it a try, by all means, please do!
dnkl added this to the 1.6.0 milestone 1 year ago
dnkl removed the
help wanted
label 1 year ago
dnkl self-assigned this 1 year ago
dnkl commented 1 year ago
Owner

There's some initial work in the input-method-editor branch; it's supposed to log all callbacks from the text-input protocol.

So far I've only seen enter/leave events. These trigger when fcitx5 is running, but not otherwise. So that's something.

But I'm not getting any other callbacks. According to fcitx5-remote, its state is "close" (display fcitx state, 0 for close, 1 for inactive, 2 for active).

I'm guessing I need fcitx5 to be active for anything more to happen. Just not sure how to to that. There doesn't appear to be any more foot should be doing, protocol wise.

There's some initial work in the _input-method-editor_ branch; it's supposed to log all callbacks from the _text-input_ protocol. So far I've only seen _enter_/_leave_ events. These trigger when fcitx5 is running, but not otherwise. So that's something. But I'm not getting any other callbacks. According to `fcitx5-remote`, its state is _"close"_ (_display fcitx state, 0 for close, 1 for inactive, 2 for active_). I'm guessing I need fcitx5 to be _active_ for anything more to happen. Just not sure how to to that. There doesn't appear to be any more foot should be doing, protocol wise.

Let me know if there is anything I can do to help with testing. Would it be helpful for me to try and build the IME branch (and use)?

Let me know if there is anything I can do to help with testing. Would it be helpful for me to try and build the IME branch (and use)?
dnkl commented 1 year ago
Owner

Would it be helpful for me to try and build the IME branch (and use)?

Probably not. But thanks for the offer.

At this point what's needed is research. What exactly is the status of fcitx5 on pure Wayland, and in particular, in non-GTK and non-QT applications.

I've seen it work in QT applications with the fcitx5 QT im module, but not without. This suggests it is supposed to work without GTK/QT im modules.

Another thing is the configuration of fcitx5; it looks like you're configuring global keyboard shortcuts to activate it. But applications cannot "hook" global keyboard shortcuts under Wayland. I'm guessing the GTK/QT im modules somehow (dbus?) reads the fcitx5 configuration and implements the shortcut handling client side. That would explain why I can't activate the IME from foot.

> Would it be helpful for me to try and build the IME branch (and use)? Probably not. But thanks for the offer. At this point what's needed is research. What exactly *is* the status of fcitx5 on pure Wayland, and in particular, in non-GTK and non-QT applications. I've seen it work in QT applications **with** the fcitx5 QT im module, but not without. [This](https://wiki.archlinux.org/index.php/Fcitx5#Input_method_module) suggests it is _supposed_ to work without GTK/QT im modules. Another thing is the configuration of fcitx5; it looks like you're configuring global keyboard shortcuts to activate it. But applications cannot "hook" global keyboard shortcuts under Wayland. I'm guessing the GTK/QT im modules somehow (dbus?) reads the fcitx5 configuration and implements the shortcut handling client side. That would explain why I can't activate the IME from foot.
dnkl added the
help wanted
label 1 year ago

I have tried the IME branch with https://github.com/emersion/wlhangul (note that it requires a sway patch), and it works so far:

 dbg: ime.c:16: enter: seat=seat0
 dbg: ime.c:66: preedit-strig: text=ㄱ, begin=0, end=3
 dbg: ime.c:87: done: serial=1
 dbg: ime.c:66: preedit-strig: text=개, begin=0, end=3
 dbg: ime.c:87: done: serial=1
 dbg: ime.c:66: preedit-strig: text=, begin=0, end=0
 dbg: ime.c:73: commit: text=개
 dbg: ime.c:87: done: serial=1
 dbg: ime.c:59: leave: seat=seat0

so wlhangul may be an easier testbed to implement this feature.

As for fcitx5, with said sway patch not only it doesn't work, but I end up in a very bad state where I cannot send any keypress to applications anymore (not a foot issue, maybe fcitx5 isn't ready for it yet).

I have tried the IME branch with https://github.com/emersion/wlhangul (note that it requires a sway patch), and it works so far: ``` dbg: ime.c:16: enter: seat=seat0 dbg: ime.c:66: preedit-strig: text=ㄱ, begin=0, end=3 dbg: ime.c:87: done: serial=1 dbg: ime.c:66: preedit-strig: text=개, begin=0, end=3 dbg: ime.c:87: done: serial=1 dbg: ime.c:66: preedit-strig: text=, begin=0, end=0 dbg: ime.c:73: commit: text=개 dbg: ime.c:87: done: serial=1 dbg: ime.c:59: leave: seat=seat0 ``` so wlhangul may be an easier testbed to implement this feature. As for fcitx5, with said sway patch not only it doesn't work, but I end up in a very bad state where I cannot send any keypress to applications anymore (not a foot issue, maybe fcitx5 isn't ready for it yet).
Owner

@st3r4g thanks for the update! Sounds like we have a way forward :)

@st3r4g thanks for the update! Sounds like we have a way forward :)
dnkl added a new dependency 11 months ago
Owner

Progress update: I have wlhangul working in Sway, and fcitx5 in Gnome. Neither shows a candidate list, meaning the only feedback you get is from foot. I'm pretty sure this is a limitation of the IMEs, not foot.

The input-method-editor branch in foot has been updated to push committed text to the application. This means you can get text into foot, but since pre-edit (preview?) doesn't work (yet), you're kind of typing blind folded.

Progress update: I have _wlhangul_ working in Sway, and _fcitx5_ in Gnome. Neither shows a candidate list, meaning the only feedback you get is from foot. I'm pretty sure this is a limitation of the IMEs, not foot. The `input-method-editor` branch in foot has been updated to push **committed** text to the application. This means you _can_ get text into foot, but since pre-edit (preview?) doesn't work (yet), you're kind of typing blind folded.
Owner

Pre-edit has been implemented, and the PR in #232 is ready for initial testing.

My initial testing has been with wlhangul in Sway, but mostly fcitx5/anthy in Gnome.

Pre-edit has been implemented, and the PR in https://codeberg.org/dnkl/foot/pulls/232 is ready for initial testing. My initial testing has been with wlhangul in Sway, but mostly fcitx5/anthy in Gnome.
Owner

Neither shows a candidate list, meaning the only feedback you get is from foot. I'm pretty sure this is a limitation of the IMEs, not foot.

For what it's worth, gnome-terminal behaves in exactly the same way.

> Neither shows a candidate list, meaning the only feedback you get is from foot. I'm pretty sure this is a limitation of the IMEs, not foot. For what it's worth, gnome-terminal behaves in exactly the same way.

Neither shows a candidate list, meaning the only feedback you get is from foot. I'm pretty sure this is a limitation of the IMEs, not foot.

Yes this is something to be (optionally) implemented by the IME/compositor. text-input clients are not even aware of candidates. The text-input has to specify an area for its placement with set_cursor_rectangle though.

> Neither shows a candidate list, meaning the only feedback you get is from foot. I'm pretty sure this is a limitation of the IMEs, not foot. Yes this is something to be (optionally) implemented by the IME/compositor. text-input clients are not even aware of candidates. The text-input has to specify an area for its placement with `set_cursor_rectangle` though.

My main use case for IME support in a terminal would be to comfortably use an IME in vim/kakoune. Therefore, one needs a mechanism to enable/disable the IME automatically when entering/exiting insert mode. I wonder if we can achieve this with a custom escape sequence that makes foot send enable/disable zwp_text_input requests. The editor would then be configured to emit this escape sequence on entering/exiting insert mode.

My main use case for IME support in a terminal would be to comfortably use an IME in vim/kakoune. Therefore, one needs a mechanism to enable/disable the IME automatically when entering/exiting insert mode. I wonder if we can achieve this with a custom escape sequence that makes foot send enable/disable zwp_text_input requests. The editor would then be configured to emit this escape sequence on entering/exiting insert mode.
Owner

@st3r4g that's a very interresting idea. After only briefly playing around with IME in vim and kakoune, the current state is not satisfactory, and I agree that having a way to disable/enable IME would make things much more usable.

Adding an escape definitely makes sense and isn't technically hard to do.

We'll have to think it through however; what kind of escape should be used? I think either a DECSET (\E[?Nh and \E[?Nl), or an OSC would make the most sense. The trick is to choose one not likely to clash with other terminals' future escapes.

We should perhaps also consider if it would make sense to try to auto-detect terminal modes where IME should be disabled.

@st3r4g that's a very interresting idea. After only briefly playing around with IME in vim and kakoune, the current state is not satisfactory, and I agree that having a way to disable/enable IME would make things much more usable. Adding an escape definitely makes sense and isn't technically hard to do. We'll have to think it through however; what kind of escape should be used? I think either a `DECSET` (`\E[?Nh` and `\E[?Nl`), or an OSC would make the most sense. The trick is to choose one not likely to clash with other terminals' future escapes. We should perhaps also consider if it would make sense to try to auto-detect terminal modes where IME should be disabled.
Owner

The text-input has to specify an area for its placement with set_cursor_rectangle though.

I figured as much. Foot does call it, but not yet with correct values. This is still on the TODO list.

> The text-input has to specify an area for its placement with set_cursor_rectangle though. I figured as much. Foot does call it, but not yet with correct values. This is still on the TODO list.
Owner

The text-input has to specify an area for its placement with set_cursor_rectangle though.

I figured as much. Foot does call it, but not yet with correct values. This is still on the TODO list.

After looking at how this works, I think foot will not be able to use this feature. We'd need to call set_cursor_rectangle() each time the cursor position changes, which is on almost every single byte we receive from the client application. This would flood the Wayland socket and kill performance, most likely.

For now, I've removed the call.

> > The text-input has to specify an area for its placement with set_cursor_rectangle though. > I figured as much. Foot does call it, but not yet with correct values. This is still on the TODO list. After looking at how this works, I think foot will not be able to use this feature. We'd need to call `set_cursor_rectangle()` each time the cursor position changes, which is on almost every single byte we receive from the client application. This would flood the Wayland socket and kill performance, most likely. For now, I've removed the call.
Owner

Adding an escape definitely makes sense and isn't technically hard to do.

I've played around a bit with this. I think a DECSET escape makes the most sense, since then the IME enable/disable state will be automatically restored (when exiting e.g. vim) to whatever it was before. Assuming the application uses XTSAVE+XTRESTORE of course...

I used :autocmd InsertEnter * silent !echo -en "<escape>" (and for InsertLeave). This worked well enough. I haven't pushed the escape yet, but I don't see anything preventing us implementing this for real.

> Adding an escape definitely makes sense and isn't technically hard to do. I've played around a bit with this. I think a `DECSET` escape makes the most sense, since then the IME enable/disable state will be automatically restored (when exiting e.g. vim) to whatever it was before. Assuming the application uses `XTSAVE+XTRESTORE` of course... I used `:autocmd InsertEnter * silent !echo -en "<escape>"` (and for `InsertLeave`). This worked well enough. I haven't pushed the escape yet, but I don't see anything preventing us implementing this for real.

I used :autocmd InsertEnter * silent !echo -en "<escape>" (and for InsertLeave). This worked well enough. I haven't pushed the escape yet, but I don't see anything preventing us implementing this for real.

Nice! Looking forward to trying it.

> I used `:autocmd InsertEnter * silent !echo -en "<escape>"` (and for `InsertLeave`). This worked well enough. I haven't pushed the escape yet, but I don't see anything preventing us implementing this for real. Nice! Looking forward to trying it.
Owner

Nice! Looking forward to trying it.

Just pushed a new DECSET escape: \e[?737769h (enable), and \e[?737769l (disable).

73 77 69 is ASCII for IME. I'm open for better suggestions... :)

> Nice! Looking forward to trying it. Just pushed a new `DECSET` escape: `\e[?737769h` (enable), and `\e[?737769l` (disable). 73 77 69 is ASCII for IME. I'm open for better suggestions... :)

I used :autocmd InsertEnter * silent !echo -en "<escape>" (and for InsertLeave)

I'm having a hard time configuring the editors... with the configuration above, neovim doesn't send the escape correctly.
EDIT: This is working (found here):

autocmd InsertEnter * call chansend(v:stderr, "\e[?737769h")
autocmd InsertLeave * call chansend(v:stderr, "\e[?737769l")

which I think is better than echo because it doesn't spawn an external process. Feels pretty smooth, without any visual glitches or delays.

vim works but I get a one second pause between exiting insert mode and sending the escape for some reason. Entering is much quicker.
EDIT: the delay is fixed by set ttimeoutlen=0

> I used `:autocmd InsertEnter * silent !echo -en "<escape>" (and for InsertLeave)` I'm having a hard time configuring the editors... with the configuration above, **neovim** doesn't send the escape correctly. EDIT: This is working (found [here](https://github.com/neovim/neovim/issues/7584)): ``` autocmd InsertEnter * call chansend(v:stderr, "\e[?737769h") autocmd InsertLeave * call chansend(v:stderr, "\e[?737769l") ``` which I think is better than echo because it doesn't spawn an external process. Feels pretty smooth, without any visual glitches or delays. **vim** works but I get a one second pause between exiting insert mode and sending the escape for some reason. Entering is much quicker. EDIT: the delay is fixed by `set ttimeoutlen=0`
Owner

vim works but I get a one second pause between exiting insert mode and sending the escape for some reason. Entering is much quicker.
EDIT: the delay is fixed by set ttimeoutlen=0

The reason is Escape emits \E, which is also a prefix to many other key sequences. For this reason, vim waits a while, to be sure \E really was just \E and not some other key.

Incidentally, foot recently gained the ability to instead emit \E[27;1;27~ for Escape. If you could convince vim to use that instead, you could set ttimeoutlen=0 and be sure it doesn't cause any ill effects. See #225 (issue) and #226 (PR - which has been merged).

autocmd InsertEnter * call chansend(v:stderr, "\e[?737769h")
autocmd InsertLeave * call chansend(v:stderr, "\e[?737769l")

Nice! Thanks for sharing. I'm not a (n)vim user and just did quick search for how to emit the escapes. Your version does look better.

> vim works but I get a one second pause between exiting insert mode and sending the escape for some reason. Entering is much quicker. > EDIT: the delay is fixed by set ttimeoutlen=0 The reason is <Kbd>Escape</kbd> emits `\E`, which is also a prefix to many other key sequences. For this reason, vim waits a while, to be sure `\E` really was just `\E` and not some other key. Incidentally, foot recently gained the ability to instead emit `\E[27;1;27~` for <kbd>Escape</kbd>. If you could convince vim to use that instead, you could `set ttimeoutlen=0` and be sure it doesn't cause any ill effects. See https://codeberg.org/dnkl/foot/issues/225 (issue) and https://codeberg.org/dnkl/foot/pulls/226 (PR - which has been **merged**). > ``` > autocmd InsertEnter * call chansend(v:stderr, "\e[?737769h") > autocmd InsertLeave * call chansend(v:stderr, "\e[?737769l") > ``` Nice! Thanks for sharing. I'm not a (n)vim user and just did quick search for how to emit the escapes. Your version does look better.
dnkl removed the
help wanted
label 11 months ago
dnkl referenced this issue from a commit 11 months ago
dnkl closed this issue 11 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Blocks
#197 1.6.0
dnkl/foot
Loading…
There is no content yet.