Re: [h-e-w] gnuserv maintenance

[David Vanderschel]

On Friday, October 29, "Lennart Borgman" <address@hidden> wrote:
>1) Gnuclientw exists to avoid the ugly dos window. (Jason)

Though the rationale for its existence which I gave,
the one based on the argument-passing problem, is a
potentially valid one, I have now argued that it is
not worth pursuing.  See my "Forget the drop target"
article.

I do not fully understand the "ugliness" rationale.
We are only talking about minimized DOS windows,
right?  We are only talking about one such window for
each client program which is waiting on gnuclient to
exit, right?  When is this ugly?

>2) It is essentially the same code as gnuclient. The
>difference is in the three lines

>#ifdef WIN_VERSION
> qflg++;
>#endif

>which sets -q for the WIN_VERSION (gnuclientw). (From
>Guys code, maybe David read some other code?)

No.  That is precisely what I did see.  Since I did
not understand about the different linking, I thought
that this trivial forcing of the q-flag was the _only_
difference. 

>3) Gnuclientw is compiled as a win32 application and
>gnuclient is compiled as a win32 console
>application. A win32 application should never show a
>dos box as far as I understand. (David, are you using
>Guys version?)

Yes.  (I just verified it by breaking gnuclient with
Zone Alarm.)

>And even if gnuclientw is waiting you will not notice
>this if you start it from the command line. (Just
>change the lines above and recompile to see
>that. Look in task manager.)

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. 

>5) If a link on the desktop is used as a drop-target
>it does not read the arguments. (David - and I tested
>this too on NT4 SP6.)

Our knowledge grows.  :)

>6) We do not want shortcuts or drop-target to wait
>and we do not want them to display a dos window.

But I no longer believe this is a requirement for
gnuclient, as the drop-target shortcut can still be
implemented with a PIF whether or not the system
passes arguments in the target specification of a
shortcut.

>7) Drop-targets do not accept arguments so gnuclientw
>must avoid to wait by default.

Drop-targets do not _always_ accept arguments, so ...

>8) If gnuclient[w] waits for a "ready message" from
>gnuserv is handled by the -q flag. If this flag is
>set then server is called with server-edit-files
>(which sends a "ready message" when the buffer is
>killed), otherwise server-edit-files-quickly is
>called (and this sends no "ready message" back).

>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.

>Summing this up I come to the conclusions:

>a) Gnuclientw must not wait by default (drop-target)

The relevant argument here is simply backward
compatibility.  It does not wait by default now, and
there exist programs which already use gnuclientw and
which depend on that fact.  The drop-target argument
is a red herring in this context.  At best, it
explains why the current behaviour is as it is.

If backwards compatiblity is not a goal, then a number
of the issues you seem to be worrying about go away. 

>b) It must be able to wait

If you view "it" as the version linked as a win32
application. 

>c) We do most often not want to use gnuclient because
>of the ugly dos box.

I am not assaulted by ugly dos boxes.  I am not
convinced that this issue has been properly presented.
Are there those who would say that _all_ occurrences
of DOS boxes in the task bar are objectionable (in
particular those corresponding to processes waiting on
emacs to finish with editing a file).  It seems like
it would be a problem only if you had several
different applications running, each of which had
handed a file to emacs for editing and was now
waiting.  That sounds like a pretty confusing way to
work to me.  I have never had more than one such file
open for editing at a time - and thus at most one
"ugly" DOS-box button on my task bar.  I must be
missing something.  (Note - My emacs session may, of
course, have a great many files open; some of which
may get referred in the process of editing a file
passed by a remote client.  It is just that I don't
expect a multiplicity of such remote clients to be
simltaneously looking for editing from emacs.)

>d) This leads to that the -q switch is not very
>useful. 

?  Then why is it that I have used it consistently
with my registry entries?  I think the response is
that I _should_ have used gnuclientw instead.  I think
I now agree with that argument because the ephemeral
DOS boxes I get with gnuclient -q really do serve no
purpose.  (But they are not ugly because they do not
persist.) 

However, the relevant point here is again going to be
backward compatibility.  gnuclient with and without -q
must continue to do what it does now as there exist
programs which depend on that behaviour.

>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.

In such other context, we may debate whether there
even need exist a version linked as a console
application.  The present virtue of gnuclient in that
regard might be achievable by other means - eg., an
explicit log file.  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.)

>I hope I have addressed most of the questions
>regarding waiting here. Sorry for not answering
>directly but i thought it would be easier to get it
>all together.

Your compilation was indeed illuminating.  Thanks for
the effort.

Regards,
  David V.