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

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

Open
drskalman opened this issue Sep 6, 2023 · 13 comments · Fixed by #938

Comments

@drskalman
Copy link

drskalman commented Sep 6, 2023

While working in an EXWM-mode buffer if one clocks in an Org mode task, org consider user being idle and call org-resolve-clocks. This results in EXWM sending all normal keys (like k or i which are needed to deal with org-resolve-clocks) to the EXWM-mode buffer so one can not interact with org-resolve-clocks and all EXWM related keys (win+1..7 for example) is being taken by org-resolve-clocks so one can not interact with EXWM (to get out of EXWM-mode buffer).

The only way out seems to be either quit the app in EXWM buffer (if the app offer a way to do that) or send abort-recursive-edit from another tty.

@medranocalvo
Copy link
Collaborator

Org is using read-char-exclusive. It seems to me that this function is quite low level. EXWM does not currently have a way to detect that Emacs is expecting the keyboard event, so it delivers it to the focused X window (or does not intercept it). Except for global keys (win+1..7, I assume); these are intercepted and delivered to Emacs, and returned by read-char-exclusive, but are not interesting to Org clock so it ignores them in a loop.

I'm not sure whether changing EXWM to detect it is desirable (fullscreen?) or even doable. (I miss @ch11ng.) I also have little time available. I suggest you to bring this up with the Org developers: could they use a higher-level function instead, like read-from-minibuffer (used by e.g. y-or-n-p). That function runs minibuffer-setup-hook and minibuffer-exit-hook, which let us detect that Emacs expect keyboard events.

@drskalman
Copy link
Author

The difference was that in earlier versions of EXWM I could click on some other window (beside the active EXWM) and the focus would go back to emacs and I was able to deal with org and that was an acceptable work around when on had a mouse. But now clicking on other windows while org has taken control of keyboard input does nothing. I assume the the desired behavoir is to change the focus when clicking even if org has taken over the keyboard input.

@medranocalvo
Copy link
Collaborator

Org recently (Org 9.6-3-ga4d38e, ~2022) changed the function to use read-char-exclusive instead of read-char; the former eats up non-character events as well. Please raise the issue with Org and let's see what can be done. (Please post a link the thread here if you report it.)

@drskalman
Copy link
Author

I submitted a bug: https://lists.gnu.org/archive/html/emacs-orgmode/2023-11/msg00150.html

They put it on EXWM I think:

"
There is a reason why we switched to `read-char-exclusive'. See
https://orgmode.org/list/87o82yaeie.fsf@gmail.com

I also do not see any reason why Org should not use
`read-char-exclusive' - the fact that EXWM does not support certain
Emacs primitives is not Org's problem, but a shortcoming of EXWM.

I would not mind changing read-char-exclusive' to another equivalent if that solves EXWM problem, but I am not aware about anything equivalent. As you see in the above link, using read-char' is not an option.

Not an Org bug.
Canceled.
"
https://lists.gnu.org/archive/html/emacs-orgmode/2023-11/msg00156.html

@medranocalvo
Copy link
Collaborator

@drskalman, we just merged a new change to deal with this issue (by new maintainer @Stebalien). Please test latest master and report back.

@drskalman
Copy link
Author

Sorry for the delay. I keep my exwm running for weeks and rarely logout. But I rebooted yesterday and logged backed in with the new exwm and this morning I had the same problem:

$ pacman -Qi emacs-exwm-git
Name            : emacs-exwm-git
Version         : r596.798dc60-1
Description     : Use emacs as windowmanager
Architecture    : any
URL             : https://github.com/ch11ng/exwm.git
Licenses        : GPL
Groups          : None
Provides        : emacs-exwm
Depends On      : emacs-xelb
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : emacs-exwm
Replaces        : None
Installed Size  : 393.44 KiB
Packager        : Unknown Packager
Build Date      : Sun 28 Jan 2024 04:37:15 AM EST
Install Date    : Sun 28 Jan 2024 04:37:24 AM EST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : None

I still can put end on org keyboard tyranny of org by issuing:

pkill -SIGUSR2 emacs

In another tty beside X. I can reproduce it relaibly if you need more info.

@Stebalien
Copy link
Contributor

Just to make sure everything is working, when you run M-x describe-function RET read-char-exclusive RET, it should say:

This function has :around advice: ‘exwm-input--call-with-passthrough’.

At the bottom. Do you see that?

Also, is your EXWM buffer in line or char mode?

@Stebalien
Copy link
Contributor

Finally, try running M-: (read-char-exclusive) RET in an EXWM buffer, then press a key. You should see the key's code printed in the echo area, and you shouldn't be locked out.

@drskalman
Copy link
Author

My bad. I had exwm also installed from gnu repo and so it was loading that instead of the one from os package manager. So yes to all of your above questions. it prints the character in message like

(#o30, #x18, ?\C-x)

I believe my buffer is in line mode.

But also it messed up completely with my randr and systray so i think I'm going back to 0.28 for now from GNU repo.

@Stebalien
Copy link
Contributor

But also it messed up completely with my randr and systray so i think I'm going back to 0.28 for now from GNU repo.

There's nothing on master that should mess with the systray or randr. Can you open a new issue for those? We're likely going to cut a release pretty soon.

@Stebalien
Copy link
Contributor

Specifically, can you open issues in https://github.com/emacs-exwm/exwm/issues. We're going to try to slowly close down issues on this issue tracker.

🙏

@drskalman
Copy link
Author

The problem seems to be with various functions of systray module failing with:

Wrong type argument: integer-or-marker-p, nil

including exwm-systemtray--exit which fails with above error at this line:

(exwm-systemtray--connection 'connected)

This error was preventing exwm-randr correctly intitialized, by removing systray, I got exwm-randr working pretty much Ok.

(Given that nobody else is reporting this) It might me because while I'm using exwm freshly cloned from github, I'm still using its dependency from elpa and I'm not able to easily remove the dependancies because I have variaous exwm dependant packages install from elpa (exwm-modeline, exwm-edite etc). So maybe I'm not a good tester after all, you probably need someone who doesn't depend so much on elpa to test.

Having said, I could start a new issue on that if you think it still makes sense.

@Stebalien
Copy link
Contributor

Ah. You need to install xelb from git, that's probably your problem.

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

Successfully merging a pull request may close this issue.

3 participants