bug#8783: 24.0.50; emacsclientw.exe behaviour in win32 not the same as in linux

bug#8783: 24.0.50; emacsclientw.exe behaviour in win32 not the same as in linux

[Jason Lewis]

Hi,

When I try to launch emacs in win32 using emacsclientw.exe it does not
seem to work as expected.

on my linux box if I start emacs with either:

emacsclient -c -a ""
emacsclient -c -a "" somefile.txt

it will start emacs in daemon mode or start a client as necessary

however on windows with the slightly different version:

C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" -c
--alternate-editor="c:\Program Files
(x86)\Emacs\emacs\bin\runemacs.exe" test.txt

it will open a new emacs instance editing text.txt

but then if you run:

C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" -c
--alternate-editor="c:\Program Files
(x86)\Emacs\emacs\bin\runemacs.exe" someotherfile.txt

it fails to open someotherfile.txt in the existing frame (and does not
create a new frame either)

further more, while emacs is already running
if you run:

C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
Files (x86)\Emacs\emacs\bin\runemacs.exe" test.txt    (no -c option)
emacs will correctly open the desired file

however:
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
Files (x86)\Emacs\emacs\bin\runemacs.exe"     (no -c option and no
file name to open)

emacs gives the error: file name or argument required, in a window and
then aborts and does not either open emacs, nor go to the emacs frame
if it is already running.

This does not seem to be the desired behaviour overall. it makes it
difficult to make 1 command to either launch emacs or open an existing
instance of emacs with a new file.


Jason


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
c:/Program Files (x86)/Emacs/emacs/etc/DEBUG.


In GNU Emacs 24.0.50.1 (i386-mingw-nt6.1.7600)
 of 2011-05-17 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 6.1.7600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENA
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  flyspell-mode: t
  show-paren-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1>
<mouse-1> <S-insert> <down-mouse-1> <mouse-1> <delete>
<delete> <delete> <delete> <delete> <delete> <delete>
<delete> <delete> <delete> <delete> <delete> <delete>
<delete> <delete> <right> <right> <down-mouse-1> <mouse-movement>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<drag-mouse-1> <escape> w <help-echo> <lwindow> M-x
r e p o <tab> r <tab> <return>

