[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h-e-w] gnuserv maintenance

From: David Vanderschel
Subject: Re: [h-e-w] gnuserv maintenance
Date: 28 Oct 2004 23:13:56 -0500

On Thursday, October 28, "Guy Gascoigne-Piggford" <address@hidden> wrote:

>Jason Rumney wrote:

>> Matthew X. Economou wrote:

>>> (1) gnuclientw exits immediately after sending the file to Emacs,
>>> i.e. "-q" is always set.

>> Many people consider this a feature, but I agree with you. Since there
>> is no Window associated with gnuclientw, users will not notice that it
>> hangs around until the buffer is killed, so I don't know what the
>> rationale behind the current behaviour is

>Now that you mention it, I'm not sure that I can come up with a good
>explanation either :(  I do know that it seemed like a really good idea
>at the time, but that's not really a whole lot of help.  As you say,
>there's no window so why should anyone care about a tiny process hanging

Embedded in my last posting is a rationale for why
gnuclientw needs to exist in addition to the the -q
flag for gnuclient.  (Guy, there are many other
comments in that message of which I hope you guys
working on improving the gnuserv-type functionality in
emacs will take note.  That you make the above remark
suggests to me that you have not actually read my
message yet.  Please do so.)  Briefly, the rationale
has to do with a lame way in which Windows treats
parameters in the target specification of a shortcut
when you drag and drop onto it.  I don't know if this
was the actual original reason; but I have groped for
such an explanation for years, and this possibility
finally occurred to me this week - also resolving a
mystery of function which had dogged me for years.

(Note that the original problem (with shortcuts) could
also have been solved with a batch file (in which the
-q flag would be seen) and a PIF.)

  David V.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]