Open drskalman opened 10 months ago
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.
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.
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.)
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
@drskalman, we just merged a new change to deal with this issue (by new maintainer @Stebalien). Please test latest master and report back.
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.
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?
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.
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.
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.
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.
🙏
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.
Ah. You need to install xelb
from git, that's probably your problem.
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 byorg-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.