Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: (myself), Thursday, February 21, 2013 9:56 AM
> Subject: RE: Best practices for launching Emacs on Windows 7/8
> 
> When I looked back at what I had on Vista, I found that I was
> using Emacs 23.1 and working around a bug in emacsclientw that,
> if Emacs wasn't running as a server, insisted on popping up an
> error dialog box that had to be manually dismissed.  

This bug still exists.  The first time emacsclientw.exe
attempts to find a running Emacs daemon after restarting
Windows, it pops up a dialog that must be manually
dismissed.  The dialog says:

c:\<...>\emacsclientw.exe: connect: No connection could be
made because the target machine actively refused it.

This behavior has been there for a long time, and would seem
easy to fix.  Doesn't anyone else hit this?

Thanks,
Mark Ludwig

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Richard Copley]

On 19 June 2013 19:17, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> This bug still exists.  The first time emacsclientw.exe
> attempts to find a running Emacs daemon after restarting
> Windows, it pops up a dialog that must be manually
> dismissed.  The dialog says:
>
> c:\<...>\emacsclientw.exe: connect: No connection could be
> made because the target machine actively refused it.
>
> This behavior has been there for a long time, and would seem
> easy to fix.

You mean "SetErrorMode(SEM_NOOPENFILEERRORBOX)"? Might be worth a try.
Did you create a bug report?

> Doesn't anyone else hit this?

I've never noticed it before, but it's easy enough to reproduce (run
emacs, start server, kill emacs, run emacsclientw).

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Wed, Jun 26, 2013 at 8:47 PM, Richard Copley <rcopley@gmail.com> wrote:

> I've never noticed it before, but it's easy enough to reproduce (run
> emacs, start server, kill emacs, run emacsclientw).

Could you please file a bug report with a step-by-step recipe starting
from emacs -Q (if possible)?

Thanks,

   Juanma

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Juanma Barranquero, Wednesday, June 26, 2013 6:12 PM
> 
> On Wed, Jun 26, 2013 at 8:47 PM, Richard Copley <rcopley@gmail.com> wrote:
> 
> > I've never noticed it before, but it's easy enough to reproduce (run
> > emacs, start server, kill emacs, run emacsclientw).
> 
> Could you please file a bug report with a step-by-step recipe starting
> from emacs -Q (if possible)?
> 
> Thanks,
> 
>    Juanma

Okay, I will file a formal report, but first I want to make sure
others see the problem.  I also need to understand what to include in
the report.

Firstly, the problem is only reproducible (for me) by restarting
Windows.

Secondly, it does not involve emacs(!).  The problem is purely in
emacsclientw.exe.  Therefore, there is no .emacs involvement, so using
-Q also does not apply.

I am not aware of any configuration aspects to this error.  I am not
saying there are no configuration aspects, but I am not aware of any.

That said, I have set the ALTERNATE_EDITOR environmental variable to
the full path of runemacs.exe.  I doubt it matters w.r.t. the problem,
precisely, but the overall success scenario is based on
ALTERNATE_EDITOR being set.

The idea is to set up my Windows environment so that when I
double-click on a file that is associated with emacsclientw.exe, I get
a window (Emacs "frame") with the file available for editing.  If
Emacs is running as a server, that process pops up a new frame
(according to my .emacs); if Emacs server is not running, according to
ALTERNATE_EDITOR, Emacs gets started (by "runemacs").  (Now that I
think about it, my .emacs starts the server, naturally, so for that
reason, I don't think it even makes sense to attempt to use emacs -Q
anywhere in this reproduction scenario.)

The first time after restarting Windows, when I double-click on a file
that is associated with emacsclientw.exe, I have to dismiss the dialog
that I seek to eliminate.  Only after dismissing the dialog will the
alternate editor be invoked.  (I would not mind so much if the
alternate editor was launched asynchronously, not waiting for me to
respond to the dialog.)  The error message in the pop-up dialog that
must be dismissed is the long-winded Windows version of the UNIX error
"Connection refused": "No connection could be made because the target
machine actively refused it."

