[EMAIL PROTECTED] wrote:
Lennart: "Gnuclient just expands filenames before sending them
to gnuserv. Filenames must then be single arguments to gnuclient.
Actually that is not very good for the integration with the OS."
So it could be CMD's processing of text in the doskey macro
that translates the \n into control chars.
Maybe I should have read the code in gnuclient.c before answering. If
you look at that you will find that for -e the argument is just sent to
Emacs (gnuserv) with some additions if -q is used. If -e is not used
then gnuclient tries to expand the file name and it also actually
translates \ to / as far as I can see (in filename_expand for w32).
The processing of \n is entirely done by Emacs, not gnuclient, as far as
I can see.
Sounds reasonable. The emacsclient in the CVS version doesn't
seem to have much functionality, compared to gnuclient.
What's the benefit of emacsclient over gnuclient? That it's
officially part of GNU Emacs?
What's the problem with emacsclient on Windows anyway?
Doesn't Windows support Berkeley sockets?
I have not looked at emacsclient/server very much, but I believe the
functionality to edit remote files is not there. However that
functionality might pose security risks, I am not sure. Editing remote
files can be done using tramp in CVS Emacs, which supports ssh.
I do not know much about sockets. There differences in sockets handling
on w32 compared to *nix platforms however. Code for handling sockets on
w32 is in gnuclient/server. So we have it, but it is rather complicated
to fit that into emacsclient/server it seems to. So if someone feel
confident doing that and is interested it would be very welcome work.
