Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

emacsclient not functioning correctly #52

Open
jdtsmith opened this issue Jan 19, 2016 · 31 comments
Open

emacsclient not functioning correctly #52

jdtsmith opened this issue Jan 19, 2016 · 31 comments

Comments

@jdtsmith
Copy link

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
Copy link
Owner

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
Copy link

@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
Copy link

I'm also interested in this.

@ylluminarious
Copy link

@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
Copy link
Owner

@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
Copy link

aiguofer commented Jan 7, 2020

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
Copy link
Author

jdtsmith commented Jan 7, 2020

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
Copy link

aiguofer commented Jan 7, 2020

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
Copy link

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
Copy link

aiguofer commented Jan 8, 2020

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
Copy link
Author

jdtsmith commented Jan 8, 2020

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
Copy link

@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
Copy link
Author

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

@ylluminarious
Copy link

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

@jdtsmith
Copy link
Author

jdtsmith commented Jan 11, 2020

@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
Copy link

@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
Copy link

@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
Copy link

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

@hisnawi
Copy link

hisnawi commented Mar 1, 2020

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
Copy link

@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
Copy link

hisnawi commented Mar 1, 2020

@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
Copy link

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

@hisnawi
Copy link

hisnawi commented Mar 1, 2020

I reinstalled it and now it works fine. Thanks.

dancewhale pushed a commit to dancewhale/dotfiles-archive that referenced this issue Mar 21, 2020
暂时保存可能问题的解决方案,看后续需求再决定。
railwaycat/homebrew-emacsmacport#52
解决mac下的emacs-mac包 lacks multi-tty support 的问题.
@ywwry66
Copy link
Contributor

ywwry66 commented Nov 15, 2020

@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
Copy link

@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
Copy link

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

@ronisbr
Copy link

ronisbr commented Aug 20, 2022

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
Copy link

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
Copy link

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
Copy link

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?

@pierre-rouleau
Copy link

@vleonbonnet I should have mentionned it in my message; I'm not using emacs-mac based Emacs. But I noticed that I needed to run a graphics-capable emacs as the daemon if I wanted to be able to open a client in graphics mode or text mode. That might also be the case here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests