Re: [h-e-w] gnuserv maintenance

[Guy Gascoigne-Piggford]

Jason Rumney wrote:

> What exactly doesn't work when the default behaviour is to not wait?
>
> .....
>
> Who knows what programs someone might want to use gnuclientw
> from. Some of them might have the same bug as Explorer Shortcuts on
> Windows 9x and NT where they cannot specify any arguments. I think it is
> more important that gnuclientw and emacsclient works for them than for
> it to exit immediately just because some people happen to like it as
> the default behaviour with no justification.
Well I'm not sure I'd say no justification, but perhaps less need on a 
modern Windows.

Personally the thought of having a lot of gnuclients hanging around in 
the process list for absolutely no reason strikes me at ugly.  I do 
realise that they aren't awfully significant from a memory point of view 
and eventually the sockets will time out and close then the gnuclient 
will just go away anyway, But when gnuclient is used as a point of 
Explorer intergration then we know there's no need to wait so we chose 
not to.

To be completely honest I've not come across a single Windows (not 
console) app where I'd want to install a separate editor and have it 
wait for the result, I'm not saying that they don't exist, just that 
it's really easy to use Windows a lot for a lot of divers things and 
never come across this need.  I do have quite a few command line tools 
that expect an external editor to wait around (not to suprisingly they 
are all unix ports).

So I guess I'm saying that what the correct behaviour is, is all 
dependant on what your end goal actually is.  My take on this was 
attempting to make Windows intergration easier with the bonus of keeping 
pretty good compatability with the unix version of gnuclient.  I still 
think that the easiest way to do this is to just add something like -w 
to gnuclient and allow it to hang around if you need it to.

Finally this is talking about *gnuclient* which since it's been a common 
tool of this sort on Windows has a lot to be gained by remaining 
compatible with it's previous behaviour.  I am assuming that with no 
previous version of emacsclient being available on Windows, that any 
emacsclient port may have slightly different priorities.

Effectively:  I think that what seemed like a good idea as a change to 
gnuclientw back in 1998 still seems good enough to not reverse.  I'm not 
sure I'd make that change if I was doing the same coding now since 
machines and OSs have changed enough to make it less of an issue.

Guy