[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h-e-w] gnuserv maintenance
From: |
Lennart Borgman |
Subject: |
Re: [h-e-w] gnuserv maintenance |
Date: |
Sat, 30 Oct 2004 02:55:13 +0200 |
----- 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
Re: [h-e-w] gnuserv maintenance, Richard M. Heiberger, 2004/10/30
RE: [h-e-w] gnuserv maintenance, Matthew X. Economou, 2004/10/31
Re: [h-e-w] gnuserv maintenance, David Vanderschel, 2004/10/31
Re: [h-e-w] gnuserv maintenance, David Vanderschel, 2004/10/31
Re: [h-e-w] gnuserv maintenance, David Vanderschel, 2004/10/31