headers
Matthew X. Economou | 1 Nov 2004 04:27

RE: gnuserv maintenance

> -----Original Message-----
> From: help-emacs-windows-bounces On Behalf Of Richard M. Heiberger
> Sent: Saturday, October 30, 2004 5:46 PM
> 
> This discussion is getting too complex for a simple topic.

Since my use for gnuclientw is very different from what is typical,
since Guy is still actively maintaining the sockets version of
gnuserv/NT, and since a Windows port of emacsclient is in progress, I
will not take over maintenance for gnuserv/NT.

I have a privately hacked together version of the mailslots version of
gnuserv that doesn't default to "-q" for the Win32 app gnuclientw and
that de-iconifies Emacs if "-F" is set.  It compiles cleanly under
VS.NET using nmake.  If you are interested in a copy, please contact me
off-list.

Best wishes,
Matthew

--

-- 
"$30 for the One True Ring. $10 each additional ring!"
			- JRR "Bob" Tolkien
Permalink | Reply | 0 comments |
headers
David Vanderschel | 1 Nov 2004 05:23
Picon

Re: gnuserv maintenance

On Saturday, October 30, "Lennart Borgman" <lennart.borgman.073 <at> student.lu.se> wrote:
>----- Original Message -----
>From: "Richard M. Heiberger" <rmh <at> temple.edu>

>: Because emacs accepts drag and drop there is no point to dragging and dropping
>: onto the gnuclientw icon.

>In a way I agree, but different users think differently. Some seems to like
>the desktop icon they can drop files on. I never see the desktop (neither on
>my pc or in the physical world ;-)

Though I admit that I do not use the drop target much,
I also mentioned that I put it on the Quick Launch bar
so that other windows cannot cover it up.  I agree
that, otherwise, it would be very useless indeed - as
you might as well drop your file onto an emacs frame.

Regards,
  David V.
Permalink | Reply | 0 comments |
headers
David Vanderschel | 1 Nov 2004 05:33
Picon

Re: gnuserv maintenance

On Saturday, October 30, "Richard M. Heiberger" <rmh <at> temple.edu> wrote:
>This discussion is getting too complex for a simple topic.

Indeed.  That is why I tried to start at least one
new thread in which I suggested to forget about the
drop target as a requirement for gnuclientw.

>I send a file (under program control) to gnuclient if
>I want to edit it ...

>I send a file to gnuclientw if I want to display it
>in emacs.  ...

It should be realized that what Richard is saying here
concerns proper use of gnuclient and gnuclientw AS
THEY PRESENTLY EXIST!  I believe that some folks have
been talking about gnuclientw AS THEY WISH IT TO BE.
This is one source of the confusion.

>Because emacs accepts drag and drop there is no point
>to dragging and dropping onto the gnuclientw icon.

Unless there is no emacs frame open and the icon
exists on the Quick Launch bar.

>gnuclientw does the right thing in the background so
>the file is displayed in the current instance of
>emacs.  When it has completed its task it vanishes.

As far as I can recall, the above comment addresses an
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Vanderschel | 1 Nov 2004 05:44
Picon

Re: gnuserv maintenance

On Saturday, October 30, "Guy Gascoigne-Piggford" <guy <at> wyrdrune.com> wrote:
>Personally the thought of having a lot of gnuclients
>hanging around in the process list for absolutely no
>reason strikes me at ugly.

Me too.  I would go farther.  I would try hard to
avoid it.

>I do realise that they aren't awfully significant
>from a memory point of view and eventually the
>sockets will time out and close then the gnuclient
>will just go away anyway, 

But this is an undesirable behaviour for which a
workaround is clearly needed.  The TCP/IP timeout is
way too short for significant editing, and we do not
want the application/client to continue with the as
yet not edited file.  Can you not add some sort of
stay-awake message exchange?

It should also be noted that this undesirable
behaviour does not currently occur with the mailslot
version.

