-
-
Notifications
You must be signed in to change notification settings - Fork 187
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
MacOS App should detect running emacs brew service and connect as a GUI emacsclient. #398
Comments
Hey @cwlbraa I think this kind of relates to #158. That issue stagnated though. What do you think about the following solution? In addition to The only possible issue I see - there will be no way to configure socket and server, you'll have to use defaults. |
I'd use the simple solution if it existed, so yeah I think it's good. I'd probably hide the full Emacs.app from Alfred and end up with basically the same behavior as the fancy thing I previously described. I'd also be perfectly happy with defaults. |
Currently I use an "application" created via automator that runs The solution you propose seems about the same, having it included with emacs-plus would be very nice |
It would be great to have the |
I'm having trouble finding |
@restfuladi you can't find it because it doesn't exist :) But there is |
Makes sense, thanks. Any ideas on how to integrate that with Spotlight/Alfred? |
@restfuladi Spotlight/Alfred have issues with symlinks, however Raycast works really well! |
If you create an Automator application for emacs client and put it in /Applications, that should work with Spotlight. I recommend full path: |
Piggy-backing on this issue, happy to make another one - when I launch emacsclient from terminal or Alfred, it doesn't switch to the app - the window opens behind other windows, and then I have to manually switch to it. Has anyone a fix for that? |
Hi, I think Emacsclient.app is a fantastic idea. Is this something that will become available in the homebrew installation? I am new to macos (coming from linux), and I have very little experience doing mac-y things. I also observed what @rross101 said. It's a minor inconvenience, but of course, if it can be addressed it's even better. Software architecture of the mac is so, so inefficient. It's like homebrew is creating an OS within an OS, and obviously there are no standards like XDG or how permissions are managed etc. I can't even get my brew-installed hunspell to integrate with emacs-plus. Sorry for the rant, but macos is just such a user unfriendly environment to work in if you are trying to something even remotely technical. |
The idea is to provide this as part of Emacs+ installation. But it's not high on my priority list. So if someone really wants it, contributions are welcome.
Indeed, macOS is slightly (quite?) different in many regards and might be confusing if you come from newer Linux-es. macOS is based on older FreeBSD.
Look, if you need some help, don't hesitate to open a discussion. The problem you describe is not really related to Emacs+, but it's somewhere on the border, so maybe it's fine :) |
@ChauhanT This is what I did:
@rross101 You could use Apple Script for that: function ec() {
emacsclient $@ && osascript -e 'tell application "Emacs" to activate'
} |
I found I had to tweak @citizen428's answer a little bit to get the applescript to work reliably: |
This works for me. Thank you! |
I just checked quickly and noticed that these Automator scripts do not launch emacs when the server is not running. Has anyone else encountered this? |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I love that this formula includes a brew service, and for the longest time I was running that service alongside the Emacs.App. I only recently realized that these 2 paths to invoking Emacs are unaware of each other, and the App will not attempt to connect to the daemon started by the brew service.
If this worked, it'd be amazing for startup times and keeping a single persistent Emacs daemon.
The text was updated successfully, but these errors were encountered: