bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Albert]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

My shortcut in SendTo using emacsclientw -n -c no longer works in
emacs 24.0.93 (it did work in 24.0.92)
This is a simpler reproducible example:

1. command window started from emacs/bin
2. start runemacs -Q
3. M-x server-start
4. start emacsclientw -n -c test.txt
==> (small existing file) this works as expected (a new frame with test.txt)
5. repeat 4.: does not work: the second frame now displays an extra instance
   of *scratch*
6. repeat 4.: does work: a new frame with test.txt
7. repeat 4.: does not work: the last frame now shows *scratch* (and
all other frames also)
8. ... this repeats itself; I tried until I had 4 frames showing
*scratch* and then the next repeat gives a new frame with test.txt
again.

Doing this in 24.0.92: no new frame is created, even after repeating
there is only one frame, but always with test.txt in it
(This is strange: in the scenario with my shortcut I always get a new
frame with 24.0.92)

I hope this is a useful example.

Albert.

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
d:/albert/gnu/emacs/emacs-24.0.93/etc/DEBUG.


In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-01-30 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
 -LD:/devel/emacs/libs/gnutls-3.0.9/lib'

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: ENG
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x s e v e r <backspace> <backspace> <backspace> r
v e r - s t a r t <return> <help-echo> s l k f a l
f k j a s l k f j a s l <help-echo> <help-echo> <help-echo>
<tool-bar> <save-buffer> <help-echo> <help-echo> <help-echo>
<switch-frame> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <about-emacs> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Saving file d:/albert/gnu/emacs/emacs-24.0.93/bin/test.txt...
Wrote d:/albert/gnu/emacs/emacs-24.0.93/bin/test.txt
(New file)
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug server time-date 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 loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Sun, Feb 5, 2012 at 00:41, Albert <ab.for.lists@gmail.com> wrote:

> My shortcut in SendTo using emacsclientw -n -c no longer works in
> emacs 24.0.93 (it did work in 24.0.92)

What does it mean that it did work in .92? It always started a new frame?

> This is a simpler reproducible example:
>
> 1. command window started from emacs/bin
> 2. start runemacs -Q
> 3. M-x server-start
> 4. start emacsclientw -n -c test.txt
> ==> (small existing file) this works as expected (a new frame with test.txt)
> 5. repeat 4.: does not work: the second frame now displays an extra instance
>   of *scratch*
> 6. repeat 4.: does work: a new frame with test.txt
> 7. repeat 4.: does not work: the last frame now shows *scratch* (and
> all other frames also)
> 8. ... this repeats itself; I tried until I had 4 frames showing
> *scratch* and then the next repeat gives a new frame with test.txt
> again.

OK, I can reproduce it. And it does not depend on emacsclientw.exe, it
also fails with emacsclient.exe.

> Doing this in 24.0.92: no new frame is created, even after repeating
> there is only one frame, but always with test.txt in it

Yes. There was a change in .93 to fix a problem with -n, and also make
-c -and -t always start a new frame on Windows. It's more consistent,
and allows the users to run emacsclientw?.exe with -c or -t and not
have to worry whether the Emacs server was started as a GUI or console
application.

> (This is strange: in the scenario with my shortcut I always get a new
> frame with 24.0.92)

If you're seeing different behavior between running emacsclientw.exe
from a console and running it as a shortcut, please file another bug
with a step-by-step recipe, so I can reproduce it and test it.

> I hope this is a useful example.

Yes, thanks. I'll try to fix it ASAP.

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Sun, Feb 5, 2012 at 16:48, Juanma Barranquero <lekktu@gmail.com> wrote:

>> 1. command window started from emacs/bin
>> 2. start runemacs -Q
>> 3. M-x server-start
>> 4. start emacsclientw -n -c test.txt
>> ==> (small existing file) this works as expected (a new frame with test.txt)
>> 5. repeat 4.: does not work: the second frame now displays an extra instance
>>   of *scratch*
>> 6. repeat 4.: does work: a new frame with test.txt
>> 7. repeat 4.: does not work: the last frame now shows *scratch* (and
>> all other frames also)
>> 8. ... this repeats itself; I tried until I had 4 frames showing
>> *scratch* and then the next repeat gives a new frame with test.txt
>> again.

