Re: [h-e-w] Multiple versions of Emacs under Windows; How to specify which Emacs should run when file is double-clicked?

[David Vanderschel]

Thank you, Jason, for explaining the difference in behaviour
one observes when running the clients in a command window.
I had not previously realized that, when emacsclientw is
waiting, there is an invisible instance of the emacsclientw
Windows program that is doing so.  However, now that I think
to 'ask', I must say that I cannot see such instances as
processes in the Task Manager; but, if it is true, I have
been leaving a lot of those lying about by failing to
release the buffer.  It is not clear to me how to add the
--no-wait modifier in the context of the file association,
and it would probably make sense to do so.  (But see my
last paragraph in this message.)

As it turns out, I had made a mistake; and it is true that
one should use emacsclientw for the file assocation.  What
confused me was that I had correctly associated .txt files
(and others, long ago) with emacsclientw; but, when I look
now at the "Open With" choices offered by Explorer, it does
not present the emacsclientw choice as "emacsclientw".
Indeed it shows "GNU EmacsClient: Client for the extensible
self-documenting text editor (patched)", even though the
.exe which it is using is that for emacsclientw.  So that is
why I believed that I had been using emacsclient.  (When I
browse to emacsclient.exe as my choice for what program to
open a file with, yes I do get an objectionable command
window.)  I suspect that that identifying string for
emacsclientw comes from the program itself, and that this is
something that should be fixed if only to avoid the sort of
confusion that afflicted myself.  Also, I actually tried to
find some documentation somewhere about the intended
difference between the two, and I failed; so I did the
command line experiment to find out (and got a misleading
result).  I think something should be added to the Wiki as
well.  The Emacs info file has nothing to say about
emacsclientw; and it probably should not, as this is
strictly a Windows issue.

I now see that there is a correct explanation of how to
associate files in Windows here:
http://www.gnu.org/software/emacs/windows/Installing-Emacs.html
(I wish I had found that instead of the Wiki when I
initially sought such documentation; but it still does not
explain the difference in the two programs.)

One symptom I still cannot explain: When I open a file in
Emacs using Explorer, Emacs does not believe that there is
any client waiting on the buffer.  Indeed, if I try \C-x #,
Emacs says, "No server editing buffers exist".  But when I
invoke the client (either) from the command line, Emacs does
believe there is a client and \C-x # works as advertised.
Indeed, in the latter cases, I can see the client process
(either) in the Task Manager's process list.  This seems to
imply that emacsclientw is already behaving in the no-wait
manner when invoked by Explorer.

Regards,
 David V.

----- Original Message ----- 
From: "Jason Rumney" <address@hidden>
To: "David Vanderschel" <address@hidden>
Cc: "Francis Wright" <address@hidden>; 
<address@hidden>
Sent: Wednesday, January 05, 2011 4:59 PM
Subject: Re: [h-e-w] Multiple versions of Emacs under Windows; 
How to specify which Emacs should run when file is 
double-clicked?


"David Vanderschel" <address@hidden> writes:

> I believe that the difference between emacsclient and
> emacsclientw is that, with the "w", it is equivalent to
> emacsclient with the --no-wait option and not whether or
> not a command window appears.

No, both versions wait. The difference is that
emacsclientw.exe is compiled as a Windows program, and
emacsclient.exe is compiled as a console program. At least
on older versions of Windows a console program always
resulted in a command window opening when lauched outside of
a command window.  And being a Windows program, the console
window does not wait for emacsclientw.exe to terminate
before returning you to the prompt, so in that context it
does appear not to wait (but for text editors that wait for
the subprocess to terminate, it should still work the same
as emacsclient.exe).