Re: [h-e-w] gnuserv maintenance

[David Vanderschel]

On the subject of updating gnuserv, I have a number of
comments about problems with gnuserv which need to be
addressed.  Below, I am responding to comments from
multiple persons who have posted in this thread.  I
offer a couple of new issues at the end.


On Tuesday, October 26, "Matthew X. Economou" <address@hidden> wrote:
>(2) Merge the mailslot version.

>(I don't know if there is a maintainer for the
>mailslot version of gnuserv.  I also don't purport to
>understand how the mailslot version works.)

>Since not every Windows computer is a single-user
>workstation, and since I don't want to tackle the
>problem of authenticating and securing the socket
>connections (which requires changes to the Unix
>version of gnuserv), I would like to, at some point,
>merge the socket and mailslot versions of gnuserv, so
>users have the option of running a version of gnuserv
>that cannot be accessed over the network or loopback
>interfaces.

As I read the documentation on mailslot, the mechanism
can also be used over a network.  However, the
mailslot version of gnuclient does not break (for
processes on the same machine) if you shut down TCP/IP
on your machine.  (The socket version of gnuclient
stops working for me if I just tell Zone Alarm to
"Stop all Internet activity.".)  The fact that the
mailslot version works even without a network running
is certainly a virtue when gnuserv and its client are
running on the same machine.  Even with a (mainly)
sockets version, it would be good if there were a way
to bypass the network in such a situation.  From my
(admittedly limited) point of view, the functionality
of mailslot actually seems better adapted to this
problem than does that of sockets.  I can only suppose
that the sockets approach provides greater networking
generality.  (But it could also be that the sockets
approach merely admits an implementation more similar
to that seen for Unix type environments.)

>(4) Set up an issue tracker.

>I have a Plone site that I could use, or I could set
>up bugzilla or something else.  Maybe I'll host this
>all on Sourceforge or something.

Given how little evolution there has been on the
gnuserv front over the last several years, this may be
overkill.  ;-)

>(5) Re-write the gnuserv documentation.

You mean create some, huh?  Many of us have struggled
for lack of such.  My tips on the subject from some
time ago:

    http://groups.yahoo.com/group/ntemacs-users/message/12487


On Tuesday, October 26, "Windhorn, Allen, E. [LS/MKT]" <address@hidden> wrote:
>Excellent!  What about the bug that afflicts my machine (Windows 2000), so
>that when I "start" a text file, it brings up a new copy of Emacs, which
>then complains that it wasn't given a proper file?  (The mailslot version
>works.)  Or is this the same as one you mentioned?

I do not see such a bug under Windows 98.  This is the
symptom if gnuclient cannot find a running copy of
gnuserv.exe.  I wonder if, for some reason, there is no
running copy of gnuserv.exe associated with the
original instance of emacs.  (This should be easy to
check.) 


On Tuesday, October 26, "Richard M. Heiberger" <address@hidden> wrote:
>I have been under the impression that the sole difference between
>gnuclient and gnuclientw is that the -q flag is always set for gnuclientw.

If you look at the code, that is precisely true.  Yet
I have observed (what I thought at the time was)
different behaviour.  In my old tips article, I
mentioned:

    I have another shortcut, named simply
    "emacs". with the following command:

        %EMACS_BIN%\gnuclientw.exe -F "%1"

    Note the "w". (For some reason which I do not
    understand in this drag and drop case, the -q flag
    to gnuclient is not sufficient to prevent the
    resulting buffer from 'believing' that there is a
    client waiting on it. Looking at the code, I see
    no difference between gnuclientw and gnuclient
    invoked with the -q flag. Yet "gnuclientw" works
    while "gnuclient -q" does not. So this is a
    mystery. I have to suspect that those two .EXE's
    in the gnuserv package were not linked the same
    way.)

I was using the mailslot version back then.  I get the
same behaviour with the sockets version.  I have now
realized that it is probably the case that the "-q"
switch is not picked up from the target specification
in the shortcut, and I see no way around the problem
in the context of a Windows shortcut.  Indeed, when I
look at the shortcut I am using now, neither the -F
nor the "%1" are in it.  (I cannot remember why I
removed them, but it appears that they would not be
effective anyway.)  Nevertheless, my frames usually do
come visible at the front even without the -F.  If I
put quotes around the entire specification _with_ the
parameters, Windows claims that it cannot find the
target.  As far as I can tell, anything after the path
to the executable in the target specification is
ignored when you drag and drop (but not if you double
click the shortcut).  Indeed, this may be the reason
for the existence of gnuclientw as opposed to
gnuclient -q.  (I suspect (but can no longer remember
for sure) that this problem is one of the reasons I
was advocating using Winkey rather than Windows
shortcuts; but, for drag-and-drop, it had to be a
Windows shortcut.)

I note that Edi Weitz also had parameters in the
shortcut target he suggested.  The main difference I
see without them is that just double-clicking the
associated icon does nothing.  (With no argument,
gnuclient just prints some help in the command
window.)  This is actually preferable to opening a
file with name "%1", which difficulty Edi experienced.
As far as I can tell, when shortcuts are used with
drag-and-drop, Windows provides the file argument by
default.  I also note that, with both arguments
present in the target for the shortcut, the file named
"%1" which results from double clicking the shortcut
_does_not_ believe there is a client waiting on it.
Ie., when gnuclient sees the literal "%1", it _also_
sees the -q.  So I suspect it sees neither with
drag-and-drop.  