Hmm. I'm not sure it is a bug, or at least, I'm not sure the bug is
that it sometimes does not create a new frame.

When you request a new frame with -c or -t, you're passing
instructions to server.el about how to display the buffer. But
server.el also obeys the setting of server-window. If you look at
server-switch-buffer, you'll see that, when the buffer is already
shown in a window, and server-window is nil, it simply does

 (select-window win)  ; win is the window displaying test.txt
 (set-buffer next-buffer)  ; next-buffer is the one containing test.txt

so no new frame is created. That's not a bug. For some reason I still
have to investigate, the buffer shown in win is then replaced by
*scratch* (this is puzzling).

Next time, as test.txt is not visible (*scratch* replaced it in win),
server-switch-buffer creates a new frame. Rinse and repeat.

As a workaround, while I investigate further, I think you can run emacs with

 emacs -f server-start --eval "(setq server-window 'switch-to-buffer)"

which does what you want.

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Albert]

Hi,

Is it ok to reply like this? (To you and to the bugnumber)

Thanks for the explanation and for the workaround tip. It seems to
work (also for my original problem).

In my original report I made a remark about the shortcut behaving
differently than my command prompt experiments.
I have now found the reason: I had set server-window to
switch-to-buffer-other-frame in my customization files. In that case a
new frame is created, but the frame contains the original buffer
instead of the new one (the new one is also not listed in the buffer
list). Repeating the procedure gives the same result. I suspect that
with the new code in 24.0.93 the reason for using
switch-to-buffer-other-frame has disappeared, but the new buffer also
in that case ought to end up at least somewhere. Since I suspect that
the mechanism behind this behaviour is the same as in the original
case I post this remark here, instead of reporting a new bug.

Albert.

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Mon, Feb 6, 2012 at 18:47, Albert <ab.for.lists@gmail.com> wrote:

> Is it ok to reply like this? (To you and to the bugnumber)

Yes.

> Repeating the procedure gives the same result. I suspect that
> with the new code in 24.0.93 the reason for using
> switch-to-buffer-other-frame has disappeared, but the new buffer also
> in that case ought to end up at least somewhere.

I don't understand this. Do you mean that with a shortcut, and without
your customization of server-window, you see the same problem that
from the command line? That's to be expected.

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[martin rudalics]

 > When you request a new frame with -c or -t, you're passing
 > instructions to server.el about how to display the buffer. But
 > server.el also obeys the setting of server-window. If you look at
 > server-switch-buffer, you'll see that, when the buffer is already
 > shown in a window, and server-window is nil, it simply does
 >
 >  (select-window win)  ; win is the window displaying test.txt
 >  (set-buffer next-buffer)  ; next-buffer is the one containing test.txt
 >
 > so no new frame is created.

Just to make sure: Is the `set-buffer' needed because win's buffer might
not be current?

 > That's not a bug. For some reason I still
 > have to investigate, the buffer shown in win is then replaced by
 > *scratch* (this is puzzling).

When is it replaced?  After exiting `server-switch-buffer'?

martin

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Mon, Feb 6, 2012 at 18:57, martin rudalics <rudalics@gmx.at> wrote:

> Just to make sure: Is the `set-buffer' needed because win's buffer might
> not be current?

I don't really know why the set-buffer is required, because that code
only runs when (get-buffer-window next-buffer 0) has returned a window
(and server-window is nil, but that's irrelevant), and the call to
(select-window win) makes next-buffer the current-buffer. Perhaps
because it can be in another frame?

> When is it replaced?  After exiting `server-switch-buffer'?

