Re: Uhm... weird frame behaviour

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> > (#<frame address@hidden 0xf43590> #<frame F1 0xb6e7d0>)
>> > 
>> > I have no idea what frame F1 is. The only displayed frame is
>> > address@hidden', which is what `emacsclient -c -n' creates.
>> 
>> Frames whose names are F1, F2, etc. are terminal frames.  Is it
>> possible that the demonic Emacs doesn't delete the initial terminal
>> frame, like an otherwise "normal" interactive session would?
>
> Answering my own question: yes, that's what happens.
>
> So Martin, I think other_visible_frames should be augmented for the
> fact that when IS_DAEMON is non-zero, there's one frame that is always
> there and does not constitute "other frames".

It seems more correct to fix the FRAME_VISIBLE_P test for that F1 frame.

OTOH:

emacs -Q

M-x server-start

(from a terminal): emacsclient -c -nw

(on the emacs' X frame): M-x delete-windows-on (select the currently
displayed buffer)

The graphical frame goes away. This is not correct, IMO.

Another example: running emacs as a server as above, connect from a
remote X server and create an emacs frame there. On one of the two
machines, M-x delete-windows-on (choose the currently displayed buffer.)
The frame on the other machine is deleted.

So this feature about smartly deleting frames is broken for some use
cases.