>To be completely honest I've not come across a single
>Windows (not console) app where I'd want to install a
>separate editor and have it wait for the result, I'm
>not saying that they don't exist, just that it's
>really easy to use Windows a lot for a lot of divers
>things and never come across this need.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kinnucan | 1 Nov 2004 05:51
Picon
Favicon

Re: gnuserv maintenance

Jason Rumney writes:
 > "Lennart Borgman" <lennart.borgman.073 <at> student.lu.se> writes:
 > 
 > > And yes I did have spec for emacsclient in my head. It looks like there are
 > > the same difficulties there since emacsclient has a switch --no-wait (-n).
 > > Maybe just adding -w would be the best there too. The differences between
 > > emacsclient and emacsclientw with regard to default behaviour must then be
 > > the same to get things working on ms windows.
 > 
 > What exactly doesn't work when the default behaviour is to not wait?
 > 
 > Previously David was confused and thought that DOS boxes would stay
 > around for Explorer users, but with gnuclientw they don't. I have yet
 > to see anyone put forward any other reason why gnuclientw needs to
 > exit immediately.
 > 
 > Who knows what programs someone might want to use gnuclientw
 > from. Some of them might have the same bug as Explorer Shortcuts on
 > Windows 9x and NT where they cannot specify any arguments. I think it is
 > more important that gnuclientw and emacsclient works for them than for
 > it to exit immediately just because some people happen to like it as
 > the default behaviour with no justification.

I agree. It would be very nice to enable standard I/O for 
gnuclientw/gnuclient and allow the external process to pass
arbitrary Lisp expressions to the standard input of Emacs for
evaluation and to pass the results to the standard input
of the external process. I've done something like this for
the Java Development Environment for Emacs. The JDEE has an interface
between Emacs and a Java interpreter in which Java programs running
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Vanderschel | 1 Nov 2004 06:11
Picon

Re: gnuserv maintenance

On Saturday, October 30, "Lennart Borgman"
<lennart.borgman.073 <at> student.lu.se> wrote:
>- Gnuclientw is the preferred program to call from
>other program when Emacs should act as an "edit
>server". The reason for this is that is has no
>associated console window ("dos box"), since it is
>compiled as a windows application (while gnuclient is
>compiled as a console application - and those always
>has a console window).

Clearly you are not talking about any current
incarnation of gnuclientw because they cannot be made
to wait.  You are talking about what you would like to
transform gnuclientw into.

I think the more reasonable thing to say here is that
something linked as a win32 application would be the
preferred program ...

>Gnuclientw has to wait for the editing to finish and
>it does not do that by default.

As far as I know, it (as it presently exists) does
not wait under any circumstances.

