Use emacsclient? about emacs_chrome HOT 4 CLOSED

I'm unsure of what you mean. On Unix the emacsclient program is a simple program that passes the file name via a UNIX domain socket held open by the Emacs running is server (or --daemon) mode. If you use the pycl.py server it will accept the request, create a file and call emacsclient. However this is more inefficient than directly connecting to the edit-server running on the emacs that will do the editing.

However it could be that on Windows Emacs server mode operates over a network socket. Do you know if this is the case?

If this is the case and the server code can accept an http request there is no reason why the extension couldn't have an option added to generate a request to the emacsclient server. Please bare in mind that the extension cannot create files on the local system. The only way it can communicate with the outside world is via the Xml RPC mechanism it currently uses.

Unfortunately I don't run Windows so can't really try these things out. However I'll gladly accept patches.

from emacs_chrome.

Yeah, I'm not that familiar with the Unix version - so it doesn't surprise me it uses something like a domain socket. The Windows version uses a TCP network socket (at least as I have it configured). With the server running in emacs, I could see it's listening on a port (51138 in my case). I set the extension's port to that and hit the test button and got "authentication failed" - seems to me like it connected, but didn't pass the authentication string like server.el was expecting.
I'd have to look at the code to determine how the server is expecting input - not sure if it's a straight http request or other protocol. server-process-filter in server.el documents the input it expects but I'm not seeing anything that looks like it groks http.

(In the server log I see one request logged like this:
"-auth ZBp5H+fMM8M[Hvu+<l1u`lN|o~0"""@p"Nznd[%x(wI>:<C0)V_dR.u^cztX!^Q -dir C:\sys\Console2/ -nowait -current-frame -tty CONOUT$ w32console -file console.xml"
The first parameter is the authentication string from the server connection file (EMACS_SERVER_FILE) that the server.el code says it expects.)

If the extension can access the Windows environment, find EMACS_SERVER_FILE variable, open the file it points to and read the contents, it can get the authentication string to pass to emacs. I don't know enough about extensions to know if that's possible via Xml RPC.

But then again - is it that bad to have both server.el and edit-server.el running in one Emacs process? Just from a standpoint of efficiency I would think it'd be better to run just one, but if it's not really that much of a resource drain or doesn't cause adverse interactions, I could just continue to use both.

from emacs_chrome.

Sorry for the delay getting back to you. I don't think that will be possible. The extension on the chrome side cannot access the file system at all so knowing the value of EMACS_SERVER_FILE would be useless to it.

I suspect it would require patching the emacs server code to allow file contents to be passed back and forth over the TCP socket, ideally in some sort of XmlRPC style. However that is basically re-implementing edit-server.el.

If your OK with it I'll close this issue as it's unlikely to ever happen unless someone has a burning itch to scratch.

from emacs_chrome.

It's been a while since I looked at it, but I think it would work if the extension could pass the authorization string. My suggestion about the env.var was just to get that string. Since the extension can't access the local system, then there would have to be another way to get the string to it. Either the user could enter it in the options page (ugly), or if the extension could listen for some kind of ack message, maybe some elisp could be written to pass the authorization string to the extension - as a kind of handshaking when starting up. The extension would then have the string and pass it to the server with its requests as the server expects without having to access the local filesystem. I can still see issues about coordinating the startup, but I think it could work.
But, I've been using Ubuntu a lot for the last few months so its not a big issue for me. So go ahead and close the issue. If it bugs me enough, I'll take a look at implementing it and submit a patch.

from emacs_chrome.