Recent messages:
Loading c:/Users/jason/AppData/Roaming/.emacs.d/jason.el (source)...
`epa-file' already enabled
Loading c:/Users/jason/AppData/Roaming/.emacs.d/jason.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Starting new Ispell process [default] ...
When done with a buffer, type C-x #
Mark set
Auto-saving...done
Making completion list...

Load-path shadows:
c:/Users/jason/AppData/Roaming/.emacs.d/elpa/zenburn-1.8/zenburn hides
c:/Users/jason/AppData/Roaming/.emacs.d//elpa-to-submit/zenburn
c:/Users/jason/AppData/Roaming/.emacs.d/elpa/color-theme-6.6.1/color-theme
hides c:/Users/jason/AppData/Roaming/.emacs.d//elpa-to-submit/color-theme
c:/Users/jason/AppData/Roaming/.emacs.d/loaddefs hides c:/Program
Files (x86)/Emacs/emacs/lisp/loaddefs
c:/Program Files (x86)/Emacs/EmacsW32/nxhtml/util/htmlfontify hides
c:/Program Files (x86)/Emacs/emacs/lisp/htmlfontify
c:/Users/jason/AppData/Roaming/.emacs.d/custom hides c:/Program Files
(x86)/Emacs/emacs/lisp/custom
c:/Users/jason/AppData/Roaming/.emacs.d/package hides c:/Program Files
(x86)/Emacs/emacs/lisp/emacs-lisp/package
c:/Program Files (x86)/Emacs/EmacsW32/nxhtml/util/chart hides
c:/Program Files (x86)/Emacs/emacs/lisp/emacs-lisp/chart
c:/Program Files (x86)/Emacs/EmacsW32/nxhtml/util/org-freemind hides
c:/Program Files (x86)/Emacs/emacs/lisp/org/org-freemind
c:/Users/jason/AppData/Roaming/.emacs.d/elpa/ruby-mode-1.1/ruby-mode
hides c:/Program Files (x86)/Emacs/emacs/lisp/progmodes/ruby-mode
c:/Users/jason/AppData/Roaming/.emacs.d//elpa-to-submit/cperl-mode
hides c:/Program Files (x86)/Emacs/emacs/lisp/progmodes/cperl-mode

Features:
(shadow sort mail-extr message rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
mail-utils gmm-utils mailheader emacsbug url-util url-parse url-vars
help-mode view flyspell ispell eldoc paredit hl-line idle-highlight
color-theme reporter server cygwin-mount ange-ftp epa-file epa derived
epg epg-config erc-highlight-nicknames easy-mmode erc-button erc-fill
erc-stamp erc-goodies erc erc-backend erc-compat pp loaddefs
starter-kit-js starter-kit-ruby starter-kit-perl starter-kit-lisp
starter-kit-eshell starter-kit-registers starter-kit-misc ido paren
tramp-cache tramp-sh shell tramp tramp-compat auth-source eieio byte-opt
bytecomp byte-compile cconv macroexp assoc gnus-util time-date mm-util
mail-prsvr password-cache format-spec tramp-loaddefs
starter-kit-bindings windmove edmacro kmacro starter-kit-defuns imenu
thingatpt dominating-file recentf tree-widget wid-edit easymenu
ansi-color uniquify advice help-fns advice-preload ffap saveplace
starter-kit-elpa anything-autoloads anything-complete-autoloads
anything-config-autoloads color-theme-complexity-autoloads
color-theme-emacs-revert-theme-autoloads color-theme-solarized-autoloads
color-theme-twilight-autoloads color-theme-vim-insert-mode-autoloads
color-theme-zenburn-autoloads color-theme-autoloads
cygwin-mount-autoloads dired-single-autoloads
find-file-in-project-autoloads gist-autoloads idle-highlight-autoloads
inf-ruby-autoloads magit-autoloads php-completion-autoloads
php-mode-autoloads rainbow-delimiters-autoloads rainbow-mode-autoloads
ruby-mode-autoloads yaml-mode-autoloads zenburn-autoloads znc-autoloads
finder-inf package emacsw32 find-func w32-integ w32shell w32-grep cl
grep compile comint regexp-opt ring noprint nxhtml-loader emacsw32-eol
preview-latex tex-site auto-loads tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer button faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process multi-tty
emacs)

bug#8783: 24.0.50; emacsclientw.exe behaviour in win32 not the same as in linux

[Eli Zaretskii]

> Date: Thu, 02 Jun 2011 14:35:47 +1000
> From: Jason Lewis <jason@dickson.st>
> 
> When I try to launch emacs in win32 using emacsclientw.exe it does not
> seem to work as expected.
> 
> on my linux box if I start emacs with either:
> 
> emacsclient -c -a ""
> emacsclient -c -a "" somefile.txt
> 
> it will start emacs in daemon mode or start a client as necessary

First, there's no equivalent of emacsclientw.exe on GNU/Linux.  You
will be better off comparing with emacsclient on Windows.

Second, the Windows build does not (yet) support the daemon mode.  I
think this explains some of the differences in behavior that you
report.  See below.

> however on windows with the slightly different version:
> 
> C:\Users\jason\AppData\Roaming>"c:\Program Files
> (x86)\Emacs\emacs\bin\emacsclientw.exe" -c
> --alternate-editor="c:\Program Files
> (x86)\Emacs\emacs\bin\runemacs.exe" test.txt
> 
> it will open a new emacs instance editing text.txt

Which is as expected, right?  (Please tell explicitly which behavior
you think is problematic, because otherwise we need to guess.)

> but then if you run:
> 
> C:\Users\jason\AppData\Roaming>"c:\Program Files
> (x86)\Emacs\emacs\bin\emacsclientw.exe" -c
> --alternate-editor="c:\Program Files
> (x86)\Emacs\emacs\bin\runemacs.exe" someotherfile.txt
> 
> it fails to open someotherfile.txt in the existing frame (and does not
> create a new frame either)

AFACT, the -c option is not really supported in the Windows build,
because it generally needs the --display argument which Windows
doesn't support.

> further more, while emacs is already running
> if you run:
> 
> C:\Users\jason\AppData\Roaming>"c:\Program Files
> (x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
> Files (x86)\Emacs\emacs\bin\runemacs.exe" test.txt    (no -c option)
> emacs will correctly open the desired file

As expected, right?

> however:
> C:\Users\jason\AppData\Roaming>"c:\Program Files
> (x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
> Files (x86)\Emacs\emacs\bin\runemacs.exe"     (no -c option and no
> file name to open)
> 
> emacs gives the error: file name or argument required, in a window and
> then aborts and does not either open emacs, nor go to the emacs frame
> if it is already running.

Expected or not?  If not, why not?

> This does not seem to be the desired behaviour overall. it makes it
> difficult to make 1 command to either launch emacs or open an existing
> instance of emacs with a new file.

??? If you don't use the -c switch, it should behave as you want:
start a new editor if there's no existing one, and otherwise connect
to the existing one.

bug#8783: 24.0.50; emacsclientw.exe behaviour in win32 not the same as in linux

[Jason Lewis]

Eli Zaretskii wrote:
>> Date: Thu, 02 Jun 2011 14:35:47 +1000
>> From: Jason Lewis <jason@dickson.st>
>>
>> When I try to launch emacs in win32 using emacsclientw.exe it does not
>> seem to work as expected.
>>
>> on my linux box if I start emacs with either:
>>
>> emacsclient -c -a ""
>> emacsclient -c -a "" somefile.txt
>>
>> it will start emacs in daemon mode or start a client as necessary
>
> First, there's no equivalent of emacsclientw.exe on GNU/Linux. You
> will be better off comparing with emacsclient on Windows.
>
> Second, the Windows build does not (yet) support the daemon mode. I
> think this explains some of the differences in behavior that you
> report. See below.
>
>> however on windows with the slightly different version:
>>
>> C:\Users\jason\AppData\Roaming>"c:\Program Files
>> (x86)\Emacs\emacs\bin\emacsclientw.exe" -c
>> --alternate-editor="c:\Program Files
>> (x86)\Emacs\emacs\bin\runemacs.exe" test.txt
>>
>> it will open a new emacs instance editing text.txt
>
> Which is as expected, right? (Please tell explicitly which behavior
> you think is problematic, because otherwise we need to guess.)
>
Yes, this is expected
>> but then if you run:
>>
>> C:\Users\jason\AppData\Roaming>"c:\Program Files
>> (x86)\Emacs\emacs\bin\emacsclientw.exe" -c
>> --alternate-editor="c:\Program Files
>> (x86)\Emacs\emacs\bin\runemacs.exe" someotherfile.txt
>>
>> it fails to open someotherfile.txt in the existing frame (and does not
>> create a new frame either)
>
> AFACT, the -c option is not really supported in the Windows build,
> because it generally needs the --display argument which Windows
> doesn't support.
>
I see - that might well be the issue - but what I'm trying to do is
find a way to launch emacs, always using the same command, and not
have it fail if emacs is not already running, or I do not supply a
file to open from the command line.

In this example above, I expect it to open someotherfile.txt in a new
buffer an emacs frame that is already running - but that seems
contrary to the -c option. As far as I can tell, there is no option to
open a file in an existing frame? maybe I'm missing something?

>> further more, while emacs is already running
>> if you run:
>>
>> C:\Users\jason\AppData\Roaming>"c:\Program Files
>> (x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
>> Files (x86)\Emacs\emacs\bin\runemacs.exe" test.txt (no -c option)
>> emacs will correctly open the desired file
>
> As expected, right?
>
Yes, this is expected.
>> however:
>> C:\Users\jason\AppData\Roaming>"c:\Program Files
>> (x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
>> Files (x86)\Emacs\emacs\bin\runemacs.exe" (no -c option and no
>> file name to open)
>>
>> emacs gives the error: file name or argument required, in a window and
>> then aborts and does not either open emacs, nor go to the emacs frame
>> if it is already running.
>
> Expected or not? If not, why not?
>
I would expect it to open a new frame, or bring an existing frame to
the foreground, and display the scratch buffer (as thought I had
opened a new instance of emacs)

>> This does not seem to be the desired behaviour overall. it makes it
>> difficult to make 1 command to either launch emacs or open an existing
>> instance of emacs with a new file.
>
> ??? If you don't use the -c switch, it should behave as you want:
> start a new editor if there's no existing one, and otherwise connect
> to the existing one.
>
Ah, maybe that's where I was going wrong?

Case 1: no emacs running, no file name given
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
Files (x86)\Emacs\emacs\bin\runemacs.exe" ""
Result: launches emacs  - desired behaviour

Case 2: no emacs running, file name given on command line
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
Files (x86)\Emacs\emacs\bin\runemacs.exe" "somefile.txt"
Result: Launches new instance of emacs editing somefile.txt - desired
behaviour

Case 3: emacs running (but not focused, buffer editing somefile.txt),
no file name given on command line
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
Files (x86)\Emacs\emacs\bin\runemacs.exe" ""

Result: does nothing -
I think this is confusing - I think emacs should become focused and
present user with scratch buffer maybe? or at least focus emacs, as
clearly I am trying to get an instance of emacs.

Case 4: emacs running (but not focused, buffer editing somefile.txt),
file name given on command line
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" --alternate-editor="c:\Program
Files (x86)\Emacs\emacs\bin\runemacs.exe" "someotherfile.txt"
Result: opens someotherfile.txt and brings emacs into focus - desired
behaviour

Just for completeness, I have tested these 4 cases again but with the
-c option for create new frame

Case 1: no emacs running, no file name given
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" -c
--alternate-editor="c:\Program Files
(x86)\Emacs\emacs\bin\runemacs.exe" ""
Result: launches emacs  - desired behaviour

Case 2: no emacs running, file name given on command line
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" -c
--alternate-editor="c:\Program Files
(x86)\Emacs\emacs\bin\runemacs.exe" "somefile.txt"
Result: Launches new instance of emacs editing somefile.txt - desired
behaviour

Case 3: emacs running (but not focused, buffer editing somefile.txt),
no file name given on command line
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" -c
--alternate-editor="c:\Program Files
(x86)\Emacs\emacs\bin\runemacs.exe" ""

Result: does nothing -
I think this is confusing - I think emacs should become focused and
present user with scratch buffer maybe? or at least focus emacs, as
clearly I am trying to get an instance of emacs.

Case 4: emacs running (but not focused, buffer editing somefile.txt),
file name given on command line
C:\Users\jason\AppData\Roaming>"c:\Program Files
(x86)\Emacs\emacs\bin\emacsclientw.exe" -c
--alternate-editor="c:\Program Files
(x86)\Emacs\emacs\bin\runemacs.exe" "someotherfile.txt"
Result: emacs window flickers for a second, but someotherfile.txt is
not opened, and emacs continues to display the somefile.txt buffer. 
This is not desired behaviour imho. I think it should open
someotherfile.txt in the existing frame? or do something useful. User
wants file opened - if it is not possible to create another frame, use
existing frame? Or at least give an error?

In conclusion, it seems as though not using -c is mostly the solution.
with the exception of launching emacs without a file name.

Jason

bug#8783: 24.0.50; emacsclientw.exe behaviour in win32 not the same as in linux

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> AFACT, the -c option is not really supported in the Windows build,
> because it generally needs the --display argument which Windows
> doesn't support.

That seems like something that should be fixed.  The -c option is short
for --create-frame. This is something that Emacs on Windows can do,
regardless of whether it supports the --display argument, multi-tty
or daemon mode.

As far as I can tell, the problem is in emacsclient.c, where it sets
tty = 1 if --create-frame is given without a --display argument or
DISPLAY environment variable.  Windows then fails to create the new
frame because it can't create tty frames.  Either the code in
emacsclient should be changed not to send tty = 1 on Windows, or the
code in server.el should be changed to ignore the tty option on Windows.

bug#8783: 24.0.50; emacsclientw.exe behaviour in win32 not the same as in linux

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> AFACT, the -c option is not really supported in the Windows build,
>> because it generally needs the --display argument which Windows
>> doesn't support.
>
> That seems like something that should be fixed.

I fixed this in emacsclient.c with trunk bzr revno 104876.