Open walseb opened 1 year ago
I'm sorry, I have zero knowledge of EXWM and have no idea why its buffer need to be killed asynchronously. I think it would be very hard for me to help with this.
It appears that when selecting and killing multiple EXWM buffers using embark-act-all, only the first selected buffer gets killed.
Does EXWM rename other buffers when you kill one of them? If so, that's what causes the second and subsequent kills to miss: embark is still trying to kill the old names. This can be solved as in #651.
That's interesting, I don't know.
I think the issue in the second problem I mentioned is that EXWM buffers are resilient to kill-buffer in that they don't block the thread until the buffer is completely killed unlike normal emacs buffers, if my understanding of kill-buffer is correct.
I found the issue I was talking about: https://github.com/ch11ng/exwm/issues/576
It seems highly relevant.
On Mon, Jul 17, 2023, 13:10 Omar Antolín Camarena @.***> wrote:
It appears that when selecting and killing multiple EXWM buffers using embark-act-all, only the first selected buffer gets killed.
Does EXWM rename other buffers when you kill one of them? If so, that's what causes the second and subsequent kills to miss: embark is still trying to kill the old names. This can be solved as in #651 https://github.com/oantolin/embark/issues/651.
— Reply to this email directly, view it on GitHub https://github.com/oantolin/embark/issues/652#issuecomment-1637316577, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAV3U3ULXFDFRAJGEGEZMJTXQSULXANCNFSM6AAAAAA2MG7NSU . You are receiving this because you authored the thread.Message ID: @.***>
It seems one needs a special EXWM kill command which can be bound as kill action in the embark-buffer-map? See https://github.com/ch11ng/exwm/issues/576#issuecomment-543201407. In any case, this should not be part of Embark but could be documented in the wiki.
It seems one needs a special EXWM kill command which can be bound as kill action in the embark-buffer-map? See ch11ng/exwm#576 (comment). In any case, this should not be part of Embark but could be documented in the wiki.
One issue with that function is that it appears to kill the root process. I tried it just now on a Firefox window, and it killed all other Firefox windows as well. It also appears to force kill the minibuffer, despite my embark-quit-after-action
settings.
One solution is to just run kill-buffer
after exiting the embark act, instead of during it. It then works for killing multiple buffers, however, the minibuffer closes after every kill because of some reason.
(defun my/kill-buffer (b)
(interactive "bBuffer: ")
(let ((buf (get-buffer b)))
(if (eq (buffer-local-value 'major-mode buf) 'exwm-mode)
;; There were some issues with running the timer with nil.
(run-with-timer 0.01 nil
(lambda (buf)
(kill-buffer buf)
(embark--restart)) buf)
(kill-buffer buf))))
(define-key embark-buffer-map (kbd "C-k") #'my/kill-buffer)
Does anyone have ideas as for why the minibuffer closes after every kill?
Thanks for any help!
Hello!
It appears that when selecting and killing multiple EXWM buffers using
embark-act-all
, only the first selected buffer gets killed.Is there any way I can debug this further? No backtrace is triggered when running it.
There is also another problem that's probably related. When killing EXWM buffers using
embark-act
, and havingembark-quit-after-action
set so that killing buffers doesn't quit embark, EXWM buffers stay in the buffer list after killing them. I believe this is because they can't be killed synchronously like normal buffers.I think this was discussed on the EXWM GitHub page a while back, I will see if I can find it later. I believe it was concluded that other applications like ivy and helm should handle the asynchronicity of EXWM buffers.
Thoughts?