I am a network programmer, and the error message makes perfect sense:
it is simply saying there is no process listening.  That is absolutely
true!  It's also not something I want to confirm, because it's
patently obvious, and completely uninteresting -- at least in my case,
because I have the ALTERNATE_EDITOR variable (or the
--alternate-editor option) set.  AFAICT, the error only occurs if
Emacs server has never been started in the current running instance of
Windows.

What should I put in the bug report, exactly?

Thanks,
Mark

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 2:04 AM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> Secondly, it does not involve emacs(!).  The problem is purely in
[...]
> "Connection refused": "No connection could be made because the target
> machine actively refused it."

Hm. I'm going to borrow the cristal ball from a friend and ask: Do you
exit Emacs before turning off your computer?

As you start Windows and before trying emacsclientw.exe, if you look
at %HOME%\.emacs.d\server (whenever your %HOME% happens to be), do you
find there a file named server?

If so, does the problem disappear if you delete that file before
running emacsclientw.exe for the first time?

   J

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Juanma Barranquero, Wednesday, June 26, 2013 7:35 PM
> 
> On Thu, Jun 27, 2013 at 2:04 AM, Ludwig, Mark <ludwig.mark@siemens.com>
> wrote:
> 
> > Secondly, it does not involve emacs(!).  The problem is purely in
> [...]
> > "Connection refused": "No connection could be made because the target
> > machine actively refused it."
> 
> Hm. I'm going to borrow the cristal ball from a friend and ask: Do you
> exit Emacs before turning off your computer?

Usually, yes (because if I haven't saved in every buffer, I don't like
leaving auto-save files around).

> As you start Windows and before trying emacsclientw.exe, if you look
> at %HOME%\.emacs.d\server (whenever your %HOME% happens to be), do you
> find there a file named server?

Not usually, no, but if I deliberately leave Emacs running when
telling Windows to restart, then I do find a "server" file in that
directory (and the pop-up error appears).

> If so, does the problem disappear if you delete that file before
> running emacsclientw.exe for the first time?

Yes.

I was not aware that I was not exiting Emacs, but in a hard Windows
abort/restart, of course, there is no opportunity to exit Emacs.
Still, I appreciate that the problem is arguably external to Emacs.

That said, the pop-up error really shouldn't need dismissal by the
user when there is either ALTERNATE_EDITOR or --alternate-editor.  In
that configuration, it's not clear that the error should even be
reported -- except perhaps as a warning (to inform the user why the
alternate editor was launched).

Thanks!
Mark

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 3:29 PM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> I was not aware that I was not exiting Emacs, but in a hard Windows
> abort/restart, of course, there is no opportunity to exit Emacs.
> Still, I appreciate that the problem is arguably external to Emacs.

It is difficult to fix from Emacs. Even if we used WM_ENDSESSION to
clean up the server file, that would only work for "clean" exists, not
crashes. And even so, Windows 7 has a hard time limit for shutdown and
it's not guaranteed that you'll have time to do proper cleanup.

> That said, the pop-up error really shouldn't need dismissal by the
> user when there is either ALTERNATE_EDITOR or --alternate-editor.  In
> that configuration, it's not clear that the error should even be
> reported -- except perhaps as a warning (to inform the user why the
> alternate editor was launched).

The error says that emacsclientw found a server file for a process it
could not connect. That is useful. For example, emacs could still be
running, just not attending to server connections for some reason.
It's better to give the user the information *and* let him decide (by
clicking on OK, or doing something else) how to fix things.

As for a workaround, I can think of two: set some .CMD script in the
StartUp folder to clean any stale server file. Or, if running Emacs is
part of most or all of your Windows sessions, start Emacs itself
(perhaps with --iconic) from StartUp, so it takes care of the stale
file and the first emacsclientw.exe will already find it running and
ready to serve.

    Juanma

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Juanma Barranquero, Thursday, June 27, 2013 9:02 AM
> 
> On Thu, Jun 27, 2013 at 3:29 PM, Ludwig, Mark <ludwig.mark@siemens.com>
> wrote:
> 
> > That said, the pop-up error really shouldn't need dismissal by the
> > user when there is either ALTERNATE_EDITOR or --alternate-editor.  In
> > that configuration, it's not clear that the error should even be
> > reported -- except perhaps as a warning (to inform the user why the
> > alternate editor was launched).
> 
> The error says that emacsclientw found a server file for a process it
> could not connect. That is useful. 

