From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8856: 24.0.50; regression: special-display-frame is no longer dedicated Date: Tue, 21 Jun 2011 11:10:58 -0700 Message-ID: <7AF0B637CAE14034973FBCC658AFEBD9@us.oracle.com> References: <853BDEF1AA9646ACB90724066E1A5951@us.oracle.com><4DF65024.20305@gmx.at><0C191F638279437BADFCC697A5389F9E@us.oracle.com><4DF726A1.7020804@gmx.at><8E7452317D5B4FD183FD24E0FAA14F6F@us.oracle.com><4DFB6BBF.3080504@gmx.at><6FAF5DFD0E094823A512C3E0E87B6DF5@us.oracle.com><4DFE09A7.10500@gmx.at> <0137606B527A48C69E3D6C704C5C6595@us.oracle.com> <4DFF1709.3010409@gmx.at> <309F7428711D4BEBB6063C60808D8069@us.oracle.com> <4E00C54C.5080108@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308683455 18914 80.91.229.12 (21 Jun 2011 19:10:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2011 19:10:55 +0000 (UTC) Cc: 8856@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 21 21:10:51 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1QZ6LZ-0002pe-6r for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Jun 2011 21:10:49 +0200 Original-Received: from localhost ([::1]:34252 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ6LX-0000Fw-Ul for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Jun 2011 15:10:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5Qj-0008Po-DU for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2011 14:12:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZ5Qh-0003qF-KT for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2011 14:12:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZ5Qh-0003q7-8H for bug-gnu-emacs@gnu.org; Tue, 21 Jun 2011 14:12:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QZ5Qg-0006oO-AJ; Tue, 21 Jun 2011 14:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Jun 2011 18:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8856 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8856-submit@debbugs.gnu.org id=B8856.130867988026116 (code B ref 8856); Tue, 21 Jun 2011 18:12:02 +0000 Original-Received: (at 8856) by debbugs.gnu.org; 21 Jun 2011 18:11:20 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QZ5Pz-0006nB-9Y for submit@debbugs.gnu.org; Tue, 21 Jun 2011 14:11:19 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QZ5Px-0006mv-9D for 8856@debbugs.gnu.org; Tue, 21 Jun 2011 14:11:17 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5LIB9XI010596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2011 18:11:11 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5LIB7q8019601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2011 18:11:08 GMT Original-Received: from abhmt012.oracle.com (abhmt012.oracle.com [141.146.116.21]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5LIB28I007505; Tue, 21 Jun 2011 13:11:02 -0500 Original-Received: from dradamslap1 (/10.159.50.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jun 2011 11:11:01 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E00C54C.5080108@gmx.at> Thread-Index: AcwwMJAJgbB4AcwWRUKQOUT5Wc2+IgABpU7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E00DEBF.0098:SCFSTAT5015188, ss=1, re=-4.000, fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 21 Jun 2011 14:12:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:47389 Archived-At: > > Please run Emacs this way for testing this, so we're on > > the same page. > > I know what the bug is now. The old code ran some very complicated > raise-frame mechanism but did _not_ select the window if it already > existed on another frame. That's what I changed in the new > code to make it uniform with the pop-up-a-new-frame behavior. > Apparently that was a bad idea. I now (hopefully) reverted the > old behavior. > > Attached find the latest window.el. It only works with the latest two > versions uploaded by Sean. If you get any warnings or bugs > when loading or compiling it please tell me. I'll give it a try and let you knonw. Thanks for struggling with all of this, and for trying to improve the handling of windows and frames - a daunting task, no doubt. > Also, `display-buffer-alist' will unlikely work with your code > yet. So you need to trigger 1on1 using the old options. I'm not sure what you mean, in particular by the last sentence. Are you referring to how command `1on1-emacs' is invoked or to something else? I assume that I would at least need to replace the assignment, in `1on1-emacs', of `pop-up-frames' to `t' by something else, presumably something involving `display-buffer-alist'. Are you saying that there is not yet any good replacement in this case? Will you let me know when you have an idea what I can do, to DTRT, once the "yet" is dealt with? > Redirecting frame focus is not very easy to handle :-( I am sure of that. And most users have nil `pop-up-frames' (or equivalent), and they never have to deal with focus redirection. Likewise most Emacs maintainers. I've been trying to get Emacs Dev to think (and test!) more in terms of frames for years. Frames are nearly second-class citizens for Emacs. Development and maintenance changes have often, I think, been tested only with `pop-up-frames' = nil. Certainly they are more tested in that case than in the non-nil case. Frames are almost an afterthought. Partly this is no doubt due to frames being handled differently by different window mgrs. Partly it may be due to habit (Emacs had windows before frames, most users do not use non-nil `pop-up-frames', etc.). -- BTW, as you might have noticed in looking at command `1on1-emacs' and `oneonone.el' generally, it presents an example of why it is wrong to think that code should never bind or set user options. I mention this because (you think that) you disagree. Emacs base code should not overrule user settings, of course. But code that is invoked by user choice is another story. A user chooses to invoke a command, just as s?he chooses option settings and other default values. It is helpful for the command's doc in this case to mention that it temporarily binds such-and-such user option to such-and-such value or that it sets the option (i.e. not just temporarily), etc. But there is no reason that a voluntarily invoked command should not alter a user setting. The moral obligation is to let users know just what the consequences of invocation are, including option changes. A user of command `1on1-emacs' should know that it sets `pop-up-frames' to t, and that that is precisely part of the command's raison d'etre. You use `1on1-emacs' only if you want non-nil `pop-up-frames'. Emacs has always allowed for and even provided option-altering commands. See `customize-set-variable', `customize-set-value', and `set-variable', for instance. Personally, although I try to convince users to use Customize rather than just Lisp code, I also believe it is helpful to go beyond Customize as an interactive way to modify options and faces. I've done that with Do Re Mi, for instance: provide commands to easily modify option values incrementally. Nothing wrong with that - in fact, we could use more of it. Nothing should limit us to the Customize UI as the only way to interactively change user settings.