When running it with edebug, yes. I haven't yet tested without edebug
(but it happens if you're not debugging, so the effect is real).

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[martin rudalics]

 > I don't really know why the set-buffer is required, because that code
 > only runs when (get-buffer-window next-buffer 0) has returned a window
 > (and server-window is nil, but that's irrelevant), and the call to
 > (select-window win) makes next-buffer the current-buffer. Perhaps
 > because it can be in another frame?

A `set-buffer' can be needed if win is already selected but next-buffer
is not the current buffer.  Otherwise the subsequent

		(when filepos
		  (server-goto-line-column filepos)))

might do strange things.  In any case this part should not be
responsible for the behavior you see.

 >> When is it replaced?  After exiting `server-switch-buffer'?
 >
 > When running it with edebug, yes. I haven't yet tested without edebug
 > (but it happens if you're not debugging, so the effect is real).

I'm not used to working with Emacs as server.  Could you try putting a
breakpoint somewhere in set_window_buffer and get a backtrace there?

I suspect the behavior is the result of some sort of window excursion
but can't imagine why and how someone would wrap `server-switch-buffer'
in such a thing.

martin

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Tue, Feb 7, 2012 at 08:53, martin rudalics <rudalics@gmx.at> wrote:

> A `set-buffer' can be needed if win is already selected but next-buffer
> is not the current buffer.

Thanks, now I understand. Looking at the code, select_window does not
call Fset_buffer if the window is already selected. I think that
should be noted in the docstring of Fselect_window, which on that
issue says only this:

 Select window.  Most editing will apply to window's buffer.
 Also make window's buffer current and make window the frame's selected
 window.  Return window.

> I'm not used to working with Emacs as server.  Could you try putting a
> breakpoint somewhere in set_window_buffer and get a backtrace there?

The attached backtrace is the call that sets *scratch* (bug.txt is the
short test file).

    Juanma


Breakpoint 3, Fset_window_buffer (window=81516037,
buffer_or_name=54738949, keep_margins=54700058) at window.c:3069
3069      register struct window *w = decode_window (window);
(gdb) bt
#0  Fset_window_buffer (window=81516037, buffer_or_name=54738949,
keep_margins=54700058) at window.c:3069
#1  0x01036cf3 in Ffuncall (nargs=3, args=0x88aeb0) at eval.c:2994
#2  0x010de95e in exec_byte_code (bytestr=20138569, vector=20138645,
maxdepth=16, args_template=54700058, nargs=0, args=0x0) at
bytecode.c:785
#3  0x01037b38 in funcall_lambda (fun=20138501, nargs=4,
arg_vector=0x342a81a) at eval.c:3218
#4  0x0103701e in Ffuncall (nargs=5, args=0x88b1a0) at eval.c:3036
#5  0x010de95e in exec_byte_code (bytestr=20139169, vector=20139317,
maxdepth=28, args_template=54700058, nargs=0, args=0x0) at
bytecode.c:785
#6  0x010ddefc in Fbyte_code (bytestr=20139169, vector=20139317,
maxdepth=28) at bytecode.c:423
#7  0x01034e58 in eval_sub (form=20139158) at eval.c:2341
#8  0x0103260e in internal_catch (tag=54981826, func=0x103451f
<eval_sub>, arg=20139158) at eval.c:1257
#9  0x010df31c in exec_byte_code (bytestr=20138897, vector=20139029,
maxdepth=28, args_template=54700058, nargs=0, args=0x0) at
bytecode.c:966
#10 0x01037b38 in funcall_lambda (fun=20138845, nargs=2,
arg_vector=0x342a81a) at eval.c:3218
#11 0x0103701e in Ffuncall (nargs=3, args=0x88b850) at eval.c:3036
#12 0x010de95e in exec_byte_code (bytestr=20141809, vector=20141893,
maxdepth=20, args_template=54700058, nargs=0, args=0x0) at
bytecode.c:785
#13 0x01037b38 in funcall_lambda (fun=20141781, nargs=1,
arg_vector=0x342a81a) at eval.c:3218
#14 0x0103701e in Ffuncall (nargs=2, args=0x88bb58) at eval.c:3036
#15 0x01036195 in call1 (fn=54848066, arg1=57495045) at eval.c:2756
#16 0x011c019a in replace_buffer_in_windows (buffer=57495045) at window.c:2781
#17 0x010ab865 in Fkill_buffer (buffer_or_name=54700058) at buffer.c:1539
#18 0x01036c20 in Ffuncall (nargs=2, args=0x88bcb4) at eval.c:2987
#19 0x010de95e in exec_byte_code (bytestr=56290273, vector=81404805,
maxdepth=20, args_template=1028, nargs=1, args=0x88bfbc) at
bytecode.c:785
#20 0x01037704 in funcall_lambda (fun=56018789, nargs=1,
arg_vector=0x404) at eval.c:3152
#21 0x0103701e in Ffuncall (nargs=2, args=0x88bfb4) at eval.c:3036
#22 0x010de95e in exec_byte_code (bytestr=54897281, vector=82037253,
maxdepth=20, args_template=0, nargs=0, args=0x88c2c4) at
bytecode.c:785
#23 0x01037704 in funcall_lambda (fun=56819493, nargs=0,
arg_vector=0x0) at eval.c:3152
#24 0x0103701e in Ffuncall (nargs=1, args=0x88c2c0) at eval.c:3036
#25 0x01034be2 in eval_sub (form=82028518) at eval.c:2307
#26 0x01032b09 in internal_lisp_condition_case (var=81410938,
bodyform=82028518, handlers=82026542) at eval.c:1454
#27 0x010df383 in exec_byte_code (bytestr=54897457, vector=82037125,
maxdepth=56, args_template=0, nargs=0, args=0x88c7a4) at
bytecode.c:981
#28 0x01037704 in funcall_lambda (fun=56815621, nargs=0,
arg_vector=0x0) at eval.c:3152
#29 0x0103701e in Ffuncall (nargs=1, args=0x88c7a0) at eval.c:3036
#30 0x01034be2 in eval_sub (form=82028454) at eval.c:2307
#31 0x01032b09 in internal_lisp_condition_case (var=81410914,
bodyform=82028454, handlers=82028502) at eval.c:1454
#32 0x010df383 in exec_byte_code (bytestr=54897521, vector=81404357,
maxdepth=84, args_template=7196, nargs=7, args=0x88ccb0) at
bytecode.c:981
#33 0x01037704 in funcall_lambda (fun=56954789, nargs=7,
arg_vector=0x1c1c) at eval.c:3152
#34 0x0103701e in Ffuncall (nargs=8, args=0x88cc90) at eval.c:3036
#35 0x010de95e in exec_byte_code (bytestr=54817377, vector=57453061,
maxdepth=32, args_template=0, nargs=0, args=0x88cf94) at
bytecode.c:785
#36 0x01037704 in funcall_lambda (fun=56818309, nargs=0,
arg_vector=0x0) at eval.c:3152
#37 0x0103701e in Ffuncall (nargs=1, args=0x88cf90) at eval.c:3036
#38 0x010de95e in exec_byte_code (bytestr=57148833, vector=81305125,
maxdepth=4, args_template=0, nargs=0, args=0x88d294) at bytecode.c:785
#39 0x01037704 in funcall_lambda (fun=56816709, nargs=0,
arg_vector=0x0) at eval.c:3152
#40 0x0103701e in Ffuncall (nargs=1, args=0x88d290) at eval.c:3036
#41 0x01034be2 in eval_sub (form=82028366) at eval.c:2307
#42 0x01032b09 in internal_lisp_condition_case (var=81410770,
bodyform=82028366, handlers=82028414) at eval.c:1454
#43 0x010df383 in exec_byte_code (bytestr=57149281, vector=54798725,
maxdepth=40, args_template=1028, nargs=1, args=0x88d798) at
bytecode.c:981
#44 0x01037704 in funcall_lambda (fun=56045605, nargs=1,
arg_vector=0x404) at eval.c:3152
#45 0x0103701e in Ffuncall (nargs=2, args=0x88d790) at eval.c:3036
#46 0x010de95e in exec_byte_code (bytestr=55380625, vector=81599493,
maxdepth=128, args_template=0, nargs=0, args=0x88dac4) at
bytecode.c:785
#47 0x01037704 in funcall_lambda (fun=55708613, nargs=0,
arg_vector=0x0) at eval.c:3152
#48 0x0103701e in Ffuncall (nargs=1, args=0x88dac0) at eval.c:3036
#49 0x01034be2 in eval_sub (form=55900630) at eval.c:2307
#50 0x01032b09 in internal_lisp_condition_case (var=81410842,
bodyform=55900630, handlers=55900054) at eval.c:1454
#51 0x010df383 in exec_byte_code (bytestr=55793521, vector=57560325,
maxdepth=40, args_template=0, nargs=0, args=0x88df94) at
bytecode.c:981
#52 0x01037704 in funcall_lambda (fun=57868997, nargs=0,
arg_vector=0x0) at eval.c:3152
#53 0x0103701e in Ffuncall (nargs=1, args=0x88df90) at eval.c:3036
#54 0x01034be2 in eval_sub (form=55900966) at eval.c:2307
#55 0x0103260e in internal_catch (tag=81410794, func=0x103451f
<eval_sub>, arg=55900966) at eval.c:1257
#56 0x010df31c in exec_byte_code (bytestr=55793585, vector=81404421,
maxdepth=48, args_template=2056, nargs=2, args=0x88e43c) at
bytecode.c:966
#57 0x01037704 in funcall_lambda (fun=56954053, nargs=2,
arg_vector=0x808) at eval.c:3152
#58 0x0103701e in Ffuncall (nargs=3, args=0x88e430) at eval.c:3036
#59 0x01035bf3 in Fapply (nargs=2, args=0x88e4c4) at eval.c:2492
#60 0x01036140 in apply1 (fn=81410338, arg=55901310) at eval.c:2730
#61 0x0104c229 in read_process_output_call (fun_and_args=55901014) at
process.c:5002
#62 0x01032cd3 in internal_condition_case_1 (bfun=0x104c1a6
<read_process_output_call>, arg=55901014, handlers=54757786,
    hfun=0x104c22b <read_process_output_error_handler>) at eval.c:1538
#63 0x0104c8fc in read_process_output (proc=57560069, channel=4) at
process.c:5201
#64 0x0104bd71 in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54700058,
wait_proc=0x0,
    just_wait_proc=0) at process.c:4844
#65 0x010f8826 in sit_for (timeout=120, reading=1, do_display=1) at
dispnew.c:6063
#66 0x0100923b in read_char (commandflag=1, nmaps=2, maps=0x88f980,
prev_event=54700058, used_mouse_menu=0x88fa58, end_time=0x0) at
keyboard.c:2690
#67 0x0101c25c in read_key_sequence (keybuf=0x88fbd4, bufsize=30,
prompt=54700058, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9302
#68 0x01005c93 in command_loop_1 () at keyboard.c:1448
#69 0x01032beb in internal_condition_case (bfun=0x100569b
<command_loop_1>, handlers=54757786, hfun=0x1004eba <cmd_error>) at
eval.c:1500
#70 0x010052f7 in command_loop_2 (ignore=54700058) at keyboard.c:1159
#71 0x0103260e in internal_catch (tag=54755810, func=0x10052d3
<command_loop_2>, arg=54700058) at eval.c:1257
#72 0x010052b3 in command_loop () at keyboard.c:1138
#73 0x0100488f in recursive_edit_1 () at keyboard.c:758
#74 0x01004baa in Frecursive_edit () at keyboard.c:822
#75 0x010028b5 in main (argc=4, argv=0xc62ca8) at emacs.c:1715

Lisp Backtrace:
"set-window-buffer" (0x88aeb4)
"set-window-buffer-start-and-point" (0x88b1a4)
"byte-code" (0x88b404)
"switch-to-prev-buffer" (0x88b854)
"replace-buffer-in-windows" (0x88bb5c)
"kill-buffer" (0x88bcb8)
"server-unselect-display" (0x88bfb8)
0x362ff20 PVEC_COMPILED
"funcall" (0x88c2c0)
0x362f000 PVEC_COMPILED
"funcall" (0x88c7a0)
"server-execute" (0x88cc94)
0x362fa80 PVEC_COMPILED
0x362f440 PVEC_COMPILED
"funcall" (0x88d290)
"server-execute-continuation" (0x88d794)
0x3520bc0 PVEC_COMPILED
"funcall" (0x88dac0)
0x37302c0 PVEC_COMPILED
"funcall" (0x88df90)
"server-process-filter" (0x88e434)
(gdb) frame 0
#0  Fset_window_buffer (window=81516037, buffer_or_name=54738949,
keep_margins=54700058) at window.c:3069
3069      register struct window *w = decode_window (window);
(gdb) p buffer_or_name
$2 = 54738949
(gdb) pr
#<buffer *scratch*>
(gdb) frame 17
#17 0x010ab865 in Fkill_buffer (buffer_or_name=54700058) at buffer.c:1539
1539      replace_buffer_in_windows (buffer);
(gdb) p buffer_or_name
$3 = 54700058
(gdb) pr
nil
(gdb) frame 16
#16 0x011c019a in replace_buffer_in_windows (buffer=57495045) at window.c:2781
2781      call1 (Qreplace_buffer_in_windows, buffer);
(gdb) p buffer
$4 = 57495045
(gdb) pr
#<buffer bug.txt>
(gdb)

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

In this code from `server-unselect-display':

    (if (and (eq (frame-first-window frame)
                 (next-window (frame-first-window frame) 'nomini))
             (eq (window-buffer (frame-first-window frame))
                 (frame-parameter frame 'server-dummy-buffer)))
        ;; The temp frame still only shows one buffer, and that is the
        ;; internal temp buffer.
        (delete-frame frame)             ;; <---- (1)
      (set-frame-parameter frame 'visibility t))
    (kill-buffer (frame-parameter frame 'server-dummy-buffer))  ;; <---- (2)
    (set-frame-parameter frame 'server-dummy-buffer nil)))

When the `if' part runs, the frame is deleted in (1), but then (2)
calls `frame-parameter' on it, and it always returns nil

(let ((f (make-frame)))
  (set-frame-parameter f 'my-param t)
  (delete-frame f)
  (frame-parameter f 'my-param))        =>   nil

so (2) runs (kill-buffer nil), and deletes the buffer (in this case,
bug.txt), triggering the behavior we see.

The attached simple patch fixes it.

Stefan, thoughts on the issue?

   Juanma



=== modified file 'lisp/server.el'
--- lisp/server.el	2012-02-02 07:48:39 +0000
+++ lisp/server.el	2012-02-07 13:26:33 +0000
@@ -407,6 +407,6 @@
         ;; internal temp buffer.
         (delete-frame frame)
-      (set-frame-parameter frame 'visibility t))
-    (kill-buffer (frame-parameter frame 'server-dummy-buffer))
+      (set-frame-parameter frame 'visibility t)
+      (kill-buffer (frame-parameter frame 'server-dummy-buffer)))
     (set-frame-parameter frame 'server-dummy-buffer nil)))

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Tue, Feb 7, 2012 at 14:31, Juanma Barranquero <lekktu@gmail.com> wrote:

> The attached simple patch fixes it.

Or, assuming I'm now really awake, this one.


=== modified file 'lisp/server.el'
--- lisp/server.el	2012-02-02 07:48:39 +0000
+++ lisp/server.el	2012-02-07 13:32:12 +0000
@@ -407,7 +407,7 @@
         ;; internal temp buffer.
         (delete-frame frame)
-      (set-frame-parameter frame 'visibility t))
-    (kill-buffer (frame-parameter frame 'server-dummy-buffer))
-    (set-frame-parameter frame 'server-dummy-buffer nil)))
+      (set-frame-parameter frame 'visibility t)
+      (kill-buffer (frame-parameter frame 'server-dummy-buffer))
+      (set-frame-parameter frame 'server-dummy-buffer nil))))

 (defun server-handle-delete-frame (frame)

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[martin rudalics]

 > Or, assuming I'm now really awake, this one.

I'd rather use something like the untested patch below (still very fragile
because it neither verifies that a frame is a frame nor that a buffer is
a buffer).

martin


=== modified file 'lisp/server.el'
*** lisp/server.el	2012-02-02 07:48:39 +0000
--- lisp/server.el	2012-02-07 14:29:08 +0000
***************
*** 399,414 ****
       ;; visible.  If not (which can happen if the user's customizations call
       ;; pop-to-buffer etc.), delete it to avoid preserving the connection after
       ;; the last real frame is deleted.
!     (if (and (eq (frame-first-window frame)
!                  (next-window (frame-first-window frame) 'nomini))
!              (eq (window-buffer (frame-first-window frame))
!                  (frame-parameter frame 'server-dummy-buffer)))
!         ;; The temp frame still only shows one buffer, and that is the
!         ;; internal temp buffer.
!         (delete-frame frame)
!       (set-frame-parameter frame 'visibility t))
!     (kill-buffer (frame-parameter frame 'server-dummy-buffer))
!     (set-frame-parameter frame 'server-dummy-buffer nil)))

   (defun server-handle-delete-frame (frame)
     "Delete the client connection when the emacsclient frame is deleted.
--- 399,413 ----
       ;; visible.  If not (which can happen if the user's customizations call
       ;; pop-to-buffer etc.), delete it to avoid preserving the connection after
       ;; the last real frame is deleted.
!     (let ((buffer (frame-parameter frame 'server-dummy-buffer)))
!       (if (and (one-window-p 'nomini frame)
! 	       (eq (window-buffer (frame-first-window frame)) buffer))
! 	  ;; The temp frame still only shows one buffer, and that is the
! 	  ;; internal temp buffer.
! 	  (delete-frame frame)
! 	(set-frame-parameter frame 'visibility t)
! 	(set-frame-parameter frame 'server-dummy-buffer nil))
!       (kill-buffer buffer))))

   (defun server-handle-delete-frame (frame)
     "Delete the client connection when the emacsclient frame is deleted.

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

On Tue, Feb 7, 2012 at 15:32, martin rudalics <rudalics@gmx.at> wrote:

> I'd rather use something like the untested patch below

OK, you're the expert.

> (still very fragile
> because it neither verifies that a frame is a frame nor that a buffer is
> a buffer).

Why don't you add such checks?

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[martin rudalics]

 >> I'd rather use something like the untested patch below
 >
 > OK, you're the expert.

Not really.  But I think that your patch didn't kill the buffer if it
was on the frame.

 >> (still very fragile
 >> because it neither verifies that a frame is a frame nor that a buffer is
 >> a buffer).
 >
 > Why don't you add such checks?

I don't like changing a function I cannot immediately test.  Did you
apply my patch?

martin

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

> But I think that your patch didn't kill the buffer if it  was on the frame.

Ah, yes, you're right.

> I don't like changing a function I cannot immediately test.  Did you
> apply my patch?

Yes. In the reported case it works as expected, but I haven't done
extensive testing with other setups.

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[martin rudalics]

> Yes. In the reported case it works as expected, but I haven't done
> extensive testing with other setups.

Feel free to peruse it any which way you like if you can test it.

martin

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Stefan Monnier]

> I'd rather use something like the untested patch below (still very fragile
> because it neither verifies that a frame is a frame nor that a buffer is
> a buffer).

Looks right, please install,


        Stefan

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[Juanma Barranquero]

Closing this as fixed.

    Juanma

bug#10729: 24.0.93; On MS-Windows: emacsclientw.exe -n -c does create a new frame, but does not always display the requested file or the requested directory (24.0.92 does)

[martin rudalics]

 > Thanks, now I understand. Looking at the code, select_window does not
 > call Fset_buffer if the window is already selected. I think that
 > should be noted in the docstring of Fselect_window, which on that
 > issue says only this:
 >
 >  Select window.  Most editing will apply to window's buffer.
 >  Also make window's buffer current and make window the frame's selected
 >  window.  Return window.

It's an undocumented and possibly wrong behavior of some functions and
macros (`window-point' recently stroke me again).  I plan to look into
this for Emacs 24.2.

martin