I don't agree.  Why is it useful to make the user click OK (the only
available button) /before/ launching the alternate editor?

> For example, emacs could still be
> running, just not attending to server connections for some reason.
> It's better to give the user the information *and* let him decide (by
> clicking on OK, or doing something else) how to fix things.

Let's say you're correct that there is a running Emacs that's not
responding, so the dialog information is reporting an "interesting"
situation.  I claim that it /still/ doesn't matter, because
emacsclientw has made its only attempt to connect to the
supposedly-running server (which failed) and all the user can do is
click OK, after which emacsclientw will launch the alternate editor
(if any).  If there were a "Retry" button, that would be /very/different.

What else do you think I can do before clicking OK?  As far as
investigating what's wrong with a running Emacs, it doesn't matter
whether I look before or after clicking OK, because emacsclientw has
done whatever it's going to do to the running Emacs, and the alternate
editor (in my case) will be a separate instance of Emacs.

Thanks,
Mark

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 4:28 PM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> I don't agree.  Why is it useful to make the user click OK (the only
> available button) /before/ launching the alternate editor?

Because if we don't say anything, the user won't be aware that there's
a problem. In fact, if we didn't say anything, we would not be having
this conversation in the first place. That message tells the user that
Emacs exited unexpectedly. I agree that it is not useful for *your*
use case, but that does not mean that it is not generally useful. I,
for once, much prefer getting these error messages than not getting
them (so I can try and find what's going wrong behind my back).

> Let's say you're correct that there is a running Emacs that's not
> responding, so the dialog information is reporting an "interesting"
> situation.  I claim that it /still/ doesn't matter, because
> emacsclientw has made its only attempt to connect to the
> supposedly-running server (which failed) and all the user can do is
> click OK, after which emacsclientw will launch the alternate editor
> (if any).  If there were a "Retry" button, that would be /very/different.

I didn't say that Emacs is not responding, I said that Emacs is not
responding to server requests. Perhaps you inadvertedly deactivated
the server mode, and jus M-x server-mode <RET> will activate it again
without having to exit and reload Emacs. If that seems far-fetched to
you, well, it's happened to me more times that I could count.

   J

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Juanma Barranquero, Thursday, June 27, 2013 9:52 AM
> 
> On Thu, Jun 27, 2013 at 4:28 PM, Ludwig, Mark <ludwig.mark@siemens.com>
> wrote:
> 
> > I don't agree.  Why is it useful to make the user click OK (the only
> > available button) /before/ launching the alternate editor?
> 
> Because if we don't say anything, the user won't be aware that there's
> a problem. 

I am not saying that emacsclientw should not to say anything.  :-)  

I am saying that it should not wait for me to click OK before
proceeding to launch the alternate editor (if any).

Consider that the non-windows version (emacsclient) does just this.
It will issue the error message to the console and, since it's
non-interactive, it will proceed to launch the alternate editor (if
any).

> > Let's say you're correct that there is a running Emacs that's not
> > responding, so the dialog information is reporting an "interesting"
> > situation.  I claim that it /still/ doesn't matter, because
> > emacsclientw has made its only attempt to connect to the
> > supposedly-running server (which failed) and all the user can do is
> > click OK, after which emacsclientw will launch the alternate editor
> > (if any).  If there were a "Retry" button, that would be /very/different.
> 
> I didn't say that Emacs is not responding, I said that Emacs is not
> responding to server requests. Perhaps you inadvertedly deactivated
> the server mode, and jus M-x server-mode <RET> will activate it again
> without having to exit and reload Emacs. If that seems far-fetched to
> you, well, it's happened to me more times that I could count.

