Re: [h-e-w] gnuserv maintenance

[Lennart Borgman]

----- Original Message ----- 
From: "David Vanderschel" <address@hidden>

: >3) Gnuclientw is compiled as a win32 application and
...
: I think I might just call this "gnuclient linked as
: a win32 application" as opposed to "gnuclientw modified
: to wait".  But I agree without having to conduct the
: experiment.

Sorry, yes, of course I should have written "linked".


: >9) As David and others have pointed out it is very
: >important that gnuclient[w] waits when Emacs is used
: >as an editing server for another program. Both
: >gnuclient and gnuclientw can wait!
:
: Not in their present incarnations.  I think you are
: saying that gnuclientw can be modified so that it can
: be told to wait.

Yes ;-)


: >Summing this up I come to the conclusions:
:
: >a) Gnuclientw must not wait by default (drop-target)
...
: >b) It must be able to wait
:
: If you view "it" as the version linked as a win32
: application.

Yes, sorry ;-)


: >Instead I sugges a reverse switch that can fullfill
: >this: -w for wait. Remove the old -q switch!
:
: Since you have no regard for backward compatibility, I
: must assume that you are really trying come up with
: specifications for a new program which is not required
: to be compatible with the existing gnuclient - ie.,
: something in the emacsclient for win32 context or
: something else yet.

You think you are right. I did not care very much for backward
compatibility. I now realizes that it break things for those currently using
gnuclient from applications. A way to keep compatibility is to just add -w.
Then -q would still mean nothing with gnuclientw and -w should mean nothing
with gnuclient. Ugly in princip but then gnuclientw -w could be used in
applications calling Emacs and nothing used now is broken.

And yes I did have spec for emacsclient in my head. It looks like there are
the same difficulties there since emacsclient has a switch --no-wait (-n).
Maybe just adding -w would be the best there too. The differences between
emacsclient and emacsclientw with regard to default behaviour must then be
the same to get things working on ms windows.


: As long as I can blow off backward
: compatibility, getting back to a single win32
: application which can do everything sounds good to me.
: (It is probably possible to fold in gnudoit function
: while you are at it.)

Gnudoit is already in princip merged into gnuclient[w] in Guys version
(though it also still exist standalone). I think it should be merged into
emacsclient too. (But that is another story.)

I believe it is good to have one version linked as console and one version
linked as a windows app for the reasons we have discussed and also because
the console version may be useful for logging. But logging could be handled
differently as you have suggested. However I would go for two versions. And
when it comes to emacsclient


: Your compilation was indeed illuminating.  Thanks for
: the effort.

Ok, then it worked. Thanks.

- Lennart