bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#549: emacsclient or emacsclientw not waiting in Windows


From: Lennart Borgman (gmail)
Subject: bug#549: emacsclient or emacsclientw not waiting in Windows
Date: Tue, 15 Jul 2008 09:37:32 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

Vesa Suontama wrote:
Hi,

thanks for clarification. It seems now that I was not testing
emacsclient at all, since now when I test it it works. I am very sorry
for misleading bug report.

I was not aware that emacsclientw does not wait, and thought that the
only difference there is that emacsclientw is compiled as windows
binary, which does not create (or use) a console.

Just to not confuse any readers:
emacsclientw.exe does wait. You can see it in Window Task Manager. However the console window does not wait for emacsclientw.exe since it is not a console app.

This is quite sorry state of affairs, that windows needs to have
two emacsclient versions. (At least when the difference is not that
well or at all explained IMHO).

You can always use emacsclient.exe if you want to. The drawback is that you will see an extra console window for each invocation of it.

It would be interesting to know why you just cannot have one
emacsclient for windows? Would it be too complex to go around the
issue of having two emacsclient versions the same way as MS does (Yes,
I know this is insane, but look many MS utilities e.g. devenv).

It works like this: have emacsclient.com and emacsclient.exe, where
new emacsclient.exe is the old emacsclientw.exe, and emacsclient.com
is just a wrapper that calls the emacsclient and waits for it to
finish (e.g. by using a named event, which emacsclient.com waits).

Please try to write some code for this so we can test it.

Console programs use .com version by default (when only "emacsclient"
is called), and win32 uses .exe. We cannot directly rename
emacsclient.exe to emacsclient.com because there is a restriction that
com files can only be less than 64 kb.

The other way around could be to use "AttachConsole" etc. from
emacsclientw (and rename it to emacsclient), but all this is just guessing
as I do not know the real reason for emacsclientw.

If you know how to do this then please try writing some code for that so we can test that. This may be a better solution than the one above.

I would like to hear from you, but understand if you are too busy.

Thanks for your help anyway.

BR,

Vesa

-----Original Message-----
From: Lennart Borgman (gmail) [mailto:address@hidden
Sent: 14. heinäkuuta 2008 18:39
To: Vesa Suontama; address@hidden
Cc: address@hidden
Subject: Re: bug#549: emacsclient or emacsclientw not waiting in
Windows

Vesa Suontama wrote:
Hi,

I have a Windows Vista SP1, and when using emacsclient or
emacsclientw,
they always return immediately with return value 1, and do not wait
making it useless as EDITOR for command line utilities which should
wait.
I use the emacsclient from cmd.exe and not from cygwin. I also
started
emacs with –q, and started server manually after that, so no startup
file should be causing this.

Is this a known issue?

Otherwise I love emacs :)

Vesa

In GNU Emacs 22.2.1 (i386-mingw-nt6.0.6001)

 of 2008-03-26 on RELEASE

Windowing system distributor `Microsoft Corp.', version 6.0.6001

I do not have Emacs 22 here. However I just tested with CVS Emacs 23,
both unpatched and the patched version that comes with Emacs+EmacsW32.
I
saw no problem, both emacsclient and emacsclientw waited as expected.

Some notes:

- Please use -Q (uppercase), not -q (lowercase). -q will still run
site-start.el

- If you test from a console window (running cmd.exe) then please note
that emacsclientw can not make cmd.exe wait for it. I can't remember
the
technical terms for it but w here stands for "window, GUI". Program
linked as GUI applications do not use a console window (by default).
They can not write to a console and if started from a console the
console will not wait for them.








reply via email to

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