Sure, and I claim that this does still not change the uselessness of
waiting for the user to click OK before launching the alternate
editor.  Let's say you're correct that somehow the server was
deactivated, and all you need to do is reactivate it.  Nothing you do
in response to the dialog changes what will happen with that instance
of emacsclientw.  If you have an alternate editor, it gets launched
(unless you take the extraordinary steps necessary to kill the
emacsclientw process while the dialog is sitting there).  If you don't
have an alternate editor, you have to perform the action again after
fixing the Emacs server.

I certainly understand that my perspective is based on the fact that I
use alternate editor, but I didn't invent the concept; I'm just trying
to use it.

Thanks,
Mark

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 5:34 PM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> Consider that the non-windows version (emacsclient) does just this.
> It will issue the error message to the console and, since it's
> non-interactive, it will proceed to launch the alternate editor (if
> any).

User expectatives for a console program and a GUI one are quite different.

> Sure, and I claim that this does still not change the uselessness of
> waiting for the user to click OK before launching the alternate
> editor.  Let's say you're correct that somehow the server was
> deactivated, and all you need to do is reactivate it.  Nothing you do
> in response to the dialog changes what will happen with that instance
> of emacsclientw.

No, it's the fact that you click on the dialog, which means that you
saw the message. If it does not appear, or times out, perhaps you'll
miss it. Waiting for the user to acknowledge that s/he read a warning
is hardly something exclusive to emacsclientw.exe.

> I certainly understand that my perspective is based on the fact that I
> use alternate editor, but I didn't invent the concept; I'm just trying
> to use it.

I tend to think that the alternate editor is an error, but that's just me.

Anyway, if you feel that the behavior is wrong, use M-x
report-emacs-bug and file a bug report / enhancement request. Perhaps
someone who shares your view will be prompted to act on it.

Thanks,

   Juanma

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Juanma Barranquero, Thursday, June 27, 2013 3:50 PM
> 
> I tend to think that the alternate editor is an error, but that's just me.

How do you configure Emacs on Windows?  Do you use emacsclientw to do
anything like what I'm trying to do (make double-clicking on an
associated file "just work" no matter whether Emacs is already
running)?

Especially on W7/8, it's become impossible to configure non-trivial
associations in the GUI, because there is no ability to specify the
command name or any options.  I know how to do more via regedit or
other utilities, but I find it's usually better to take the lazy
approach and do things the way "regular" users usually will.  I can
associate emacsclientw.exe and I can set ALTERNATE_EDITOR in the
environment.

Cheers,
Mark

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 11:27 PM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> How do you configure Emacs on Windows?  Do you use emacsclientw to do
> anything like what I'm trying to do (make double-clicking on an
> associated file "just work" no matter whether Emacs is already
> running)?

I don't use file associations for Emacs. I'm a console guy through and
through, and launch almost everything from CMD (or, truth be told,
from TCC, the command line part of TakeCommand, a commercial product).

But as for the alternate editor: If you always use the -n/--no-wait
command line arg there's not much difference, but if you want
emacsclient.exe to stay connected to Emacs and wait for the user to
finish editing the file, "emacsclient MYFILE" is quite different of
running "alternate-editor MYFILE", because currently there's no way to
start the alternate Emacs editor and make it "connect back" to
emacsclient. Lennart Borgman's EmacsW32 was patched to allow it, and
seems to be a well liked feature, but his changes to emacsclient.c
have never been integrated back into Emacs proper.

What I do is run emacs from a script (a .CMD batch file) which makes
sure that emacs.exe is running and ready to answer client requests. If
not, it starts emacs and waits until it is. Only then does my script
call emacsclient.exe. It's a bit convoluted, but it works.

> Especially on W7/8, it's become impossible to configure non-trivial
> associations in the GUI, because there is no ability to specify the
> command name or any options.

You could write a trivial C program to run whatever you want via
system() (or execvp() and friends) and use that in the association.

    Juanma

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Juanma Barranquero, Thursday, June 27, 2013 3:50 PM
> 
> User expectatives for a console program and a GUI one are quite different.

Sure.

There is no "GUI" version on Unix.

