Skip to content
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

Passthrough input when explicitly reading events and keys #938

Merged
merged 1 commit into from
Jan 8, 2024
Merged

Passthrough input when explicitly reading events and keys #938

merged 1 commit into from
Jan 8, 2024

Conversation

Stebalien
Copy link
Contributor

When any of these functions are called, Emacs expects to receive all input events until they return. Unfortunately, there doesn't appear to be a reliable way to detect that these functions are currently running other than advising them, so that's what I did.

These functions are:

  • read-char
  • read-char-exclusive
  • read-key-sequence-vector
  • read-key-sequence
  • read-event

In terms of downsides... I've been advising these functions (well, most of them) in my config for years now and haven't had any issues.

Fixes #921, #570 (and probably others)

When any of these functions are called, Emacs expects to receive all
input events until they return. Unfortunately, there doesn't appear to
be a reliable way to detect that these functions are currently running
other than advising them.

* exwm-input.el (exwm-input--init): Advise low-level input reading
functions to bind 'exwm-input-line-mode-passthrough' to t when called.
(exwm-input--exit): Unadvise.
(exwm-input--call-with-passthrough): The advice.
(exwm-input--passthrough-functions): The functions we now advise.
@medranocalvo
Copy link
Collaborator

This is great, thank you. We already advise when there's no other way. (Ideally, we should report Emacs bugs for stuff we advise, in case a mechanism exists or can be made for us...)

I'll merge and I'd propose leaving this some time in master for people to try it out. Does that sound OK?

@minad
Copy link
Contributor

minad commented Jan 8, 2024 via email

@medranocalvo
Copy link
Collaborator

medranocalvo @.***> writes:
This is great, thank you. We already advise when there's no other way. (Ideally, we should report Emacs bugs for stuff we advise, in case a mechanism exists or can be made for us...)
Yes, we should do that - at least for the cases we consider particularly intrusive/problematic. Personally I am not fond of the indirection via the server for blocking GUI features.

I opened to track that #943 (we should do the migration and avoid opening more tickets over here. I'll look into working on that on the following days, though you two are welcome push forward).

I'll merge and I'd propose leaving this some time in master for people to try it out. Does that sound OK?
Sounds good. I am installing EXWM from GNU ELPA-devel. If this is not yet the case we should document this installation method, such that more users can beta test new functionality.

There's many users that track the master branch here on GitHub. I think elpa-devel is less well known and we should encourage it. In https://github.com/ch11ng/exwm/wiki/Maintenance there's also two ideas I planned but never actually brought into action: EXWM Testing Team, people who opt in to test particular features (think systemtray or XRandr, which I don't use); and Call For Testing, kind of a release candidate announcement where the testing team members would be @tagged.

@medranocalvo medranocalvo merged commit 01ae286 into ch11ng:master Jan 8, 2024
@medranocalvo
Copy link
Collaborator

I merged this to master and pushed to externals/exwm as well. Congrats! (Soon you'll merge yourself :-)).

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 this pull request may close these issues.

org-resolve-clocks (and other spontaneous focus-grabing functions) has conflict with EXWM-mode buffers
3 participants