emacsclient not functioning correctly

[jdtsmith]

I have linked:

/usr/local/bin/emacsclient -> /Applications/Emacs.app/Contents/MacOS/bin/emacsclient

The command:

% emacsclient -t 

(or --tty or -nw) should open a frame in the current tty. Instead, if Emacs.app is open and the server is running, it opens a new frame in the GUI, whether or not -t is passed. If, on the other hand, emacsclient is invoked first (running emacs in --daemon mode), as:

% emacsclient -a ""

(which in the background launches /Applications/Emacs.app/Contents/MacOS/Emacs --daemon=^J5,6^J) further calls to emacsclient to open a GUI frame do not function:

% emacsclient -c foo 

(opens a tty frame)

% emacsclient foo 
Waiting for Emacs... 

(hangs, no window opens)

It also seems to be impossible to have emacsclient open Emacs.app if the latter is not already running. I have had this setup (using emacsclient to go back and forth between GUI and TTY frames) working with vanilla Carbon Emacs.app (but it's been some time).

[railwaycat]

It's a known issue that multi-tty not supported in mac port. As developers words

The developer has no idea how to detach Emacs as a GUI application from Window Server or Dock without separating a GUI process (not thread) from the main Emacs (Lisp evaluator) process.

[Intensity]

@railwaycat can you clarify here? I'm confused because a vanilla build for OS X does seem to allow this functionality - I've confirmed that I can have a GUI frame and a tty attachment open to the very same Emacs process. @jdtsmith have you had any success getting this to work?

[i-am-the-slime]

I'm also interested in this.

[ylluminarious]

@railwaycat I am also confused as to why this is an issue at all. Why does the Mac Port not include functionality from the more basic GNUStep port?

In other words, it works in vanilla Emacs just fine; why not on the Mac Port?

[railwaycat]

@ylluminarious Because Mac port and Nextstep/GNUStep port are different implementations, they does not share (most of) the code base. As I know there are people working on merging these two ports, but so far they are still separated.

For questions about technical details, I suggest you get answer from the developer: [email protected]

[aiguofer]

In case anyone is interested, emacs-plus solves this issue for me. I can brew services start emacs-plus to start the server, then I can start emacsclient in the GUI or in the console. Also, tiling WMs like yabai are able to detect it correctly.

[jdtsmith]

Yes, but emacs-plus doesn't have all the nice features that bring people to this port (tab handling and tab-overview, swipe to change buffers, smooth scroll, etc.).

[aiguofer]

Ahh, I wasn't really aware of which features come with each of the many available emacs versions for Mac.

Working well with the WM and having the server work as expected with a variety of clients in either gui or tty are the only things I really care about (trying to match my Linux setup with i3). Hopefully, when others stumble upon this they can decide which features they prefer and have a potential solution. Who knows if this ever gets fixed I might give this a try!

[ylluminarious]

I forgot that I wrote an article about this some months ago, documenting how I fixed this issue. Perhaps it will fix this problem for others too.

[aiguofer]

Thanks @ylluminarious, tried it and your patches fix the multiple TTY support for me, but I'm still SOL on the GUI client. Without that, I'm still stuck with emacs-plus... and I've already found a few issues with it (mainly processes hanging, forcing me to C-g).

Btw, for anyone wanting to try this, it's easy to add to the formula with:

$ brew edit emacs-mac
# add the following lines somewhere in the formula before it builds
  patch do
    url "https://bitbucket.org/ylluminarious/emacs-mac-multi-tty/commits/6d23e90288d21546ed2551a7d14dec79ccb3dc13/raw"
  end

  patch do
    url "https://bitbucket.org/ylluminarious/emacs-mac-multi-tty/commits/08874543cb806d0c2dc7b6b5c0f5f92836b7671a/raw"
  end

[jdtsmith]

Excellent thanks @ylluminarious! @aiguofer I edited the brew as you suggested and it works well. The referenced bug is definitely present though: I'm allowed to close the last GUI window, and when I do, it immediately hangs with a beachball. The original emacs process and TTY window is just fine, though, so I can save work. But I can't create new GUI windows, and must Force-Quit the hung GUI process. Is this the behavior that the daemon you mentions solves?

[ylluminarious]

@aiguofer @jdtsmith Yes, sorry about that. The way I've worked around this issue is by using the mac-pseudo-daemon package which I mentioned in the article.

[jdtsmith]

This works for me! Command-Q doesn't quit but I can use the menu or dock icon. Thanks!

[ylluminarious]

@jdtsmith Perhaps you can bind Cmd-Q to save-buffers-kill-emacs? In any case, I'm glad it worked for you otherwise.

[jdtsmith]

@ylluminarious I explicitly don't do that because I use option for Meta, and Cmd is right next door, and Meta-Q is refill paragraph, so called very often... I should just learn to leave Emacs running with a hidden frame and not worry about it.

BTW, another awesome feature of emacs-mac is its tab support. I use Ido for switching between buffers, and have 'maybe-frame set for ido-default-buffer-method so it asks me if I want to hop to another frame showing that buffer (often on another Space). But if the "frame" is really just a tab in my current (mac) window, I'd rather just hop right to it, so:

  ;; If in a tab in this (mac) window, don't prompt for frame jump
  (advice-add 'ido-visit-buffer :around
	      (lambda (func buffer method &rest args)
		(when (eq method 'maybe-frame)
		  (if (bufferp buffer)
		      (setq buffer (buffer-name buffer)))
		  (let* ((frames (mac-frame-tab-group-property nil :frames))
			 (win (ido-buffer-window-other-frame buffer))
			 (frame (window-frame win)))
		    (if (memq frame frames)
			(setq method 'raise-frame))))
		(apply func buffer method args))
	      '((name . "ido-raise-tab-unprompted")))

[ylluminarious]

@jdtsmith Ah, I see. Got it. No worries, everyone has their own preferences. Personally I don't bind Cmd-Q to save-buffers-kill-emacs, but I use Cmd-Ctrl-Q instead.

Also you're right about tabs being a nifty feature. I don't use them enough. Your little snippet there might help me to start using them more often. Thanks!

[hummuscience]

@ylluminarious your fix only solved multiple terminal frames but not the "--create-frame" bug, right?

Not even starting GUI emacs -> "server-start" -> close GUI frame -> emacsclient -c works.

Any idea how to work around this?

[ylluminarious]

@Cumol I have no problems with emacsclient --create-frame when I use the mac-pseudo-daemon package which I mentioned above.

[hisnawi]

I have compiled emacs on Catalina but I am unable to start emacs in a GUI mode. It always starts in terminal mode (both emacs and emacsclient). Am I doing something wrong? Is the issue I am having related to this one? Any insight into this is highly appreciated.

[hummuscience]

@hisnawi it is probably unrelated.

I suspect that you are trying to use the in-built emacs and not the one installed by homebrew.

If you have linked emacs to your application folder, you can try to run that directly or use the executable in the package contents in the terminal.

Probably something like this: /Applications/Emacs.app/Contents/MacOS/Emacs

[hisnawi]

@Cumol Thanks for your response. I used this to install: brew install emacs-mac But I dont see emacs in the Applications directory. I only see that it installed in /usr/local/bin Did I miss something?

[hummuscience]

Try running emacs through the /usr/local/bin path instead of simply writing emacs in the terminal.

[hisnawi]

I reinstalled it and now it works fine. Thanks.

[ywwry66]

@ylluminarious You patch was recently merged to the formula in this repo so I tried it out. I am able to open X/tty frames using emacsclient -c and emacsclient -t, when the server is created by GUI emacs with (server-start). This is great. However, if I create the server with emacs --daemon or /Applications/Emacs.app/Contents/MacOS/Emacs --daemon, both emacsclient -c and emacsclient -t can only make tty frames, which makes it unusable. Ideally, I prefer using emacs --daemon because it runs totally in the background, and I can kill all frames without any problem. Do you think if that can be achieved? Thanks.

[ylluminarious]

@ywwry66 Sorry for the delayed response. I never run emacs --daemon anymore with this patch. Instead, I use a package called mac-pseudo-daemon. I wrote a blog article dealing with the nuances of this issue here: https://ylluminarious.github.io/2019/05/23/how-to-fix-the-emacs-mac-port-for-multi-tty-access/

[markgeejw]

Could I check that this is still not working even with multi-tty support when running emacs --daemon instead of (server-start)?

[ronisbr]

It does not work even with the patch. If you do not use mac-pseudo-daemon, you need to start emacs daemon from GUI and let the window opened. That's why I am unfortunately still using emacs-plus.

[naavid-morshed]

I installed emacs-mac like "brew install emacs-mac --formula --with-native-comp --with-no-title-bars".

"emacsclient -t" opens in terminal but "emacsclient -c" also opens in terminal. my Emacs.app is in /opt/homebrew/opt/emacs-mac/Emacs.app/contents/MacOs/Emacs. I created a symlink to Application folder. I'm getting occasional hiccups when moving cursor but the hiccups are not present if gui opened from Application folder or as tui like "emacs -nw"

What should I do to fix this issue?

[pierre-rouleau]

For anyone interested, I am using macOS Sonoma with Emacs 29.3. From the macOS terminal shell, I am able to launch the Emacs daemon and then start Emacs GUI or text-based clients. I described the problem and the solution and wrote shell scripts that can be used to start Emacs in various ways (including starting the daemon if it's not already running).

You can find the information here: https://github.com/pierre-rouleau/pel/blob/master/doc/emacs-daemon.rst.txt

[vleonbonnet]

For anyone interested [...] I described the problem and the solution [...] You can find the information here: https://github.com/pierre-rouleau/pel/blob/master/doc/emacs-daemon.rst.txt

@pierre-rouleau Your doc seems to refer to https://emacsformacosx.com/ and not this repo (emacs-mac), did I miss something?