>Hence I suggested a new -w flag. The default
>behaviour to not wait can not be changed unless we
>want gnuclientw processes hanging around on some ms
>windows versions (NT, Win98 ...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Vanderschel | 1 Nov 2004 06:54
Picon

Re: gnuclient - Forget the drop target. Was: gnuserv maintenance

On Friday, October 29, "David Vanderschel" <DvdS <at> Austin.RR.com> wrote:
>... For those who still want a drop target shortcut,
>there is still the PIF approach where one has better
>control over the passing of the arguments.  Four
>years ago I might have complained that the overhead
>for the PIF solution was too great.  (It took 3
>seconds on my 350MHz AMD K-6.)  Nowadays, I think the
>extra overhead is a non-issue.  (I could be on shaky
>ground here if the PIF concept itself does not carry
>over cleanly from, say, 98 to XP.)

Let me offer the simple batch file I concocted some
time back:

______________________________________________________________________
if "%1"=="" goto nofile
d:\emacs\emacs-20.7\bin\gnuclientw.exe -F "%1"
goto done
:nofile
d:\emacs\emacs-20.7\bin\gnudoit.exe -q (dv-focus-initial-frame)
:done
exit
______________________________________________________________________

If you put in a reference to a .bat file like the
above (modified as appropriate for your installation)
as the "Cmd. line" for a shortcut, you get a PIF-type
shortcut which behaves in the manner Edi sought
without advising find-file.  Though I rarely use the
drop-target feature, I would more often use this icon
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guy Gascoigne - Piggford | 1 Nov 2004 20:09

Re: gnuserv maintenance

David Vanderschel wrote:

>On Saturday, October 30, "Guy Gascoigne-Piggford" <guy <at> wyrdrune.com> wrote:
>  
>
>>I do realise that they aren't awfully significant from a memory point of view and eventually the sockets
will time out and close then the gnuclient
>>will just go away anyway, 
>>    
>>
>
>But this is an undesirable behaviour for which a
>workaround is clearly needed.  The TCP/IP timeout is
>way too short for significant editing, and we do not
>want the application/client to continue with the as
>yet not edited file.  Can you not add some sort of
>stay-awake message exchange?
>
>It should also be noted that this undesirable
>behaviour does not currently occur with the mailslot
>version.
>  
>
I've noticed that as well, mailslots are just handled differently.  I'll 
take a look at how best to change the tcp timeout issue, it's certainly 
a pain the way that it is.

>>So I guess I'm saying that what the correct behaviour
>>is, is all dependant on what your end goal actually
>>is.  My take on this was attempting to make Windows
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guy Gascoigne-Piggford | 2 Nov 2004 17:44

Re: DOS boxes and gnuclient vs. gnuclientw

The problem is that there is sometimes useful information returned by 
gnuclient(w) or gnudoit and this goes to the console.  If the app is 
built as a windows app then this information gets lost.  Even if the 
windows app is run from a console, you still can't write to it.

 From looking at the Windows APIs there actually might be a way to 
improve this under XP or Server2003, there are now a couple of APIs that 
allow for attaching to an existing console, so it might be possible to 
work around this to a degree, but my concern is that this attachement 
comes very late in the startup of the aplication, by which time any 
inherited file handes (stdin/stdout/stderr) have been lost, if they were 
ever passed in that is.

So there is an angle to look at here at least for newer OSs, but I've 
only been reading the docs, I've not really delved into this much yet.

 From a Windows app, either the shell or another application, I agree, 
there is little need to use the command line versions, but from a 
command line they still have their uses.

Guy

Ludwig, Mark wrote:

>One aspect of the Windows platform has been a gradual migration away
>from "console apps."
>
>Thus, if we want to be working in the direction Microsoft advocates, I
>suggest that gnuclient go away and that its ability to wait for a user
>to edit something be added to gnuclientw -- assuming it's possible to do
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ludwig, Mark | 2 Nov 2004 22:13

RE: DOS boxes and gnuclient vs. gnuclientw

The "Windows way" would be to make the text that otherwise would go to
the console (stdout/stderr, I assume) go to a pop up of some sort.
Multiple-line stuff should go to a text box with scrolling, etc.

Mark

-----Original Message-----
From: Guy Gascoigne-Piggford [mailto:guy <at> wyrdrune.com] 
Sent: Tuesday, November 02, 2004 10:44 AM
To: Ludwig, Mark
Cc: help-emacs-windows <at> gnu.org
Subject: Re: [h-e-w] DOS boxes and gnuclient vs. gnuclientw

The problem is that there is sometimes useful information returned by 
gnuclient(w) or gnudoit and this goes to the console.  If the app is 
built as a windows app then this information gets lost.  Even if the 
windows app is run from a console, you still can't write to it.

 From looking at the Windows APIs there actually might be a way to 
improve this under XP or Server2003, there are now a couple of APIs that

allow for attaching to an existing console, so it might be possible to 
work around this to a degree, but my concern is that this attachement 
comes very late in the startup of the aplication, by which time any 
inherited file handes (stdin/stdout/stderr) have been lost, if they were

ever passed in that is.

So there is an angle to look at here at least for newer OSs, but I've 
only been reading the docs, I've not really delved into this much yet.
(Continue reading)

Permalink | Reply | 501 comments |

Gmane