emacs-mini-frame icon indicating copy to clipboard operation
emacs-mini-frame copied to clipboard

`C-g` doesn't quit minibuffer

Open gramanas opened this issue 2 years ago • 13 comments

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

(package-initialize)
(require 'mini-frame)
(mini-frame-mode)

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, Another C-g is required to actually quit.

gramanas avatar May 08 '22 14:05 gramanas

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

muffinmad avatar May 10 '22 14:05 muffinmad

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)

steewbsd avatar May 17 '22 15:05 steewbsd

@gramanas Are you on wayland as well?

muffinmad avatar May 17 '22 15:05 muffinmad

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.

image


GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.16.0)

GeorgesAlkhouri avatar Jul 10 '22 17:07 GeorgesAlkhouri

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 ?

nicolas-graves avatar Aug 31 '22 12:08 nicolas-graves

Same issue, this makes the package unusable for me :(

amilonop avatar Dec 04 '22 11:12 amilonop

Found the solution

(setq mini-frame-detach-on-hide nil)

amilonop avatar Dec 04 '22 11:12 amilonop

(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 avatar Aug 04 '23 01:08 A7R7

@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)) "]"))

nicolas-graves avatar Aug 09 '23 07:08 nicolas-graves

@gramanas @amilonop @GeorgesAlkhouri @steewbsd @muffinmad I'm pretty confident this last workaround should work if you use sway.

nicolas-graves avatar Aug 10 '23 06:08 nicolas-graves

Glad to hear that! But I use hyprland btw

A7R7 avatar Aug 10 '23 08:08 A7R7