[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Uhm... weird frame behaviour

From: Óscar Fuentes
Subject: Re: Uhm... weird frame behaviour
Date: Mon, 12 Sep 2011 19:16:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]