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