I actually don't agree that emacsclientw is a proper "GUI program."  I
suppose you'll take the technical view that it is because it's a
"Windows-mode" not a "console-mode" program, but for a user, it
certainly isn't interactive in any /meaningful/ way.  Popping up
output-only dialogs and making a user click OK does not a GUI program
make.

This emacsclientw variant exists solely on Windows.  Why?  I assume
because the alternative is worse!  The console-mode version
(emacsclient) is even more annoying because Windows pops up a console
to invoke emacsclient every time.  In that configuration, the same
error message goes to the console and then the console window
disappears.  It all happens as a flash.

So, what about emacsclient Unix?  What happens in X in this scenario?
I stopped using Unix as my desktop so long ago that I have no idea
what "launching from a GUI" looks like any more.  Where does the error
message from emacsclient go?  Does the user normally get a chance to
even see it?  What I recall was that launching was in the background
so that stdout/stderr usually went to /dev/null (effectively) ... but
perhaps things have changed.

Cheers,
Mark

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 11:35 PM, Ludwig, Mark <ludwig.mark@siemens.com> wrote:

> I actually don't agree that emacsclientw is a proper "GUI program."  I
> suppose you'll take the technical view that it is because it's a
> "Windows-mode" not a "console-mode" program, but for a user, it
> certainly isn't interactive in any /meaningful/ way.  Popping up
> output-only dialogs and making a user click OK does not a GUI program
> make.

Programs come in all sizes and functionalities.

> This emacsclientw variant exists solely on Windows.  Why?  I assume
> because the alternative is worse!  The console-mode version
> (emacsclient) is even more annoying because Windows pops up a console
> to invoke emacsclient every time.  In that configuration, the same
> error message goes to the console and then the console window
> disappears.  It all happens as a flash.

Yes, emacsclientw exists to avoid creating an annoying console in uses
such as yours, i.e., when used as file associations.

> So, what about emacsclient Unix?  What happens in X in this scenario?
> I stopped using Unix as my desktop so long ago that I have no idea
> what "launching from a GUI" looks like any more.

I do not use Unix-like systems either, at least not frequently. And
I've never run emacsclient from GNU/Linux.

    Juanma

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Jason Rumney]

On Friday, 28 June 2013 05:35:09 UTC+8, Ludwig, Mark  wrote:

> So, what about emacsclient Unix?  What happens in X in this scenario?

X does not show a console automatically when command line apps are run from desktop associations, but it does send output to the X log file.

Perhaps someone can modify the Windows version to output to EventLog instead of popping up the dialog when the GUI version encounters an error.

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Richard Copley]

Ludwig, you could always sidestep the issue by deleting any stale
"server" file on startup.
For example, create a shortcut in your Start Menu\Startup folder, with target:

cmd.exe /c "del %APPDATA%\.emacs.d\server\server"

(To get to the Startup folder on Windows 8 you can type
"shell:startup" in the Run box.)

Re: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Richard Copley]

On 28 June 2013 18:55, Richard Copley <rcopley@gmail.com> wrote:
> Ludwig,

Sorry. Mark,

> you could always sidestep the issue by deleting any stale
> "server" file on startup.
> For example, create a shortcut in your Start Menu\Startup folder, with target:
>
> cmd.exe /c "del %APPDATA%\.emacs.d\server\server"
>
> (To get to the Startup folder on Windows 8 you can type
> "shell:startup" in the Run box.)

RE: Dialog from emacsclientw.exe must be dismissed (was RE: Best practices for launching Emacs on Windows 7/8)

[Ludwig, Mark]

> From: Richard Copley, Friday, June 28, 2013 1:32 PM
Ludwig,
> 
> Sorry. Mark,

No worries, and thanks for "shell:startup" -- didn't know that one
before.

Now that I know I might have caused some of the problems, I can tolerate
it when it occurs due to Windows crashing, which doesn't happen very
often any more.  I have Emacs starting in the Startup folder, but via a
.txt association to emacsclientw.  I'll change Startup to be a .CMD file
that cleans up "server" files first.

Cheers,
Mark