I also note that, if I supply an actual file-argument
path in the target specification, it is ignored for
drag-and-drop; but, if I just open the shortcut icon,
the file specification works.  With an appropriate
default file, this could be a feature.  Unfortunately,
if the file does not exist, a second opening of the
shortcut while the "new file" buffer exists encounters
problems with internal emacs logic.  So, if you do
this, you should probably specify a file which exists.
I have now specified the path to a folder which
contains miscellaneous files, a directory to which I
frequently refer for various reasons.  Thus clicking
on my drag-and-drop shortcut (which I keep on the
Quick Launch bar so that it cannot be buried by other
windows) now brings up a dired listing for that
directory.  I like it!  


On Tuesday, October 26, "Matthew X. Economou" <address@hidden> wrote:
> problem is that gnuclientw forces -q on, not that it
> is on by default.  If defaulting "-q" on for
> gnuclientw is the expected behavior, then I will
> cause -q to toggle the quick flag instead, because
> Zope ExternalEdit relies upon the called editor only
> exiting when the user finishes editing the
> downloaded file and because I prefer not to pop up a
> console window for every edited file.

See my response to Heiberger's comment above.  The
behaviour you observe for gnuclientw is definitely the
intended behaviour of gnuclientw; and, as far as I can
tell, it is the only reason for the existence of a
gnuclientw separate from gnuclient.  Matthew, you
should not change it because there are plenty of folks
depending on the current behaviour; but the solution
to your editing problem is simple: Just use gnuclient!
(without the -q)  Because it seemed like a kluge to
have the separate programs, I never advocated use of
gnuclientw in my tips, _except_ for that shortcut
case.  (But I did suggest use of -q in appropriate
cases.  I have only just come to realize that the
kluge was probably introduced just to work around the
peculiar way Windows treats parameters in the target
specification of a shortcut.)

The console window _should_not_ be visible.  I believe
that there _is_ a bug in this area.  Indeed I
commented on it back in 2000:

    For reasons I do not understand, the DOS window
    associated with a gnuclient or gnudoit invocation
    sometimes persists on my system, though it is
    supposed to close when the task terminates.  (If a
    DOS window persists inappropriately for you, just
    hit Ctrl-c when that window has focus.)
    Furthermore, the DOS boxes sometimes run focussed
    instead of minimized.  This can be a more serious
    problem, as it appears that emacs has difficulty
    when it comes to automatically wresting focus from
    a DOS window, though it sometimes succeeds anyway.
    When these problems are occurring, the occurrences
    are sporadic and I see no particular pattern to
    either the focussed or non-closing behaviours.
    More mysteries.  If anyone knows how to prevent
    these strangenesses, please let me know.  Neither
    problem seems to occur early after I reboot, and
    they don't seem to occur when I have only a few
    tasks running.  I suspect there is some resource I
    need more of, but I don't what it is.  If there is
    a place for setting the defaults for such DOS
    boxes similar to the settings you can make on a
    PIF object, I'd like to know about it.

I continue to be annoyed by such inconsistencies, so I
would like to see this fixed.  

A related problem which I have only noticed recently
is the following:  If I have a DOS window open (not
minimized, not focussed) and I do a gnuclient or
gnudoit operation, the _already_existing_ DOS window
momentarily gets the focus before the resulting emacs
frame does.  Not a serious problem, but surprising, as
the DOS window which briefly pops to the fore is not
the one which is running gnuclient.  This behaviour is
consistent when there has been only one such
(interactive) DOS window.  It is somewhat annoying
because the DOS window which pops to the front remains
in front after the resulting emacs frame is closed.
This is not the same state the desktop was in before
gnuclient was invoked.  IMO, gnuclient should not
shuffle the already-existing windows.  If I open a DOS
window, bury it, open another, and close the _second_,
then the peculiar behaviour need not occur with the
original remaining DOS window (but does sometimes
anyway).

Incidentally, when I was experimenting with the above
issues, emacs and the system in general seemed to get
extremely bogged down at some points.  Eventually, I
even crashed Windows 98.  This suggests that the
problem may be 'deep'.  (Thank goodness that emacs
maintains a backup of copy of what you are working
on.  I would have been upset if I had had to retype
the bulk of this message.)


Another problem with gnuserv which needs to be
addressed is the following:  Alas, emacs itself does
occasionally crash.  When it does so, the copy of
gnuserv.exe it started continues to run.  If you try
to start a new instance of emacs, things get fouled up
because an instance gnuserv is already running.  I
have to use the Close Program dialogue to kill off the
old instance of gnuserv before I can successfully
restart emacs.  It seems to me that this is a
situation which can be recognized and worked around.
However, it is not a gnuclient problem - it is an
emacs startup problem.  Perhaps someone could offer a
batch file or some other sort of script which will
kill off any existing instance of gnuserv before
calling runemacs; and we could use that script in lieu
of runemacs.  Perhaps it can even be done in elisp
before starting gnuserv, in which case gnuserv-start
should be improved in this way.  Unfortunately, though
it sounds simple to do, my own expertise is not
sufficient to accomplish this.


Regards,
  David V.