Open gramanas opened 2 years ago
Can't reproduce on recent Emacs version:
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.6)
of 2022-05-10
C-g
close mini-frame as expected.
Under Gnome Shell 42.1
I suffer from the same issue, GNU Emacs 29.0.50 (build 1, amd64-portbld-freebsd14.0, GTK+ Version 3.24.33, cairo version 1.17.4). Running under wayfire (wlroots wayland)
@gramanas Are you on wayland as well?
I am also experiencing the same behavior under NixOS (22.05) with Wayland. When I try to quit the mini-frame a mini-buffer pops out in a second window.
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.16.0)
Same configuration, I also have the issue. If it works on Xorg but not on Wayland, maybe the issue comes from emacs source ? Has a bug been reported there ?
Same issue, this makes the package unusable for me :(
Found the solution
(setq mini-frame-detach-on-hide nil)
(setq mini-frame-detach-on-hide nil)
This does solve the second window problem! However, In my case, after quiting minibuffer, all the keyboard input into emacs is not responded. Mouse action works as usual.
btw I'm using emacs 29.1 with jit (native-compile), aot, trampolines and pgtk enabled on hyprland
Edit: I then tested it on emacs 29.1 with jit, aot, trampolines without pgtk, and it just works flawlessly. So this is the problem of pgtk.
Edit2: I then found out that on pgtk, after quiting minibuffer, pressing direction keys or tab makes emacs respond to my keyboard input again. But I don't know why it only respond to direction keys and the tab.
@A7R7 This gives us more information to work with, thanks!
The issue probably stems from the function x-focus-frame
which is used in select-frame-set-input-focus
and then in the mini-frame package. I can reproduce the error with emacs -Q
(emacs -Q
then (make-frame) (x-focus-frame (get-other-frame))
won't work).
So the issue is in Emacs source code pgtk implementation, not with the package itself. I'll report an error and indicate it there in an edit. In the meantime, if you use sway and the package sway.el, you can use the following workaround (changing the frame-title-format ensures there's a unique name for each frame) :
(defalias 'x-focus-frame 'sway--x-focus-frame)
(setq frame-title-format '("%b — GNU Emacs [" (:eval (frame-parameter (selected-frame) 'window-id)) "]"))
@gramanas @amilonop @GeorgesAlkhouri @steewbsd @muffinmad I'm pretty confident this last workaround should work if you use sway.
Glad to hear that! But I use hyprland btw
@A7R7 This gives us more information to work with, thanks!
The issue probably stems from the function
x-focus-frame
which is used inselect-frame-set-input-focus
and then in the mini-frame package. I can reproduce the error withemacs -Q
(emacs -Q
then(make-frame) (x-focus-frame (get-other-frame))
won't work).So the issue is in Emacs source code pgtk implementation, not with the package itself. I'll report an error and indicate it there in an edit. In the meantime, if you use sway and the package sway.el, you can use the following workaround (changing the frame-title-format ensures there's a unique name for each frame) :
(defalias 'x-focus-frame 'sway--x-focus-frame) (setq frame-title-format '("%b — GNU Emacs [" (:eval (frame-parameter (selected-frame) 'window-id)) "]"))
Just chipping in that I've tried the fix but the function doesn't seem to be defined on Hyprland
Just to be clear @ceuk , the function is defined in the package https://github.com/thblt/sway.el which I haven't tried on Hyprland (and will probably depend on Hyprland API), but I can't help you with that.
Emacs version:
GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4) of 2022-04-29
Steps to Reproduce:
emacs -Q
M-x
C-g
--> At this point the minibuffer should close, no longer accepting input and the focus returned to the*scratch*
buffer. Instead it remains there with a[Quit]
text added. Any input at this point will go into the minibuffer, AnotherC-g
is required to actually quit.