>> > 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel