Fail to start when no emacsclient frames are open

[io12]

If there are no open emacsclient frames, then running

emacsclient --eval "(emacs-everywhere)"

outputs

*ERROR*: Wrong type argument: stringp, nil

When there is at least one emacsclient frame open, this problem doesn't happen.

I am using Linux and Emacs 27.2.

[tecosaur]

I found an issue like this occurred when I was caching environmental variables and the XAUTHORITY was wrong. Could something like that be happening here?

[io12]

I don't really know. I can't figure out how to get a backtrace because all the methods for getting backtraces I know about require that a frame is open.

[ibrahimmuftee]

I am also having this issue, and I am on Linux, Doom Emacs, and Emacs 27.2

[dadair-ca]

Also having this issue

[io12]

I looked into this again and I think I found the root cause of the issue. Running emacsclient --eval '(getenv "DISPLAY")' prints nil with no emacsclient frames open, but :0 when an emacsclient frame is open. This issue seems to happen in i3 but not GNOME. I'm not really sure why this is happening, though.

[dadair-ca]

I looked into this again and I think I found the root cause of the issue. Running emacsclient --eval '(getenv "DISPLAY")' prints nil with no emacsclient frames open, but :0 when an emacsclient frame is open. This issue seems to happen in i3 but not GNOME. I'm not really sure why this is happening, though.

I'm experiencing this on Fedora 34 with Gnome.

[io12]

Restarting the systemd user service I use for Emacs server with systemctl restart --user emacs.service also seems to fix it, and I think that normally starts at login, so maybe Emacs server is starting after Xorg and that's preventing it from having DISPLAY set? That doesn't really explain why opening an emacsclient frame fixes it.

Either way, this seems to work:

emacsclient --eval "(setenv \"DISPLAY\" \"$DISPLAY\")" --eval '(emacs-everywhere)'

[io12]

I'm experiencing this on Fedora 34 with Gnome.

Actually I am too after a reboot. I guess I restarted Emacs since the last reboot and assumed it always worked in GNOME.

[tecosaur]

I'm beginning to feel like an FAQ / Fixes for common issues section would be a good addition to the readme. Or maybe a GH wiki page that's publically editable?

[dadair-ca]

Any luck @io12? What's interesting is I've had an emacs-everywhere popup work randomly from other programs, but any attempt to bind it to a key fails, and even getting a result back from any emacsclient --eval .. call hands in the terminal

[dadair-ca]

It appears there's an issue with xdotool getactivewindow called from the emacs-everywhere-app-info-linux function:

$ xdotool getactivewindow
XGetWindowProperty[_NET_ACTIVE_WINDOW] failed (code=1)
xdo_get_active_window reported an error

[tecosaur]

Interesting, thanks for digging that up. I wonder what's going on with that...

[dadair-ca]

So far I think this is related to Wayland, doesn't look like xdotool and it play well together

[Atreyagaurav]

Same issue on Arch + i3 setup.

I have the keybinding like this: bindsym $mod+m exec emacsclient --eval '(emacs-everywhere)'

Even after doing sytemclt restart service or adding --eval "(setenv \"DISPLAY\" \"$DISPLAY\")" didn't help here. Though it runs on the terminal, does show the contents on the primary, but doesn't apply the edits.

[furkanusta]

I've found this: https://dev.suckless.narkive.com/Pr5qxYcw/xid-of-a-current-window

Replacing xdotool getactivewindow with xdotool getwindowfocus in emacs-everywhere-app-info-linux makes it open now, though I am not sure if they are equivalent.

It still cannot paste into the text-box but leaves it in the clipboard which is good enough for me

Update: ydotool seems to support key command and it works for pasting. However, it requires a daemon to be running and sudo access while pasting the text, which makes it not as seamless.

[tecosaur]

Looking at man xdotool I see:

getactivewindow
    Output the current active window. This command is often more reliable than getwindowfocus. The result
    is saved to the window stack. See "WINDOW STACK" for more details.

[bevsxyz]

https://github.com/psibi/emacs-everywhere/issues/2#issuecomment-997234091

I need to find a working solution. I use gnome Wayland and am not planning to go back to Xorg. wtype seems to be packaged for all major distros. I am guessing it doesn't need access to /dev/uinput like ydotool.

[tecosaur]

@bevsxyz see #50.

[tecosaur]

Oh, you commented there at the same(ish) time. Oh well :stuck_out_tongue:

[bevsxyz]

Found that one later, when looking for closed issues😅

[GiulioCentorame]

I don't know if this can help, but I am on Fedora 36 Wayland and vim-anywhere seems to work fine, while emacs-anywhere doesn't

[azzamsa]

So, the current status of /tecosaur/emacs-everywhere/ in Waylad is not supported? Or anyone have a working installations in Wayland?

[ntrp]

So, the current status of /tecosaur/emacs-everywhere/ in Waylad is not supported? Or anyone have a working installations in Wayland?

Not working, I don't see a chance of it working if is not specifically implemented since it uses heavily X11 specific tools.

[g-hanwen]

It might be slightly off-topic, but here's a potentially related clue. Recently, when I was trying to add Windows support to emacs-everywhere, I encountered a similar issue. In fact, the issue can be reproduced without using emacs-everywhere on Windows with the following code:

(defun test ()
  (apply #'call-process "emacsclient" nil 0 nil
           '("-c")))

and executing emacsclient -e "(test)" in shell.

However, when I replaced call-process with a call to the same command using w32-shell-execute, the issue no longer occurred. This suggests that the problem may be related to the encoding or environment of the newly created process.