help-emacs-windows
[Top][All Lists]
Advanced

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

Re: [h-e-w] gnuserv maintenance


From: Guy Gascoigne - Piggford
Subject: Re: [h-e-w] gnuserv maintenance
Date: Fri, 29 Oct 2004 10:55:03 -0700
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

So I did a bit of testing on Windows XP.

First it had actually never occurred to me to use a gnuclient shortcut as a drop target, so if there are quirks there it's not a surprise that they eluded me.

1) whilst there are quite a few flags that can be used on gnuclient(w), the only ones that seem to be generally relevant on NT are -q and +line.

2) I created a shortcut on my desktop that pointed to gnuclient.exe -q. When I dragged a file onto it, it loaded the file in emacs as you'd hope and gnuclient exited. So at least on XP the command line args are being passed through correctly. The only annoyance is that you need to set the shortcut to run as minimized otherwise the dos box flashes on the screen.

3) I do think that on a slower machine even a minimized dos box would be seen as a nuisance so there may well still be a use for a windows app and not just a console app.

I have to say that I simply have an gnuclientw shortcut in my SendTo folder, and that works perfectly for me.

Is any of the behavior that I describe different on Win98? As far as I can see so far everything is working exactly as expected, and the only change coming out of this part of the discussion so far would be some way to optionally negate the -q, I've seen -w (for wait) mentioned, and that seems like a good idea.

Did I miss anything?

Guy

David Vanderschel wrote:

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.










reply via email to

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