Repeated key in st #33
Comments
|
it's irrelevant IMHO. I think the cause is same as #30. |
|
Should be improved after 75d5cbd . |
|
Actually I just noticed that st use a very small buffer for key string, so it will not commit string longer than 32 bytes from im. Probably you should report this to st upstream (looking for the caller of XmbLookupString). Comparing to xterm, xterm uses 500 bytes as the buffer, which should be practical for any common usage. |
|
The issue still persists even in the latest commit. |
|
In the meantime, I increased the buffer from 32 to 64 to take in middle to long string from IME, so it should even work for sentences now, the patch was included in upstream https://git.suckless.org/st/commit/895e5b50a8cc835c19a45e1e328eb4dc78f5fd0c.html. |
|
Tried multiple different xim based application (gtk-xim, xterm) non of them have the same problem. So I don't think the issue is in fcitx. I suspect st misses some XFlush call. |
|
But I tried using old fcitx and it works fine, okay I will check on the XFlush call. |
|
I believe it probably have something to do with high autorepeat I did with |
|
When we are talking about the real cause of the bug, we are not talking
about what triggers the bug.
With that being said, under your autorepeat settings, xterm, gtk based xim,
work properly. I can only assume that the bug is in st.
…On Thu, Jan 30, 2020 at 07:31 Ivan Tham ***@***.***> wrote:
I believe it probably have something to do with high autorepeat I did with xset
r rate 150 60, when I did not set that, it works nicely.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#33?email_source=notifications&email_token=AAB7MZC62KHONSC5ULDDU4LRALXFJA5CNFSM4KFX5OY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKLM3PI#issuecomment-580308413>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB7MZAJCR54LRT5FJY3THTRALXFJANCNFSM4KFX5OYQ>
.
|
|
Ah, I believed I spot the issue in st, it was introduced in https://git.suckless.org/st/commit/e85b6b64660214121164ea97fb098eaa4935f7db.html#h0-0-3 where |
|
Weird that |
|
on the spot uses XNPreeditStartCallback
over the spot doesn’t use that.
fcitx by default uses over the spot style for xim, because on the spot
doesn’t suppose notify the cursor location.
…On Sun, Feb 2, 2020 at 03:07 Ivan Tham ***@***.***> wrote:
Weird that XNPreeditStartCallback is not called on fcitx, but ibus is
able to recognize that. Should i not use XIMPreeditCallbacks?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#33?email_source=notifications&email_token=AAB7MZGFVMAE7U3QY6O6EZTRA2SNZA5CNFSM4KFX5OY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRUB6Q#issuecomment-581124346>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB7MZBWSVKOP47AOEQSN3LRA2SNZANCNFSM4KFX5OYQ>
.
|
|
Okay, thanks a lot for the input. st is also using over-the-spot for now. I also found a patch to fix the repeated key issue, looks like this is an issue with st, not fcitx5 but just that it doesn't happen in fcitx. |
Once too much event comes in to main thread and main thread is not fast enough to handle the event, the XIM client may hang in such case. Fix #33.
On some applications such as st, fcitx5 have weird behavior such that there feels like some keys are slow to appear (on us-dvorak) when holding the keys for a short while, the problem does not appear on fcitx.
Holding the keys in fcitx5 shuangpin input and mozc japanese input causes fcitx to kimpanel to hang (or crash) and I need to xkill st. Not sure if this is a bug in st or fcitx5 since it works with fcitx.
For example, hold
jfor a while and then presskwhen stop holding the key, the old keys will still be inserted. Maybe because I have a high keyboard typematic rate,xset r rate 150 60?The text was updated successfully, but these errors were encountered: