On 03/06/2025 21:28, Charles Choi wrote:
I have published two macOS apps on the Mac App Store which support Org
Protocol in different ways:
- Captee (launched April 2023) which constructs an Org Protocol request
from the macOS Share Menu.
- Scrim (launched April 2025) which is an Org Protocol proxy (scheme
handler) for macOS.
Thanks for your patience. Reading Ihor's message I had an impression
that Captee is enough to pass org-protocol URLs to emacs. I was not
aware that it is just share target implementation and it needs another
glue application to pass data to emacs server. If so, I see why Captee
is missed in the updated text (mentioning it still might be helpful
since I am unaware of other articles discussing capture from other apps).
Among the motivations for writing Scrim was that all the guidance for
macOS users on WORG related to setting up a scheme handler for Org
Protocol was obsolete.
Certainly Worg page should be rewritten.
Am I to understand that expectations of Apple is that Emacs application
should be published with implementation of share target and either
universal links (deep links in Android parlance if I do not confuse
features) or custom URL scheme? I am realizing that most variants of
Emacs for macOS will not do it so 3rt party helpers are unavoidable.
Steps 1, 2, and 4 are platform-dependent (GNU/Linux, macOS, Windows),
with steps 2 and 4 being especially so. It might perhaps be better to
organize with respect to platform first, e.g.
- GNU/Linux, BSD
1. Setting up Emacs Server.
2. Setting up the Org Protocol Scheme Handler.
3. Setting up Org Protocol Capture. (link to common section)
4. Setting up Org Protocol URL Request.
- macOS
1. Setting up Emacs Server.
2. Setting up the Org Protocol Scheme Handler.
3. Setting up Org Protocol Capture. (link to common section)
4. Setting up Org Protocol URL Request.
Yes, I have in mind something like this. Perhaps:
- Setup and test a capture template.
- (require 'org-protocol)
- Linux: should work out of the box,
test using emacsclient command
- macOS alternatives:
- Scrim setup including server configuration
(and share menu)
- Emacs build with built-in org-protocol support
- Bookmarklets, browser extensions, etc.
TCP Emacs Server uses a shared secret file (default named "server") for
authentication.
Thanks for explanation. I am surprised that a sandboxed app may access
this shared file with a secret.
That said, macOS security policy prevents the usage of local domain
sockets as IPC between code-signed applications.
Is it restriction namely for operations with sockets or path where Emacs
creates its socket is inaccessible? From my point of view it may be
expected that running external binary (emacsclient) is prohibited, but I
am unsure why a custom communication channel (perhaps with custom
permission) may be harmful. Anyway I am almost sure that it is not
feasible to set a more visible directory for the socket and to request
com.apple.security.files.user-selected.read-write from sandbox.
Is it possible to invoke emacsclient or to connect to Emacs socket from
native messaging helper for a browser extension?
Frankly speaking, I expected to find more discussions and complains
related to emacsclient on macOS, but quick search gives mostly outdated
results.
P.S. It seems macOS desktop/laptop security model became
indistinguishable from mobile OS where data are tightly sealed withing
each app.
