Re: w32 does not have emacsclient/server

[Stefan Monnier]

>> > In emacsclient.c I've got rid of all AF_UNIX stuff.
>> Doesn't sound so good.  I'd rather make it possible to choose between Unix
>> and TCP sockets (default to Unix when possible, and TCP otherwise).
> Oh. Well, the AF_UNIX code should be conditionally commented out on
> Windows, or do you mean to choose at run-time?

As much as possible, it should be chosen at runtime, but under w32, the
choice would have to be done at compile time since IIRC AF_UNIX doesn't
exist, so the compilation would otherwise fail.

>> I'd rather see "server-name" which could be a path to a unix socket (like
>> now) or just a relative name of a unix socket (like now) or the name of
>> a server to be found in ~/.emacs.servers.  I.e. if there is no unix socket
>> of that name, lookup ~/.emacs.servers for TCP servers.

> I'm not sure I'm getting what you intend with this. Why would you do
> have several servers on the same .emacs.server(s) file?

>   - To run several instances of Emacs, each one a server, using the
> same .emacs.server? I think that would cause all kinds of race
> conditions; it'd be better to simply use different server files.

Maybe you're right, and .emacs.servers should be a directory.
So if you run emacsclient --server-name foo it would look for
/tmp/emacs<uid>/foo for a unix socket and if that fails it'd look for
~/.emacs.servers/foo for a file holding the host/port/auth info.

>> Sounds very good.  To the host, port, and auth, I'd add a "server
>> name" entry, which would default to "server", to reproduce the
>> socket-name thingy.
> OK.

If the server name is in the file name, it doesn't need to be added inside
the file.

>   - Or, for one single Emacs to have several server instances? I don't

I'm not sure this can currently work.  I wouldn't worry about this case.

>> > The last change has been to make it consider \path and c:path as absolute
>> > paths (previously it would prepend the current directory to Windows-style
>> > absolute paths).
>> 
>> Of course this should only be done under w32.

> Why? As I see it, the name you send is interpreted by the server, so
> the client has to be able to send absolute and relative paths for all
> environments (in fact, VMS or Mac ones should also be grokked, if
> emacsclient works on these environments). I mean, if I'm on a
> GNU/Linux, and the server is running on a Windows machine, emacsclient
> c:\my\file.txt is likely to be a file on the server...

I'd basically assume that cross-host uses would only work right if both
machines share the same file-system (and layout).  In other cases, it's not
really clear which behavior is right in which case.  I.e. in your example
where the command issued on the client refers to a path on the server, it
may be preferable to use --eval (find-file "c:\\my\\file.txt") to make it
clear what is the intention.  After all, * and other meta chars will be
handled by the shell under the assumption that the argument to emacsclient
is a local file name.


        Stefan