Which desktop environment do you use?

I haven't use emacs-eaf aur package, I can not guarantee it will be able to work.

That's right, emacs-aur is made possible by the community, we personally do not have the chance to use it yet.

I also installed previously manually, so AUR not the isue.

Using i3 as my wm. I will reboot to XFCE and see if it works.

Okay - works when I use XFCE, so I am guessing there is a problem with i3. Happy to provide any other info I can. Would love to get this working as it's something I anticipate using a great deal.

Great to hear it works at least on xfce for you. The challange we have right now to support EAF on more WM/DEs and platforms is that we don't use them ourselves. It would be best if you can play around with EAF on i3 to get familiar with it and contribute :)

I am afraid I would not even know where to begin. I know some elisp and that is about it as far as programming goes. Hopefully someone else will see this and jump on it. I'll play around with it if I get any ideas though. This looks like an amazing package and thank you for putting it out there.

I search emacs-china forum, when you move cursor out of EAF area, i3wm will focus EAF buffer.

I think it's a bug of i3wm on focus handle.

Tried it and that makes it work. Not a huge inconvenience since I rarely use the mouse anyway. Thank you for reporting back.

It's bug of i3wm, not EAF, close issue.

Your app not working in i3wm doesn't mean it is a bug in i3wm

@legalnonsense i3 have many dirty patch to modify X11 reparent protocol, make EAF can't reparent Qt window with standard X11 protocol.

Anyway commuity developer commit workaround patch 2ff25cd to fix this issue.

i think I've found part of the problem. While reading EAF's source, I found this line:

