Skip to content

exwm-input--update-focus cause key not sent to input-method-function #705

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

Open
QiangF opened this issue Jan 30, 2020 · 12 comments
Open

exwm-input--update-focus cause key not sent to input-method-function #705

QiangF opened this issue Jan 30, 2020 · 12 comments

Comments

@QiangF
Copy link

QiangF commented Jan 30, 2020

See the debug log here,
https://gist.github.com/QiangF/3da9f935354d31657a056ef31c6127cf

Every time exwm-input--update-focus is run, one key (118) is not processed by the input method, the focused window does not changing,, the focus actually does not need update. Is the input method disabled during that instant?

@QiangF
Copy link
Author

QiangF commented Jan 30, 2020

I think the fix will be: if the focus did not change, don't run that function.

@QiangF
Copy link
Author

QiangF commented Jan 31, 2020

Seems to be fixed by #706

@ch11ng
Copy link
Owner

ch11ng commented Feb 2, 2020

That change may have some unintended side effects I'm afraid. I wonder why there was a change in buffer-list. I didn't find the definition of rime-input-method though.

@QiangF
Copy link
Author

QiangF commented Feb 2, 2020

rime-input-method is my simplified chinese input method:
https://gist.github.com/QiangF/d726722d4ceee0cd31fc59163ae2a5bd
I put exwm--log there to print the key received by input method. I have not seen any side effect by far.

There might be better fix if we know the reason for the issue.

@QiangF
Copy link
Author

QiangF commented Feb 2, 2020

The change in buffer-list is probably because I use a temporary buffer for the preedit. Also exwm-xim has a " *temp*" buffer.

@ch11ng
Copy link
Owner

ch11ng commented Feb 2, 2020

I've not tried it myself but it seems your input method does call functions like get-buffer-create which in turn run buffer-list-update-hook.

@ch11ng
Copy link
Owner

ch11ng commented Feb 2, 2020

What about let-bind exwm-input--skip-buffer-list-update to t so as to skip certain calls to buffer-list-update-hook? This should not be abused though.

@QiangF
Copy link
Author

QiangF commented Feb 3, 2020

No, "let-bind exwm-input--skip-buffer-list-update to t" doesn't work.
I tried set it both in exwm-xim:

         (let ((input-method-use-echo-area t)
               (exwm-input--skip-buffer-list-update t))
               (with-temp-buffer

and in my input method:

(defmacro rime-with-preedit (&rest forms)
(declare (indent 0) (debug t))
`(let ((exwm-input--skip-buffer-list-update t))
    (with-current-buffer
        (get-buffer-create " *rime-preedit*")
    ,@forms)))

I have type 7 key 118, and the last one is lost, see the debug output:

https://gist.github.com/QiangF/721dec58a86405dc72fdde3dfade2c61

@QiangF
Copy link
Author

QiangF commented Feb 3, 2020

There are many other command that create invisible buffers, to find out each of them is impossible. If both the focused buffer and the current window doesn't change, does that mean the focus has not changed? why do you need to update the focus in this case?

@ch11ng
Copy link
Owner

ch11ng commented Feb 16, 2020

If both the focused buffer and the current window doesn't change, does that mean the focus has not changed?

No. All X clients can change input focus, or we won't have to take the trouble to set it every possible time.

@QiangF
Copy link
Author

QiangF commented Feb 17, 2020

I think there are 3 possible solutions:

  1. during exwm-input--update-focus, don't process key event, like (push key unread-command-events)
  2. don't run exwm-input--update-focus when the buffer update is due to normal emacs buffers (non exwm mode buffers), especially hidden buffers
  3. use the pull request solution: I have not find any issues so far with that.

@ch11ng
Copy link
Owner

ch11ng commented Feb 17, 2020

Solution 2 is the most nature way to go if feasible. There was a implementation which can be broken sometimes. You can stick to that PR until we work out another implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants