emacs-30: provide Emacs Client.app #783
Conversation
|
It works, but I can't figure out how to capture file path when you open a file from Finder. If someone knows - please let me know :) |
|
Ok, shell scripts is not the right approach as it seems. Turns out macos sends filename via system events, not via arguments. Will explore two directions - a simple cocoa application or a simple apple script application. |
|
if you create a AppleScript or automator app it works fine. I am using it this way. |
|
unfortunately brew services does not run the daemon. I guess it's just keeping emacs alive? which six of one half dozen of the other I guess. I guess emacs is looking for the daemon to run in client mode? so maybe it doesn't know what's going on with this service that's just keeping emacs running? |
|
I'm curious about what this is for? If the idea is to support opening files via finder interactions or via If it's to support opening via org-capture, isn't that better done in the existing Emacs.app, ie issue #285 . Or is it to have an app to call that can ensure the main Emacs is alive and route file args to it? In my current workflow, restarting Emacs looks like Once that's up, I can treat the Emacs.app like most other apps using activation/open/drag files etc. It'd be nice to have stop/start/restart/daemon handling less of a thing I need to worry about, as depending on the timing I can end up with extra processes, or a foreground daemon app instead. I think ideally the one Emacs.app would act as the app to:
Is there benefit to handling these cases in different applications, or is it more about what's feasible? |
@danielboston38 I'm running emacs-plus via |
Any proof? I just did it and it works. Keep in mind that TCP is not supported (not sure why).
Yes, but every user needs to create it. Wouldn't it be nice if we had it OOTB?
To have ability to open files from Finder in Emacs Client. And I just realised that you are correct for cases when Emacs is already open, because Finder doesn't create a new instance of Emacs. But if you start Emacs server via brew, then things break. When I try to open a file in Emacs via Finder when the service is running, Emacs is opened, but the window is not created 🤷 So I actually have to use CLI to open a new window. And maybe this is what needs to be fixed actually. @mbhutton thanks a lot for your insights! 🙏 |
|
True! Activation and file opening via Finder work well when the service is running and at least one frame is active. But when there's no active frame then usually something surprising happens like an extra process, or no window opening, and I need to figure out what went wrong and fix it. It would be amazing to have an app, Emacs.app itself or a companion app, "do what I mean", for activation, finder files, and org-protocol. My dream would be for it to:
A tool that was able to do all that would also be just as useful from the command line.
|
|
Maybe there are some extractable, composable commands in there that could be useful as their own command. Eg:
Btw I know this is crazy out of scope for this PR (!), just trying to capture what the scope of the problem is. Kinda sounds like a project in itself to cover all the above. |
|
Oh and (to add to the list of wishes!) ideally the app would also act as a share target to invoke the command org-protocol convention of url, title, and text. If all of that aligns with what most users want, I could definitely contribute, or possibly write it directly in a different project, as it could potentially be useful across all the macOS Emacs flavours. I think that solving all those problems probably does require one tool that's able to coordinate all those aspects, otherwise it's easy to end up with a patchwork of apps/tools that only work in some cases. |
|
Hi @d12frosted, I essentially added a giant wish list above for all the things I wish such an app would do, which I know is unrealistic and out of scope for a single PR! Since I have so many wishes for such an app, I've started a project at https://github.com/mbhutton/EmacsOpen to capture all that scope and eventually do all those things above. The initial scope is to get it to work with Emacs-plus v30 when running Emacs daemon via It's very pre-pre-alpha, just getting started, not close to functional yet. Very happy to collaborate if you're interested, otherwise happy to implement it solo. |
|
This patch that just got merged might be relevant (savannah link, github mirror link) |
|
@d12frosted What work is still remaining before you'd merge this PR? |
|
Bump again @d12frosted, what's left here? This would be really cool to get in 😄 If it helps I just did a rebase locally and it pretty much applies cleanly from current |
|
@mcmehrtens @elken in short, I need to figure out how to make
I just need find some time and motivation to finish it :) but maybe I will tackle it this month. seeing interest and this PR increases my motivation 😅 |
|
Thanks for the update! No rush of course 😄 |
d12frosted
force-pushed
the
feature/emacs-client
branch
from
6d62623 to
74b4759
Compare
this commit replaces the initial naive shell script implementation with a robust AppleScript-based solution that properly handles file opening from Finder. **problem with initial approach** the original shell script wrapper could not receive files opened via Finder's "Open With" menu or drag-and-drop. this is because shell scripts cannot handle `AppleEvents` - when macOS opens files from Finder, it sends `application:openFiles:` events, not command-line arguments. **solution** implement `Emacs Client.app` using AppleScript compiled with `osacompile`, which: - handles file opening from Finder via on open handler - supports drag-and-drop onto app icon - works from Spotlight/Dock via on run handler - includes `PATH` injection (respects `EMACS_PLUS_NO_PATH_INJECTION`) - auto-starts daemon using `emacsclient -a ''` - proper macOS integration with bundle identifier, file type associations, and custom icon
|
ok, I think I have some progress - I've pushed a commit that implements TL;DR - there is some progress, I need your help with testing and if everything is fine, I'll update documentation and will merge this PR. this commit replaces the initial naive shell script implementation with a robust AppleScript-based solution that properly handles file opening from Finder. problem with initial approach the original shell script wrapper could not receive files opened via Finder's "Open With" menu or drag-and-drop. this is because shell scripts cannot handle solution implement
I would really love to get some proper testing of this solution (works only with Emacs 30 for now), specifically the following test cases:
one thing that I have noticed so far - |
|
ok, in general it does look promising 🤞 |
|
@mbhutton I am also curious to hear your feedback since you spent some time figuring these things out 🙏 |
|
I don't use anything like yabai but I will endeavour to test this today 👍 |
|
The only thing that doesn't work for me is the dock :/ I can do new frame but that's it, no new client. Because the osascript calls Emacs Client.app also has no icon, if possible it should inherit from the icon you set, eg I use the doom icon |
|
@elken thanks for checking! ❤️
why do you want a new client? that's the point of
not sure I understand this bit - we copy icon; though I need to check if we copy the user prefer icon or the stock one 😅 I will check it a bit later 🙏 |
No reason inherently, just reporting what I see 😄
It could be a Tahoe thing maybe, but this is what I see for it |
Ah good, I wanted to double check if it's something I didn't understood in the expected user flow or something else 😅
oops, I have just realised that I am using an older Sequoia 😅 I tried building with dragon icon and this is what I get: 
I see you have an alias. Can you check of original |
The original has the same icon, icons in general have been drastically changed for Tahoe (see #815) so possibly related, I'm far from an expert though 😅 |
|
hm... maybe you are right; does |
|
Yep Emacs.app is fine as is the symlink but you can also see the impact of #815 (the white background, previously it was transparent) 
|
|
@elken that's actually strange as both icons should be treated the same 🤔 maybe there is actually an issue with icon setting, cause I see the following files under 
let me investigate, cause it might be a misconfiguration on formula side |
Yep I see the same thing here 😄 I assume Assets.car is some Tahoe thing, |
|
pushed potential fix, will appreciate if you can test it @elken 🙏 |
regarding this file, it seems that I need to delete it as well; can you manually delete it and see if it helps? |
No change, just finished building |
Also no change :/ |
|
well, if everything else works, I am inclined to merge this PR and then I will fix the icon discrepancy issue once I upgrade to Tahoe on one of my machines (possibly closer to end of week) |
|
@elken thanks for testing though 🙏 |
|
No worries! It's a minor annoyance at best, just means it's not obvious that a file is marked to open with Emacs Client by default, but it's a good start 😄 |
|
ok, so I am merging; hope to get more feedback - having it in master should make the feature more discoverable 😅 |
|
oh, I had a laptop where I don't care about macos version, so upgraded and pushed a fix for icons in macOS 26 - caae572, already in master but we really need to figure out the situation with icons in Tahoe - they are ugly lol |
this is mostly for testing
if it goes well, I will provide Emacs Client.app for other versions of Emacs.