Re: [h-e-w] gnuserv maintenance

[David Vanderschel]

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

>> Embedded in my last posting is a rationale for why
>> gnuclientw needs to exist in addition to the the -q
>> flag for gnuclient.

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

It is the behaviour you would want for a shortcut.
There is no application waiting on the edited file.
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.  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).

(When there really is a client application waiting on
gnuclient, the C-x # command is not normally
necessary, as emacs also releases gnuclient if you
delete the buffer, which is what I usually do after
saving the edited file.  Indeed, I normally use the
command I created to delete, in a single stroke, the
buffer, the emacs window, and the emacs frame which
resulted from the gnuclient call.)

>The other more important difference between gnuclient
>and gnuclientw is that the latter does not pop up a
>DOS window while it is active, so having a gnuclientw
>process stick around until the file is finished with
>in Emacs should not cause any distraction.

In my experience, neither makes an unminimized DOS
window.  Using gnuclientw or using gnuclient with the
-q, the minimized window disappears almost
immediately.  For gnuclient without the -q, the
minimized DOS window does stick around (apparent only
on the task bar) until the buffer is released.  This
is the behaviour you would expect, since the client
cannot be waiting on gnuclient to finish unless the
instance of gnuclient started by the client is still
running (in its DOS window).


I meant it literally when I said that, if you look at
the code, you will see that gnuclientw and gnuclient
with the -q argument must behave identically.  (What
confused me for years was that they actually seemed to
behave differently for a shortcut; but I was
misinterpreting the symptom.  Note that Edi Weitz was
making the same wrong assumptions about target
specifications for shortcuts that I had been making.)

Regards,
  David V.