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#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' Date: Fri, 17 Jun 2011 11:31:44 -0700 Message-ID: References: <4DF7B1BB.6050704@gmx.at><4DF87A4F.60704@gmx.at><5F95025D0ABE4561A305F30293828F38@us.oracle.com><4DF8DD1E.8080004@gmx.at><68E985ED37824BE799A9C01162553E22@us.oracle.com><4DF8EF87.8080903@gmx.at> <7923A876A42744A39EEC6AAB67362EAC@us.oracle.com> <4DF9FEA7.1050509@gmx.at> <4DFA1C6B.50400@gmx.at> <4DFB76D4.6080400@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 1308335660 10045 80.91.229.12 (17 Jun 2011 18:34:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Jun 2011 18:34:20 +0000 (UTC) Cc: 8865@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 17 20:34:15 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 1QXdry-000105-GE for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Jun 2011 20:34:14 +0200 Original-Received: from localhost ([::1]:50017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXdrx-0003Bq-Cn for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Jun 2011 14:34:13 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXdqu-0002vh-1i for bug-gnu-emacs@gnu.org; Fri, 17 Jun 2011 14:33:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXdqq-0003lI-A0 for bug-gnu-emacs@gnu.org; Fri, 17 Jun 2011 14:33:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXdqq-0003l5-1O for bug-gnu-emacs@gnu.org; Fri, 17 Jun 2011 14:33:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QXdqo-0004XZ-07; Fri, 17 Jun 2011 14:33: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: Fri, 17 Jun 2011 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8865 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8865-submit@debbugs.gnu.org id=B8865.130833552617377 (code B ref 8865); Fri, 17 Jun 2011 18:33:01 +0000 Original-Received: (at 8865) by debbugs.gnu.org; 17 Jun 2011 18:32:06 +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 1QXdps-0004WE-Lj for submit@debbugs.gnu.org; Fri, 17 Jun 2011 14:32:05 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QXdpp-0004Vh-L7 for 8865@debbugs.gnu.org; Fri, 17 Jun 2011 14:32:02 -0400 Original-Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5HIVrGe022402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2011 18:31:55 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5HIVpaR013550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 18:31:52 GMT Original-Received: from abhmt004.oracle.com (abhmt004.oracle.com [141.146.116.13]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5HIVkXK001386; Fri, 17 Jun 2011 13:31:46 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Jun 2011 11:31:45 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4DFB76D4.6080400@gmx.at> Thread-Index: AcwtBb+hm3rqHdfyT4iILC3VsUBEIAAALHrA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090207.4DFB9D9B.00C8:SCFSTAT5015188,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 17 Jun 2011 14:33: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:47272 Archived-At: > The NEWS entries and the manuals will be updated next week, hopefully. > > > What is the recommended replacement for a nil/non-nil test of > > `pop-up-frames'? > > Remove it. Such a test is not reliable. That doesn't help. What is the _replacement_? In Emacs ...20,21,22,23, code can test `pop-up-frames'. What is the corresponding test using `display-buffer-alist' (or whatever)? If there is no exact correspondence then what is the closest correspondence. > >> Code shouldn't try to guess the user's intentions in the > >> first place: > > > > Huh? What is that about? `pop-up-frames' is a user option. > > What's to guess about it? > > Where the user wants to display the buffer. With Emacs 23 > you would in general have to check for > (1) display-buffer-function, (2) whether the > selected window shows the buffer already and can be used, and (3) > same-window-p, before you can safely decide that the user really wants > to pop up a new frame. What can I say? The test of `pop-up-frames' tells me what I need to know in Emacs 20,21,22,23, so that my code DTRT. What is an equivalent test that I can use in Emacs 24, so my code still DTRT? That's all I'm asking. If there is no exact equivalent, then let me know the closest thing. I will try it and see whether it is sufficient for my needs. I'm asking to use your new features to get the same or very similar behavior - nothing more. Previously I could test the user's setting of `pop-up-frames' (at least its current value) to determine what to do based on what the user wants (at least as reflected in the current value). How to do that now? What's the closest mapping of `pop-up-frames' to (some part of) `display-buffer-alist' or whatever the substitute is? > You can't check whether the user wants a new frame by looking > at `display-buffer-alist' alone. Well, please give me the variables to check then. And how to check them. > You have to look at the sizes of the windows of the selected > frame before you can decide that the user really wants to > create a new frame. Are you joking? And just what must you look for? And how do you decide based on what you find? Before, a user could specify that they generally wanted a separate frame (new or existing, but separate), by just using non-nil `pop-up-frames'. And code could check that value and DTRT. Now, you seem to be saying, code has to analyze a set of windows to determine whether the user wants a separate frame? Just how is that analysis done? Please give us a code template that comes close to the general case handled so simply before by just testing `pop-up-frames'. What is the closest thing to the simple scenario we had before, of (1) a user setting `pop-up-frames' to `t' to express wanting `display-buffer' to generally use a separate frame and (2) code testing `pop-up-frames' to generally DTRT and respect that user setting? > > just let us know what the replacement for a nil/non-nil test of > > `pop-up-frames' is > > You first have to normalize specifiers as with > `display-buffer-normalize-specifiers'. If in the resulting list, you > find an entry whose car is 'pop-up-frame you know that > popping up a new > frame is one possible option. Whether it will be tried depends on the > entries preceding it and the actual window configuration. Can you be please more specific? Give an example, replacing a simple (if pop-up-frames X Y) with recommended analysis-or-whatever code. Please don't just send us off to read umpteen pages of code and explanation. Let us start with a simple replacement example and see if that works well enough. If not, then we can dig deeper and try to understand more of your bells and whistles. Doing this will also help understanding. > > What is the Emacs 24 equivalent to the intention expressed > > by - and the behavior realized by, a nil/non-nil > > `pop-up-frames' test prior to Emacs 24 (i.e. prior to > > the introduction of your feature)? > > > > Can you express that behavior in terms of > > `display-buffer-alist'? If so, presumably you can give us > > the test of the `display-buffer-alist' value to use > > in place of the nil/non-nil test of the `pop-up-frames' > > value, that is, a test that gives the same behavior. > > > > That's all I'm asking for here: how to do, using your new > > constructs, what we have always done before using `pop-up-frames'. > > I added a new specifier to `display-buffer-alist' called > other-window-means-other-frame. When a user sets this it > means that the user wants `display-buffer' called with the second > argument t (and most other scalar non-nil values) to pop up a new > frame instead of a new window. I also added a function called > `display-buffer-other-window-means-other-frame' which tells > you whether a user has set that specifier for the buffer in > question. So when this function returns a non-nil value you can > safely assume that the user "in principle" accepts popping up a > new frame. The function is included in the code I sent you > separately. I hate to say it, but OK, I figured I'd try to guess what you mean here, so I took a look at `display-buffer-alist' (in the code you sent me) - and I'm lost. I expected I'd see `other-window-means-other-frame' somewhere, but its only presence was in the most complex defcustom :type expression I have ever seen. So, I said to myself, OK, I'll try `M-x customize-option' - maybe things will be clearer once I'm in Customize. Whoa! The Customize buffer from hell! Sorry to kid a bit, but I cannot make hide nor hair of this. Can you please give me an example, showing what I can try changing `(if pop-up-frames X Y)' to, to at least test this case you're developing of a user setting (something in) `display-buffer-alist' to `other-window-means-other-frame'? I'm guessing that even after I understand that, it won't be sufficient - that at least some users who might have had non-nil `pop-up-frames' in Emacs prior to 24 will change to something slightly different for `display-buffer-alist' from just using `other-window-means-other-frame'. But let me at least start with handling that case. Please let me know how to test this. Please understand that this all seems super-complex to me, so far. The complexity you've added for handling windows has little bearing for me as a user because I don't often use more than one window per frame. I'm not typical in that, but that might be the case of at least some other users who have used non-nil `pop-up-frames'. When such a user (I'll try to speak for myself) sees that Customize buffer s?he is overwhelmed. Even just as a user I don't know how to customize the option to get a behavior that is as close as possible to what I had before (`display-buffer' generally using a separate frame). As a programmer I have even less idea how to handle different user settings that all might trace their ancestry to use of non-nil `pop-up-frames' in prior releases. I'm asking for a little help here. I think other users and programmers could probably use some guidance also. I find it hard to believe that things really need to be so complex, as shown by that Customize buffer. But I do not pretend to be an expert on Emacs windowing, and certainly not on using multiple windows per frame. > With `display-buffer-alist' the user sets up a list of options that > shall be tried by `display-buffer' until one succeeds. There's no > equivalent to this in the old code where that order was hardcoded in > `display-buffer'. That's fine. I have no problem with that idea. My problem is to know how to deal with it, both as a user and a programmer. To start with, how do I as a user customize `display-buffer-alist' to get a behavior as close as possible to what I had in Emacs 22 or 23 by just setting `pop-up-frames' to nil? Do I remove all of the default `Display specifiers' and then add one that corresponds to what I want? If so, which one? > >> Obviously, if your code is targeted only at users not customizing > >> `display-buffer-alist', you can test `pop-up-frames' as before, > > > > I'm perfectly willing and wanting to have my code support > > whatever is the new design. That's why I'm asking the question! > > But then you should simply set the second argument of `display-buffer' > appropriately _without_ thinking of the user but only thinking of what's > best for the application. If the user doesn't want what you propose > here she can override it. Huh? What _are_ you talking about? I'm not even calling `display-buffer' directly. This is about code that tests `pop-up-frames', in order to respect what the user has specified for that option. You said that if my code doesn't target users who customize `d-b-a' then it can test `p-u-f' as before. I answered that I _want_ my code to target users who now customize `d-b-a', since users will do just that from now on. I have been asking, with no success so far, _how_ to do that. What is the equivalent, or a close equivalent, for testing `d-b-a' now to testing `pop-up-frames' in the past? > > I'm just trying to adapt my code to your changes. > > > > What I'm asking is how to do so. My code needs to support > > multiple Emacs versions, and I would like it to DTRT for Emacs > > 24, which I gather means testing `display-buffer-alist' > > appropriately. > > > > The question is how to use/test that > > variable to get the same behavior as before, i.e., the > > same behavior as for other Emacs versions. > > > > Why is this such a hard question for you to address? > > Your code didn't DTRT for Emacs 23. How the f do you know that? It works well enough for me and those who use it, which is what it was designed for. All I'm asking you is how to use your new features, to do what we've done before using `pop-up-frames' - since you are replacing/deprecating that option. You have talked all around the question to no end, but you haven't answered it. There are tests of `pop-up-frames' in the Emacs source code. How will you replace them? That info would provide an example as a starting point, at least. > > Please tell me specifically what you mean - I don't > > follow. Please take a given nil/non-nil test of > > `pop-up-frames' and let me know what it would be for > > Emacs 24 and `display-buffer-alist' instead. > > > > Preferably, translate Emacs 22's (if pop-up-frames...) to > > code that will do the same thing in _both_ Emacs 22 and > > Emacs 24 - e.g., using `display-buffer-alist' > > for the latter (i.e., when `boundp'). Thx. > > Sigh. Why "sigh"? Why is that so hard? You get rid of (deprecate) X, saying to use Y instead, but you won't give an example of _how_ to use Y instead of X? > Maybe the new code does what you want. Do you mean the new version of window.el you sent me? Sadly, no - the same symptoms are there as I described originally. But my previous test with your suggested `display-buffer-normalize-specifiers-1' worked, as I mentioned. You said you would install that, but it differs from the definition that is in the window.el version you sent me. And in fact I cannot even use the two together: If I load the window.el you sent me and then eval the `display-buffer-normalize-specifiers-1' version you posted in this thread (which worked, by itself), then I get this error: Entering debugger... let*: Wrong number of arguments: (lambda (specifiers) "Subroutine of `display-buffer-normalize-specifiers'. SPECIFIERS is the SPECIFIERS argument of `display-buffer'." (let (normalized entry) (cond ((not specifiers) nil) ((listp specifiers) (dolist (specifier specifiers) (cond ((consp specifier) (setq normalized (cons specifier normalized))) ((symbolp specifier) (let ((entry ...)) (dolist (item ...) (setq normalized ...)))))) (nreverse normalized)) ((and (not (eq specifiers (quote other-window))) (setq entry (assq specifiers display-buffer-macro-specifiers))) (cdr entry)) ((memq pop-up-frames (quote (nil unset))) (cdr (assq (quote other-window) display-buffer-macro-specifiers))) (t (cdr (assq (quote other-frame) display-buffer-macro-specifiers)))))), 3