(defcustom eaf-wm-focus-fix-wms `("i3")
  "Set mouse cursor to frame bottom in these wms, to make EAF receive input event.
Add $DESKTOP_SESSION environment variable to this list."
  :type 'list
  :group 'eaf)

By changing the value of eaf-wm-focus-fix-wms to `(), I was able to restore keybinding functionality so long as I hover over the modeline for the frame. It appears as though the issue is linked to said variable.

Also, it does appear that it is indeed a bug in your code, not i3.

EDIT: After some further testing, the nil set does nothing nor does the fix it causes. I'll look into it further. A suggestion may be to handle the keybindings on the Python side, since it seems to handle keyboard inputs perfectly.

handle the keybindings on the Python side, since it seems to handle keyboard inputs perfectly.

Python side does not handle keyboard inputs by design, so it never able to handle keyboard inputs perfectly.

Please edit your comment to clarify what exactly is different by modifying the eaf-wm-focus-fix-wms variable.

Is it worth adding a notice to the README about this? I use i3 and was confused why EAF was having focusing issues, but it was hard to find this GitHub issue since it's closed.

It's worth reopening since 2ff25cd clearly did not fix this issue.

As a sanity check, what is the value of echo $DESKTOP_SESSION on your systems? Is it i3?

DESKTOP_SESSION is empty for me. It might only apply to desktop environments and not WMs like i3. I can set DESKTOP_SESSION manually tomorrow to see if the unfocusing patch works.

Has anyone tested this on any other tiling WMs? Perhaps it is caused by the tiling nature of I3. Also to note, the code that I sent appears to never trigger, as the warning text never appeared in messages for the tool it uses even when missing. Finally, a better way to detect I3 would be to try to send the window manager a message (like the one used for logging out). I know there is a command for it but I can’t remember it’s name. That would also cover forks like i3-gaps.

Has anyone tested this on any other tiling WMs? Perhaps it is caused by the tiling nature of I3.

I tested with dwm just now, and it seems to work. This is probably more of an i3 problem than a tiling window manager problem.

Also, I tried hardcoding DESKTOP_SESSION to test if the i3 fix works otherwise. It definitely helps a lot, but if the browser window manages to grab focus (through mouse clicks, or because it was just opened), it doesn't ever release the focus and the problem still happens.

I think it's i3 problem that not follow WM protocol standard, and many i3 believer think it's a bug of EAF.

The "move to minibuffer" patch is hacking way.

I believe right way is i3 fix focus problem, or use i3 focus message instead hacking patch.

Close this issue since EAF can't adaptable to all window managers, sorry.

If this is a bug in i3, any ideas which part of the i3 code has the bug?

Also, if this issue is closed, it might make sense to add that EAF doesn't work with i3 to the README. When I first tried EAF, I couldn't easily find this issue since it was closed, so I was confused why it wasn't working.

Let's keep it open, I don't see any reason for EAF not to adapt to i3 in the future, given i3's popularity. Hopefully someone from the community who uses i3 can help. 🙂

I can still reproduce the issue with the new version.

Also, the Alt+Tab patch seems to create another issue in i3. When I have two workspaces open with emacs in both the first and second workspace, pressing Alt or Meta switches to the second workspace.

Well, I have disable Alt+Tab patch when EAF found it running under i3.

It appears that keys are handled differently depending on which window has focus. I suspect it is not WM specific (I happen to be using i3 as others in this thread). In i3 the window usually gains focus when you hover it. I wonder if you'd be able to reproduce some of the same issues in other WMs, if you manage to focus the window displaying the QT5 application. Perhaps some other mechanism is preventing this from happening when you click it?

I noticed a thing which I think is relevant here and may help investigation: If I open a website in EAF and focus an input field. If I then hit escape I expect the input field to "blur" (web parlance for loose focus). This only happens, however, if my mouse is over the EAF buffer displaying the browser window. If I mouse over another buffer in my Emacs window the text "<es" is inserted into the input field. Very strange... The unfortunate thing about this is, that it if you move your mouse away from the EAF window you can use the EAF keybindings but not the QT5 key bindings and vice versa.

I post newest patch: 95e1de9

I found the following law happend in KDE, i3 and qtile:

1. If the mouse is in the EAF window area, then switch back to Emacs, Emacs cannot get the input focus. (Cause by QEvent.ShortcutOverride)
2. If the mouse is out of EAF window area, then switch back to Emacs, Emacs can get the input focus.

So newest patch fix focus by below logic:

1. Call elisp function eaf-move-mouse-to-frame-bottom when switch back to Emacs. (Test with QTile)
2. Or use wmctrl activate on Emacs window after Alt + Tab operation. (Test with KDE)

I have test QTile, can you guys help me confirm this fix?
Thanks!

Thanks!
It does not work under Sway, but this might be linked to Wayland support: #449

Thanks!
It does not work under Sway, but this might be linked to Wayland support: #449

can you help test i3?

I just installed i3 to try it out. Unfortunately, it doesn't work.
Let me know if I can be of any help.

I just installed i3 to try it out. Unfortunately, it doesn't work.
Let me know if I can be of any help.

I see, I just install i3 and test it, not work because DESKTOP_SESSION should be /usr/share/xsessions/i3, is not i3.

I have post new patch to fix this:
c40bd2a

I believe i3 will works well now.

Sway maybe casue by Wayland native technology, EAF has support XWayland.

Please re-open this issue if anyone found new bug on i3.

It doesn't seem to work here under i3, but maybe there's something wrong with my config.

It doesn't seem to work here under i3, but maybe there's something wrong with my config.

i test standard i3 with default config

I can also still reproduce the bug.

I can also still reproduce the bug.

Are you on i3? Can you paste your $DESKTOP_SESSION value?

Are you on i3? Can you paste your $DESKTOP_SESSION value?

I'm on i3 and DESKTOP_SESSION is not a set environment variable.

Can you set your DESKTOP_SESSION to string "i3" and try again?

Are you on i3? Can you paste your $DESKTOP_SESSION value?

I'm on i3 and DESKTOP_SESSION is not a set environment variable.

What's your value of XDG_CURRENT_DESKTOP ?

What's your value of XDG_CURRENT_DESKTOP ?

That's also not set.

Can you set your DESKTOP_SESSION to string "i3" and try again?

This works much better than EAF has ever worked on i3 before! The cursor jumps to the bottom-left corner, which isn't ideal, but at least the workaround works.

About how to test if i3 is running, you could check if there's a process called i3 running or check if xprop -root contains _NET_WM_NAME(UTF8_STRING) = "i3".

@io12 I see, I believe that the previous I3 users are because the DESKTOP_SESSION variables are not set.

Anyway, I post newest commit c5fdf0b

That use command `wmctrl -m' get desktop name dynamically, not need set DESKTOP_SESSION anymore.

I believe i3 will works if user install wmctrl.

@io12 I see, I believe that the previous I3 users are because the DESKTOP_SESSION variables are not set.

I remember manually setting DESKTOP_SESSION a lot earlier in the thread and it not working, so it must have been some recent change. #237 (comment)

I believe i3 will works if user install wmctrl.

Here's my wmctrl -m output:

Name: i3
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

@io12 I see, I believe that the previous I3 users are because the DESKTOP_SESSION variables are not set.

I remember manually setting DESKTOP_SESSION a lot earlier in the thread and it not working, so it must have been some recent change. #237 (comment)

I believe i3 will works if user install wmctrl.

Here's my wmctrl -m output:

Name: i3
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

Please update to newest version, if you has install wmctrl and xdotool, EAF should work out of box now.

Please update to newest version, if you has install wmctrl and xdotool, EAF should work out of box now.

It works now. Thank you!

I've been having the same issue using something more exotic and I'm happy to open a separate issue if that is preferred. I run emacs as a daemon on a remote server, launch emacsclient on a display, and access that display through the utility xpra (for now it's just the single emacs window) from my Windows computer. I have installed wmctrl and xdotool both installed. Here's my wmctrl -m output:

Name: Xpra
Class: N/A
PID: 543
Window manager's "showing the desktop" mode: N/A

I can input keystrokes to the eaf window (for example a PDF) only when I click in the minibuffer first. Clicking around in the eaf window directly will then again result in no keystrokes being detected.

I've been having the same issue using something more exotic and I'm happy to open a separate issue if that is preferred. I run emacs as a daemon on a remote server, launch emacsclient on a display, and access that display through the utility xpra (for now it's just the single emacs window) from my Windows computer. I have installed wmctrl and xdotool both installed. Here's my wmctrl -m output:

Name: Xpra
Class: N/A
PID: 543
Window manager's "showing the desktop" mode: N/A

I can input keystrokes to the eaf window (for example a PDF) only when I click in the minibuffer first. Clicking around in the eaf window directly will then again result in no keystrokes being detected.

can you add Xpra to list eaf-wm-focus-fix-wms, and try again?

That seems to have fixed it, thank you very much.

@manateelazycat The mouse cursor movement hack may defer users that need to use the mouse sometimes, I would suggest a better solution:

If my understanding is correct, eaf includes 2 part, the gui as we see and the underlying emacs frame, if you can make the emacs frame send fake keys to the gui part, sure you can let the gui send keys to emacs.

When the gui receives a keyboard event, do a check to see if the mouse pointer is above the gui, if so, the key must have not been processed by emacs, let the gui part send the key to emacs, emacs will look up the keybinding table, and execute the corresponding commands,.

If that command is to send a modified key event, let the command also send a suppress signal that suppress the key event origin check to the gui, and tell the gui that please don't send the key back again. If the mouse pointer is at the corner, or any where the window manager won't misbehave, let the gui just accept the key and don't bother emacs.

If that command has nothing to do with key event, no further action is needed.

I hope someone can get this to work and stop the mouse jumping madness.

@manateelazycat The mouse cursor movement hack may defer users that need to use the mouse sometimes, I would suggest a better solution:

If my understanding is correct, eaf includes 2 part, the gui as we see and the underlying emacs frame, if you can make the emacs frame send fake keys to the gui part, sure you can let the gui send keys to emacs.

When the gui receives a keyboard event, do a check to see if the mouse pointer is above the gui, if so, the key must have not been processed by emacs, let the gui part send the key to emacs, emacs will look up the keybinding table, and execute the corresponding commands,.

If that command is to send a modified key event, let the command also send a suppress signal that suppress the key event origin check to the gui, and tell the gui that please don't send the key back again. If the mouse pointer is at the corner, or any where the window manager won't misbehave, let the gui just accept the key and don't bother emacs.

If that command has nothing to do with key event, no further action is needed.

I hope someone can get this to work and stop the mouse jumping madness.

NO，reason is focus problem of wm implemention