From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Shepherd Newsgroups: gmane.emacs.bugs Subject: bug#19256: 24.3; Bad interaction between calendar.el and pop-up-frames Date: Wed, 3 Dec 2014 10:35:20 +0000 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2ac4eb68d1205094d67b4 X-Trace: ger.gmane.org 1417602983 29096 80.91.229.3 (3 Dec 2014 10:36:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 10:36:23 +0000 (UTC) Cc: 19256@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 03 11:36:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xw7I8-0007ef-KT for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Dec 2014 11:36:16 +0100 Original-Received: from localhost ([::1]:40801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw7I8-00073P-8d for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Dec 2014 05:36:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw7Hz-00073I-7c for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2014 05:36:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xw7Hu-0006o0-Dy for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2014 05:36:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw7Hu-0006nw-BJ for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2014 05:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xw7Hu-0003Ov-0Z for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2014 05:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Shepherd Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Dec 2014 10:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19256 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19256-submit@debbugs.gnu.org id=B19256.141760294413047 (code B ref 19256); Wed, 03 Dec 2014 10:36:01 +0000 Original-Received: (at 19256) by debbugs.gnu.org; 3 Dec 2014 10:35:44 +0000 Original-Received: from localhost ([127.0.0.1]:52323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xw7Hb-0003OM-QU for submit@debbugs.gnu.org; Wed, 03 Dec 2014 05:35:44 -0500 Original-Received: from mail-wi0-f180.google.com ([209.85.212.180]:35341) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xw7HZ-0003OC-E5 for 19256@debbugs.gnu.org; Wed, 03 Dec 2014 05:35:42 -0500 Original-Received: by mail-wi0-f180.google.com with SMTP id n3so23858452wiv.13 for <19256@debbugs.gnu.org>; Wed, 03 Dec 2014 02:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kfUccdqaNRQvIUWsdkiDI3C5fDUOcNlZPll79pvFGHc=; b=GwxBbRsX3jv5HmRhj+u6x2rY6W/IaJSUyz9HYbGChUMJSIWddcsi0Wza8eSDvSZstL ChLkZW8URx91EUXBU3fkTaAa8CFUECM2l+RIugPmEi5FyPsZn+ysHGt80iY919CTr/yx nVTywLOFEN2cGhk5KepicqhNhomIhjW0emqFnslU/NvbJxwFqEqKhcqWl76OGfwHaM5i akqyiZo+iKD4W/Yi4+y8e6Q7JVcEIGH03gwUgb5PRxr1Xxga+E+8lt0OzNsldFWD8w8D FcA5w86r5YyN+ztVQZo9rWEMQG+WYBy4cgzJ+PRXPfzPUC5Dx6J9H6bHl4XV7qgx4fdJ U+ZA== X-Received: by 10.180.13.7 with SMTP id d7mr12537529wic.57.1417602940700; Wed, 03 Dec 2014 02:35:40 -0800 (PST) Original-Received: by 10.194.236.133 with HTTP; Wed, 3 Dec 2014 02:35:20 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:96820 Archived-At: --001a11c2ac4eb68d1205094d67b4 Content-Type: text/plain; charset=UTF-8 Glenn Morris wrote: > Sorry, I don't understand what the bug is supposed to be? > You asked for new frames to be popped up, and you got one. Sorry I should have been more specific. Calender.el implements it's own window/frame control scheme depending on the value of calendar-setup. The default setting is nil, which specifies that the calendar should open in a new window within the same frame. However, when pop-up-frames is non-nil a copy of the current frame is created and the calendar is opened in a window within that frame. That's probably not very clear so I'll give an example. Lets say I have one frame open containing a single window displaying buffer A. I do M-x calendar. I now have two frames open. The frame that was open initially is still there and unchanged. The second frame contains two windows: one displaying buffer A and the other displaying the calendar. If that's still not very clear (sorry it's quite difficult to explain) then it might be easier to just try it and see watch what happens. I should also point out that it is possible to set calendar-setup to display the calendar in a separate frame. This works as expected when combined with a non-nil pop-up-frames setting. However the calendar function is used by org-mode to enter time stamps, and in this context there is a let block setting calendar-setup to nil . So it is impossible to avoid using this combination of settings when using org-mode. --001a11c2ac4eb68d1205094d67b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Glenn Morris wrote:

> Sorry, I don't un= derstand what the bug is supposed to be?
> You asked for new frames t= o be popped up, and you got one.

Sorry I should have been= more specific. Calender.el implements it's own window/frame control sc= heme depending on the value of calendar-setup. The default setting is nil, = which specifies that the calendar should open in a new window within the s= ame frame. However, when pop-up-frames is non-nil a copy of the current fra= me is created and the calendar is opened in a window within that frame.
=
That's probably not very clear so I'll give an examp= le. Lets say I have one frame open containing a single window displaying bu= ffer A. I do M-x calendar. I now have two frames open. The frame that was = open initially is still there and unchanged. The second frame contains two = windows: one displaying buffer A and the other displaying the calendar.
=
If that's still not very clear (sorry it's quite dif= ficult to explain) then it might be easier to just try it and see watch wha= t happens.


I should also point out that it is possibl= e to set calendar-setup to display the calendar in a separate frame. This w= orks as expected when combined with a non-nil pop-up-frames setting. Howeve= r the calendar function is used by org-mode to enter time stamps, and in th= is context there is a let block setting calendar-setup to nil. So = it is impossible to avoid using this combination of settings when using org= -mode.
--001a11c2ac4eb68d1205094d67b4--