Open RidaAyed opened 5 years ago
ch11ng
commented
5 years ago Probably nothing to do with the application itself. I tried it myself and it behaved normally. How do you get the buffer read-only error? I guess other applications should also be affected.
emiljoha
commented
5 years ago I am having a similar problem where the Firefox buffer occasionally becomes read only and I have to kill it and start it again.
Not sure if this happens in other applications. I have only seen it in Firefox but it does not happen very often and Firefox stands for almost all "non-emacs" buffers.
I am happy to send some logs if someone can direct me where to look for relevant ones.
emiljoha
commented
5 years ago looking at the *Messages* buffer I see the following.
funcall-interactively: Buffer is read-only: #<buffer Firefox>@emiljoha
I am having a similar problem where the Firefox buffer occasionally becomes read only and I have to kill it and start it again.
What if you hide & show it again (by switching to another buffer temporarily and then switch back)?
I am happy to send some logs if someone can direct me where to look for relevant ones.
Thanks! It'd likely help. Please check Step 4 in https://github.com/ch11ng/exwm/wiki#how-to-report-a-bug.
emiljoha
commented
5 years ago @ch11ng
What if you hide & show it again (by switching to another buffer temporarily and then switch back)?
I do not think that solved it but will check to make sure the next time it happens.
It'd likely help. Please check Step 4 in https://github.com/ch11ng/exwm/wiki#how-to-report-a-bug.
Nice with a "how to report bug" wiki entry. Have enabled debug output and will try and find the relevant parts next time it happens.
It happens quite often but now when I actually want it to happen it does not. Must try and figure out how to reproduce this...
emiljoha
commented
5 years ago So it happened again.
What if you hide & show it again (by switching to another buffer temporarily and then switch back)?
Switching workspace did actually make the Firefox bufffer editable again.
ch11ng
commented
5 years ago @emiljoha Did you manage to get a debug log?
setzer22
commented
5 years ago I experience this issue regularly. What works to make the buffer take my input again is to press the char/line mode toggle button in the modeline a bunch of times. After two or three toggles, the buffer goes back to being editable.
In my case (And I think this may be the case too for the original OP) this may have something to do with the way evil's normal/insert modes interacts with char/line modes in exwm. If anyone has had this issue with plain emacs (no evil-mode) my suspicion may be wrong.
Anyway, I will try to get a log once I get the chance. But the issue is not consistent enough for me so it may take some time until I can reliably replicate it.
emiljoha
commented
5 years ago @emiljoha
Did you manage to get a debug log?
Unfortunately not. But will continue to try and reproduce it.
If anyone has had this issue with plain emacs (no evil-mode) my suspicion may be wrong.
@setzer22 I am not using evil-mode....
sarg
commented
5 years ago I'm also affected by buffer is read-only. Here is how it reproduces for me:
emacsclient -n somefile, new buffer will replace the terminal in current windowbuffer is read-onlyIn *XELB-DEBUG* you can see that exwm-input--update-focus isn't called.
ch11ng
commented
5 years ago @sarg Thanks for the log. It seemed for some reason exwm-input--on-buffer-list-update ignored the event. Could you insert a log into the function just like the following?
(defun exwm-input--on-buffer-list-update ()
"Run in `buffer-list-update-hook' to track input focus."
+ (exwm--log)
(when (and (not (eq this-command #'handle-switch-frame))
(not exwm-input--skip-buffer-list-update)
(not (exwm-workspace--client-p))If the result contains a line exwm-input--on-buffer-list-update: without a line exwm-input--on-buffer-list-update: current-buffer=... following then it is the problem. But I'm not sure which condition would block it. From your report it's unlikely the first three.
sarg
commented
5 years ago I have logged all the condition values. What I see is that exwm-input--on-buffer-list-update isn't called at all. When I close emacs buffer and X buffer becomes visible in the same window - it doesn't receive the focus. Even when I press mouse button in the window it doesn't receive focus. What helps is to move mouse pointer to another window and back and then pressing mouse button.
ch11ng
commented
5 years ago What I see is that
exwm-input--on-buffer-list-updateisn't called at all.
Can't find it in the log either. Was the buffer killed normally? Otherwise I can't see why the hook was not run.
Even when I press mouse button in the window it doesn't receive focus.
This is because the Emacs window is already 'selected'.
sarg
commented
5 years ago Ugh, 3 hours debugging. Found the advice (https://github.com/hlissner/doom-emacs/blob/aa64cf94266a331c1fbb6b80b76e4b53bb6c8a9f/core/autoload/buffers.el#L279) that breaks things. Reported to author. Maybe my case isn't really related with topicstarter's.
medranocalvo
commented
5 years ago This sounds like heroic debugging @sarg, thank you very much. Indeed, resetting buffer-list-update-hook utterly breaks EXWM. I wonder whether that's the origin of all of our mysterious read-only buffer issues.
emiljoha
commented
5 years ago @ch11ng Finally found a way to reproduce this!
After reading issue #552 and especially the suggesting that:
Perhaps it has something to do with the buffer being displayed somewhere else.
c-x 3 and place the *scratch* buffer (or any other buffer except *terminal*) to the right.funcall-interactively: Buffer is read-only: #<buffer Firefox>
exwm-input--update-focus: focus-window=#<window 15 on *XELB-DEBUG*> focus-buffer=*XELB-DEBUG*
exwm-input--update-focus: Focus on #<window 15 on *XELB-DEBUG*>
exwm-input--set-active-window:
exwm--on-ClientMessage: atom=_NET_ACTIVE_WINDOW(340)
exwm-input--on-buffer-list-update: current-buffer=#<buffer *terminal*> selected-window=#<window 13 on *terminal*>
exwm-input--update-focus: focus-window=#<window 13 on *terminal*> focus-buffer=*terminal*
exwm-input--update-focus: Focus on #<window 13 on *terminal*>
exwm-input--set-active-window:
exwm--on-ClientMessage: atom=_NET_ACTIVE_WINDOW(340)
exwm-input--on-buffer-list-update: current-buffer=#<buffer *Minibuf-1*> selected-window=#<window 4 on *Minibuf-1*>
exwm-layout--on-minibuffer-setup:
exwm-input--update-focus: focus-window=#<window 4 on *Minibuf-1*> focus-buffer= *Minibuf-1*
exwm-input--update-focus: Focus on #<window 4 on *Minibuf-1*>
exwm-input--set-active-window:
exwm--on-ClientMessage: atom=_NET_ACTIVE_WINDOW(340)
exwm-input--on-buffer-list-update: current-buffer=#<buffer *terminal*> selected-window=#<window 13 on *terminal*>
exwm-layout--refresh: frame=#<frame *Minibuf-1* 0x4b280b0>
exwm-layout--refresh-workspace: Refresh workspace #<frame *Minibuf-1* 0x4b280b0>
exwm-layout--set-client-list-stacking:
exwm-input--on-buffer-list-update: current-buffer=#<buffer *terminal*> selected-window=#<window 13 on *terminal*>
exwm-layout--refresh: frame=#<frame *Minibuf-1* 0x4b280b0>
exwm-layout--refresh-workspace: Refresh workspace #<frame *Minibuf-1* 0x4b280b0>
exwm-layout--show: Show #x1200003 in #<window 13 on Firefox>
exwm--set-geometry: Setting #x1200003 to 960x1030+0+0
exwm-layout--set-state: id=#x1200003
exwm-layout--set-client-list-stacking:
exwm-input--on-buffer-list-update: current-buffer=#<buffer Firefox> selected-window=#<window 13 on Firefox>
exwm-input--on-buffer-list-update: current-buffer=#<buffer *terminal*> selected-window=#<window 5 on *terminal*>
exwm-manage--on-MapNotify: id=#x1200003
exwm--on-PropertyNotify: atom=WM_STATE(431)
exwm--on-PropertyNotify: Unhandled: WM_STATE(431)
exwm-input--on-PropertyNotify:
exwm-input--update-focus: focus-window=#<window 5 on *terminal*> focus-buffer=*terminal*
exwm-input--on-buffer-list-update: current-buffer=#<buffer *Minibuf-1*> selected-window=#<window 4 on *Minibuf-1*>
exwm-layout--on-minibuffer-setup:
exwm-input--update-focus: focus-window=#<window 4 on *Minibuf-1*> focus-buffer= *Minibuf-1*
exwm-input--update-focus: Focus on #<window 4 on *Minibuf-1*>
exwm-input--set-active-window:
exwm--on-ClientMessage: atom=_NET_ACTIVE_WINDOW(340)
exwm-input--on-buffer-list-update: current-buffer=#<buffer Firefox> selected-window=#<window 13 on Firefox>
exwm-layout--refresh: frame=#<frame *Minibuf-1* 0x4b280b0>
exwm-layout--refresh-workspace: Refresh workspace #<frame *Minibuf-1* 0x4b280b0>
exwm-layout--show: Show #x1200003 in #<window 13 on Firefox>
exwm--set-geometry: Setting #x1200003 to 960x1030+0+0
exwm-layout--set-state: id=#x1200003
exwm-layout--set-client-list-stacking: @emiljoha Unfortunately I was not able to reproduce the problem according to your recipe. Nevertheless I found a case where a *temp* buffer can cause the problem. I've pushed a fix (a1cf0d9b85e1d1d4f3b50a9d51980688b7b816df). Please check if you can reproduce the problem with it.
TsarFox
commented
5 years ago Hi, I've got an issue that I believe may be related. If I have two or more X windows shown at the same time, focus doesn't transfer when I use the windmove commands or other-window. If I windmove again to a non-existent window (raising that "No window left from selected window" error), focus is updated.
I've attached a log file of the following situation:
kitty window on the left.windmove-left to select the kitty window.windmove-right to select the Firefox window.ch11ng
commented
5 years ago @TsarFox From your debug log I noticed the input focus always stayed on Firefox so this is a different issue and perhaps caused by some unusual config. But anyway:
windmove commands? It seems you've made some keybindings.mouse-autoselect-window or focus-follows-mouse turned on?TsarFox
commented
5 years ago @TsarFox From your debug log I noticed the input focus always stayed on Firefox so this is a different issue and perhaps caused by some unusual config. But anyway:
Ah, okay. I can open another issue if necessary.
* How do you invoke the `windmove` commands? It seems you've made some keybindings.
;; I have some wrapper functions for another machine of mine that aren't defined on my laptop.
(when (and (not (fboundp #'my-windmove-left))
(not (fboundp #'my-windmove-right)))
(defalias #'my-windmove-left #'windmove-left)
(defalias #'my-windmove-right #'windmove-right))
(setq exwm-input-global-keys
...
([?\s-a] . my-windmove-left)
([?\s-d] . my-windmove-right)
([?\s-w] . windmove-up)
([?\s-s] . windmove-down)
...* Do you have things like `mouse-autoselect-window` or `focus-follows-mouse` turned on?
No, both are nil.
ch11ng
commented
5 years ago @TsarFox Perhaps you had them working in char-mode? What if putting them in line-mode and avoiding switching window with global keys?
TsarFox
commented
5 years ago @TsarFox Perhaps you had them working in char-mode? What if putting them in line-mode and avoiding switching window with global keys?
Same behavior with both windows in line-mode, and the issue persists even when invoking other-window from execute-extended-command with M-x.
ch11ng
commented
5 years ago @TsarFox I can confirm windmove works fine here. It does no magic but calls select-window in the end so I can't see why it shouldn't work. Please check your configuration, perhaps by disabling some features, to see if there is anything preventing EXWM from updating input focus.
TsarFox
commented
5 years ago I spent this morning doing some init.el bisecting and discovered that the issue was from an :eval form I had foolishly put in my mode-line-format. Whoops. Sorry about that.
emiljoha
commented
5 years ago @ch11ng Sorry for being so slow. Life happened...
Unfortunately I can still reproduce the issue on a1cf0d9 and on master cb96078.
emiljoha
commented
5 years ago @ch11ng Lets see if I can make the steps to reproduce even better so that you can reproduce it.
Checkout master (cb96078) of exwm, and master "599ef70 Add timestamps to XELB debug logs" of xelb.
Have this as the only content of ~/.emacs
(add-to-list 'load-path "~/.emacs.d/xelb/")
(add-to-list 'load-path "~/.emacs.d/exwm/")
(require 'exwm)
(require 'exwm-config)
(exwm-config-default)reboot computer.
Open firefox.
(start-process-shell-command "firefox" nil "firefox")Run the following code.
(term "/bin/bash")
(exwm-workspace-switch-create 1)
(switch-to-buffer "*terminal*")
(exwm-workspace-switch-create 0)
(split-window-right)
(other-window 1)
(switch-to-buffer "*scratch*")
(other-window 1)
(switch-to-buffer "Firefox")Test to write in the Firefox buffer, it will work fine.
Switch to buffer with the code in step 5 and run it once again.
Firefox buffer is read only.
ch11ng
commented
5 years ago @emiljoha Thanks for the recipe but perhaps more details are required (sorry but I failed to reproduce it again):
emiljoha
commented
5 years ago @ch11ng Thank you for taking the time to try and reproduce this issue. Maybe it is not possible to reproduce on your system. What distro are you running? I am running a openSUSE TW.
Side Note: M-x read-only-mode also make the buffer not read-only.
ch11ng
commented
5 years ago @emiljoha I'm on Debian Sid but I don't use the Emacs or any Elisp package shipped with my distro. Usually I build and develop on the master branch, but I also keep builds of stable branches down to emacs-24 for testing purpose. If you're unsure whether there is any package installed by your distro, you may simply start Emacs with the --no-site-file and --no-site-lisp options.
Also, could you prepare debug logs with (exwm-debug)? They may reveal something.
Side Note:
M-x read-only-modealso make the buffer not read-only.
exwm-mode internally enables read-only-mode. This basically revert that but doesn't change the fact that the input focus is wrong.
emiljoha
commented
5 years ago @ch11ng I hope this debug output can help.
ch11ng
commented
5 years ago @emiljoha Not sure if the debug output is incomplete or you went with another sort of test but I cannot find any log for exwm-workspace-switch-create. Did you notice the workspace switched?
shlevy
commented
5 years ago Sorry if this is already answered up-thread, I didn't read through everything... I'm getting this a lot with firefox, is there any workaround? Or would a newer version fix it?
ch11ng
commented
5 years ago @shlevy If you can reproduce this problem reliably, please show your recipe, turn on exwm-debug and upload the debug logs. In my understanding this probably has nothing to do with a specific application.
WJCFerguson
commented
5 years ago I suffer badly from this problem, but I haven't yet got a reliable recipe to reproduce. I do use windmove (that I see mentioned here), and I have suspicions it's related to, or at least frequently triggerd by, hot-plugging monitors, possibly while having buffers open using (Edit: nope - just had it happen with zero TRAMP activity).TRAMP (though my exwm-randr-screen-change-hook function first sets default-directory to "/").
When it happens, I can sometimes temporarily clear it by just moving to another window and back. Mostly it'll clear if I split the exwm-mode window and then undo that. It doesn't seem to happen if I select the window using the mouse. But ... the behavior varies(!), so it's very hard to nail down.
It seems to happen at various severities. Sometimes just moving to another window in the frame and back to the X window clears it, sometimes the window must be split, and the behavior is consistent over an instance of it occurring.
ch11ng
commented
5 years ago I've just reread the whole thread and would like to make a summary of what had been discussed in case someone else comes across the same problem.
debug-on-error so you won't miss anything going wrong.buffer-list-update-hook to correctly set input focus. If you accidentally have it tampered (like in https://github.com/ch11ng/exwm/issues/585#issuecomment-518393883) you are likely to experience this problem. You may want to place a message at the head of exwm-input--on-buffer-list-update to verify it actually works.WJCFerguson
commented
5 years ago Re note 1: "recovering" from the problem - firstly it varies. sometimes just switching to another window works, sometimes switching workspaces, sometimes only splitting the window works, however, none of these fully "recover", it just makes it writable until/unless I move away again. Once I have had the problem, I have never had it go away until I exit the exwm session.
Re note 4: it may be relevant that I have a function in buffer-list-update-hook to set the header-line-format, and my header-line-format had an :eval element in there. I've modified my function to remove the :eval and make it more static, and haven't suffered from the problem yet (Edit: but it still occurred) I notice someone above mentioned similar about their mode-line-format, so this could be relevant, but not enough time has passed to tell me for sure if I've now avoided the problem (Edit: I haven't).
ch11ng
commented
5 years ago [...] Once I have had the problem, I have never had it go away until I exit the exwm session.
Fortunately this seems consistently reproducible so perhaps you can get more details with exwm-debug?
Re note 4: it may be relevant that I have a function in
buffer-list-update-hookto set theheader-line-format, [...]
I wonder if exwm-input--on-buffer-list-update is still the head of buffer-list-update-hook in your case. If not it may not work correctly. Otherwise it's worth checking if the log exwm-input--update-focus: focus-window=#<window ...> focus-buffer=... is present so we can see if it fails to work in some edge cases, or there is a timing issue.
ch11ng
commented
4 years ago For those still experience this issue, please give 6a3e9b2c64d644ed468684a2a867c535e50ef66a a try. I've literally removed all checks for buffer-list-update-hook so no event should be missed.
WJCFerguson
commented
4 years ago I have not seen the issue since updating to 6a3e9b2.
It's a rather unpredictable issue, but nevertheless I'd have expected to see it by now.
altnometer
commented
3 years ago When Emacs started without dbus-launch, (:eval (funcall battery-status-function)) in mode-line-format causes the error when I switch to a desktop displaying qutebrowser buffer. But only for a few seconds. After that, it seems to work normally.
The error may happen even with with dbus-launch if there is no relevant packages that provides "org.freedesktop.UPower" service.
Necronian
commented
3 years ago
(:eval (funcall battery-status-function))inmode-line-formatcauses the error
I have had this buffer read-only problem with X applications for a while now. There was a similar function in my mode line format. After removing it I haven't had any issues, it's only been about a day but I would have expected something by now.
shlevy
commented
3 years ago I periodically have this issue and have display-battery-mode in my .emacs
timor
commented
3 years ago Using SpacemacsOS, I started having this problem lately. Concerns either browser windows (e.g. Vivaldi), or the graphical Listener of the Factor language (Don't have tested this with too many other applications, though). I tried to debug this systematically, but comparing logs of working and non-working states/transitions didn't really enlighten me. I noted down the results, including the Debug output of working/non-working cases here.
I got the application running one time successfully. After several reboots, now I can't use it anymore.
The application (sonic-pi) reports some errors (jack) in it's log, though I doubt them being related to the exwm buffer read-only state (bottom left in screenshot below)
Remark Can confirm that the application itself is ok. Disabled emacs and enabled xterm for testing.
.xinitrc excerpt