OK, so you don’t want to use open -a, but why does the Atom binary take so long to contact the other process? Why does it try to open a new window, which then closes to open the right one? My use case is replacing
EDITOR=atom. EDIT: The animations on editor startup are a distracting implementation artifact, and the time taken is a further problem.
I don’t think I’d be qualified to send a pull request for this, I hope somebody else can do it.
I suspect you should just clone (most features of) nailgun (as in, reimplement the code following the features), it would allow solving all the problems you mention (with a minor twist). In other words, the client should:
- start fast (by, say, being native; you can reuse nailgun’s client)
- try connecting to the server (that is, the running application) via inter-process comunication (for instance, a local-only network socket)
- pass the command-line arguments, directory, even environment variables to the server for it to handle; nailgun propagates even standard input/output/error over the connection
- unlike nailgun, if the server is not available, it should just start it as usual.
Warning: nailgun is not secure, and I’m not sure how to fix that and whether that’s important. Here, in the worst case, another local user might be able to connect to open a file in your Atom instance; if command line actions could perform actions, there would be an actual security risk (imagine somebody giving instructions to another user’s Atom instance). Should that be a problem, I’d look at the Xauth protocol: what I understand is that the client must authenticate to the server with the content of a private file inside
~/.atom, which is filled with unpredictable data at Atom’s startup.