From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Uhm... weird frame behaviour Date: Tue, 13 Sep 2011 14:00:19 +0200 Message-ID: <4E6F45D3.3010105@gmx.at> References: <4E6C80BF.2060002@gmx.at> <4E6DCB0A.4060605@gmx.at> <87mxeaar26.fsf@wanadoo.es> <4E6DFF55.3000708@gmx.at> <87ehzlnaxj.fsf@wanadoo.es> <4E6E1D4C.7030601@gmx.at> <87littrcyy.fsf@wanadoo.es> <831uvlyckf.fsf@gnu.org> <83zki9wx4u.fsf@gnu.org> <4E6E4EC7.8070901@gmx.at> <87obypvacd.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1315915237 28262 80.91.229.12 (13 Sep 2011 12:00:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2011 12:00:37 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 13 14:00:33 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R3RfE-0007G1-C3 for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 14:00:32 +0200 Original-Received: from localhost ([::1]:44993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3RfD-0005T1-Ti for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 08:00:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3RfA-0005QE-1Z for emacs-devel@gnu.org; Tue, 13 Sep 2011 08:00:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3Rf6-0007eV-P1 for emacs-devel@gnu.org; Tue, 13 Sep 2011 08:00:27 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:33855) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1R3Rf6-0007e0-6K for emacs-devel@gnu.org; Tue, 13 Sep 2011 08:00:24 -0400 Original-Received: (qmail invoked by alias); 13 Sep 2011 12:00:22 -0000 Original-Received: from 62-47-54-95.adsl.highway.telekom.at (EHLO [62.47.54.95]) [62.47.54.95] by mail.gmx.net (mp070) with SMTP; 13 Sep 2011 14:00:22 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX193uMNiLbB37OgR9+jNPFPRwhhB9KOphcRIJ6aNrH RnUFSkUbO0xb44 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87obypvacd.fsf@stupidchicken.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143965 Archived-At: > Firstly, the function window-deletable-p should only look at frames on > the current terminal. How would it do this? Via `next-frame'? Can someone check whether this DTRT for the daemon frame? > Emacs should never automatically delete the last > frame on a terminal; that is obnoxious. So other-visible-frames-p needs > to be changed to handle this. (Not sure why that function is in C, btw; > it could be written in Lisp.) Without doing FRAME_SAMPLE_VISIBILITY? I have no idea how to do that so I'd be grateful if someone wrote such a function. I'm somewhat lost with daemons and terminals. > Secondly, the current code is too aggressive in deciding that a frame > can be deleted. Consider the following sequence: > > C-h k RET > C-x o => switch to the *Help* window > C-x 5 2 => pop to a new frame displaying *Help* > q => the frame is deleted > > I don't think this is quite right. The new frame was not created as a > "temporary frame" for displaying the *Help* window, but by the user's > explicit `C-x 5 2' command. It just so happened that a special-mode > buffer was current at the time. In this situation, quit-window should > not delete the frame. Then I'll revert to the previous behavior which kills the frame even if it has some buffer it could show instead. martin