Re: [h-e-w] gnuserv maintenance

[David Vanderschel]

On Friday, October 29, "Jason Rumney" <address@hidden> wrote:
>David Vanderschel wrote:

>>>You explain how arguments don't work in shortcuts,
>>>but can you or anyone else explain why -q behaviour
>>>is neccesary for shortcuts?


>I just tried testing this by creating a Shortcut to "gnuclient.exe" -q.
>At least on Windows 2000, this works, and I have recollections of doing
>this on Windows 95 many years ago before gnuclientw was thought up.

Are you saying that you know for a fact that gnuclient
actually sees the -q argument when you drop a file
onto that shortcut?  The shortcut is going 'work'
whether gnuclient sees the -q or not - it just behaves
slightly differently depending on whether or not it
does see the -q.  The most obvious indication that the
-q was _not_ seen would be if the DOS box for the
gnuclient invocation persists while the buffer does.
(Initially, there will also be the message about C-x
#.)  If you do not see the persistent DOS box, then
the -q was seen.  If the -q argument is being seen by
gnuclient under Windows 2000 in the drag-and-drop
case, then that behaviour is different from that of
Windows 98 and there is no reason at all (that I know
of) to even have gnuclientw available on Windows 2000.

>>Without the -q, emacs produces the message, "When done
>>with a buffer, type C-x #.", which is how you can
>>explicitly release the buffer for gnuclient's sake.
>>It seems to me that the message about the C-x #
>>command would be meaningless and confusing for a drag
>>and drop on an emacs shortcut.

>Perhaps, but if that is the only reason not to change things, then I
>think it is less annoying than the problem of programs that doo need to
>wait not working with the current implementation unless you use the
>version of gnuclient that produces an ugly and useless DOS window.

Those programs should not be using gnuclientw in the
first place.  You seem to be making an erroneous
assumption somewhere along the line here, and I cannot
guess exactly what your misconception is.

I agree that the confusing message might not be a
sufficient reason for some folks, but the following is
a more compelling reason.

>> Furthermore, there is
>>no need to have the DOS window for the corresponding
>>instance of gnuclient lying about - possibly
>>indefinitely if the buffer is never released (and
>>there is no a priori reason to expect that it should
>>be released in this case).

>There is no DOS window with gnuclientw. 

Yes there is; but it persists only very briefly until
gnuserv has accepted its task from gnuclient.  After
that, gnuclientw exits and its DOS box closes.  I can
always see the minimized DOS box appear briefly on the
task bar in this case.  When it sees the -q argument,
gnuclient behaves in the exact same manner.  gnuclient
without the -q is what the programs which doo need to
wait should use.

What I was arguing above is a reason why drag and drop
_needs_ the -q behaviour which gnuclientw provides -
ie., to prevent the DOS window from persisting.  Your
comment, though nearly true (ie., ignoring the brief
interval of existence), merely asserts the behaviour
which should be desired in the drag-and-drop case.  It
is the behaviour which does obtain with
"gnuclientw.exe" in the target specification but it
does _not_ obtain (at least under Windows 98) with
"gnuclient.exe -q" in the target specification even
though you would expect it.

>This is the reason it exists.

No.  I am claiming that it exists because it enables
you to get the -q function out of gnuclient without
having to actually pass _any_ argument.  At least for
Windows 98, _no_ argument is passed to gnuclient when
you drag and drop onto a shortcut - even if arguments
are specified in the target specification of the
shortcut.  (The inconsistent thing is that arguments
_are_ passed to gnuclient if you just open the
shortcut.)

Regards,
  David V.