* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' @ 2011-06-14 18:14 Drew Adams 2011-06-14 19:08 ` martin rudalics 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-14 18:14 UTC (permalink / raw) To: 8865 My setup, not emacs -Q. Summary: A non-interactive call to `display-buffer' with non-nil arg NOT-THIS-WINDOW does not show the buffer in a separate frame, even though `pop-up-frames' is non-nil. I have non-nil `pop-up-frames'. I use the following function via `M-x find-library-other-window frame.el'. It should find the library in a separate frame. Instead, it finds it in another window of the current frame - i.e., it splits the current window and puts it in one of those two windows. (defun find-library-other-window (library) "Find the Emacs-Lisp source of LIBRARY in another window." (interactive (let* ((path (cons (or find-function-source-path load-path) (find-library-suffixes))) (def (if (eq (function-called-at-point) 'require) (save-excursion (backward-up-list) (forward-char) (backward-sexp -2) (thing-at-point 'symbol)) (thing-at-point 'symbol)))) (when def (setq def (and (locate-file-completion def path 'test) def))) (list (completing-read "Library name: " 'locate-file-completion path nil nil nil def)))) (let ((buf (find-file-noselect (find-library-name library)))) (pop-to-buffer buf 'other-window))) Invoking `M-x find-library-other-window frame.el' leads to the following call chain (from the debugger): (display-buffer #<buffer frame.el> other-window nil) (display-buffer-normalize-specifiers "frame.el" other-window nil) returns the following sexp, which I'll call FOO below: ((reuse-window other same visible) (pop-up-window (largest) (lru)) (pop-up-frame) (reuse-window other other visible) (reuse-window nil same 0) (reuse-window-even-sizes . t) (pop-up-frame t) (pop-up-frame-function lambda nil (make-frame pop-up-frame-alist)) (reuse-window nil same visible) (pop-up-window (largest) (lru)) (pop-up-frame) (reuse-window nil other visible) (reuse-window-even-sizes . t) (reuse-window nil same visible) (pop-up-window (largest) (lru)) (pop-up-frame) (pop-up-frame-alist (height . 24) (width . 80) (unsplittable . t)) (reuse-window nil other visible) (reuse-window-even-sizes . t)) Then, * display-buffer-reuse-window( #<buffer frame.el> (other same visible) FOO) returns: nil Then, * display-buffer-pop-up-window( #<buffer frame.el> ((largest) (lru)) FOO) calls * display-buffer-split-window( #<window 8 on drews-lisp-20> nil FOO) which calls * display-buffer-split-window-1( #<window 8 on drews-lisp-20> below 4) which calls * split-window( #<window 8 on drews-lisp-20> nil below) which calls * resize-this-window( #<window 8 on drews-lisp-20> -29 nil) which calls * split-window-internal( #<window 8 on drews-lisp-20> 29 below 0.5) which splits the window and then throws, putting the frame.el buffer in the second window (instead of its own frame). In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-06-13 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.5) --no-opt --cflags -Ic:/build/include' ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-14 18:14 bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' Drew Adams @ 2011-06-14 19:08 ` martin rudalics 2011-06-14 19:43 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: martin rudalics @ 2011-06-14 19:08 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > I have non-nil `pop-up-frames'. I use the following function via `M-x > find-library-other-window frame.el'. It should find the library in a > separate frame. Instead, it finds it in another window of the current > frame - i.e., it splits the current window and puts it in one of those > two windows. Emacs has a lot of commands postfixed with -other-window and -other-frame. For example, `find-file-other-window' or `switch-to-buffer-other-window' traditionally find a file or switch to a buffer in another window on the same frame. By this convention, `find-library-other-window' is not supposed to pop up a new frame. If we want to maintain compatibility with the old behavior in this and similar cases we'd have to segregate a set of reserved values for the second argument of `display-buffer'. Preserving the classic "non-nil" behavior is impossible if we want to use the new `display-buffer' code (originally I favored let-binding to achieve that behavior but using an argument was proposed by Stefan Monnier and overloading the second argument by Juri Linkov - at the time that was discussed there were no objections). I have no objections interpreting the argument value `t' in the sense that when `pop-up-frames' is non-nil and not unset, `display-buffer' tries to pop up a new frame before it tries to pop up a new window. martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-14 19:08 ` martin rudalics @ 2011-06-14 19:43 ` Drew Adams 2011-06-15 9:24 ` martin rudalics 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-14 19:43 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > > I have non-nil `pop-up-frames'. I use the following > > function via `M-x find-library-other-window frame.el'. > > It should find the library in a separate frame. > > Instead, it finds it in another window of the current > > frame - i.e., it splits the current window and puts it in > > one of those two windows. > > Emacs has a lot of commands postfixed with -other-window and > -other-frame. For example, `find-file-other-window' or > `switch-to-buffer-other-window' traditionally find a file or > switch to a buffer in another window on the same frame. Yes, and they all pop up a separate frame, if `pop-up-frames' is non-nil. This has _always_ been the case, ever since Emacs introduced frames. And it should continue to be the case. And the doc of `pop-up-frames' (in (elisp) Choosing Window) says so: This variable specifies whether `display-buffer' should make new frames. If it is non-`nil', `display-buffer' looks for a window already displaying ... If it finds such a window... Otherwise it makes a new frame... Otherwise it makes a new frame. Period. And it says, further reinforcing the point: If `pop-up-frames' is `nil', then `display-buffer' either splits a window or reuses one. It does that only if the option value is nil. But in the latest build, this is broken. Try, in last weeks build (or last year's or 1990's build or...): emacs -Q (setq pop-up-frames t) C-x 4 f foo.el The file is visited in a separate frame. Not so in this week's build. The same is true for _all_ `C-x 4' prefix commands. Non-nil `pop-up-frames' treats all `C-x 4' keys as if they were `C-x 5' keys. It makes `*-other-window' commands behave as `*-other-frame' commands. Always has. Always should. > By this convention, > `find-library-other-window' is not supposed to pop up a new frame. Of course it is. Just like all the others. > If we want to maintain compatibility with the old behavior in this and > similar cases we'd have to segregate a set of reserved values for the > second argument of `display-buffer'. Preserving the classic "non-nil" > behavior is impossible if we want to use the new `display-buffer' code If it ain't broke, don't fix it. If there are some problems that you would like to fix for people who do not use non-nil `pop-up-frames', do so, but not by breaking Emacs for people who do use non-nil `pop-up-frames', please. > (originally I favored let-binding to achieve that behavior > but using an > argument was proposed by Stefan Monnier and overloading the second > argument by Juri Linkov - at the time that was discussed there were no > objections). I have nothing to say about how to implement your new features. My point is to please not, as a side effect, also break Emacs for non-nil `pop-up-frames'. > I have no objections interpreting the argument value `t' in the sense > that when `pop-up-frames' is non-nil and not unset, `display-buffer' > tries to pop up a new frame before it tries to pop up a new window. I'm not sure I understand what you're saying (what argument? etc.). But if you are saying that you will restore the behavior that non-nil `pop-up-frames' causes `display-buffer' to do what the doc says it should do, and what it always has done, then yes, I'm in favor of that. That means: `display-buffer' looks for a window already displaying BUFFER-OR-NAME on any visible or iconified frame. If it finds such a window, it makes that window's frame visible and raises it if necessary, and returns the window. Otherwise it makes a new frame, unless the variable's value is `graphic-only' and the selected frame is not on a graphic display. (Non-nil is not the same as non-t, BTW, for both `pop-up-frames' and the NOT-THIS-WINDOW arg of `display-buffer'. If you were speaking about that arg, then any non-nil value has always had the same behavior as a value of t. Or if you were speaking of `pop-up-frames', then the only special non-nil value is `graphic-only', not t, and even that value is special only for non-graphic displays.) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-14 19:43 ` Drew Adams @ 2011-06-15 9:24 ` martin rudalics 2011-06-15 16:14 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: martin rudalics @ 2011-06-15 9:24 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > (Non-nil is not the same as non-t, BTW, for both `pop-up-frames' and the > NOT-THIS-WINDOW arg of `display-buffer'. If you were speaking about that arg, > then any non-nil value has always had the same behavior as a value of > t. This is no more the case. That argument is called SPECIFIERS now and certain values (like lists and certain symbols) will be reserved for a different behavior. If you don't like such a change, you will have to talk to someone else; I already mentioned Juri and Stefan as potential addressees. Meanwhile I can offer the below substitute for `display-buffer-normalize-specifiers-1' which should address most of your concerns in this area. martin (defun display-buffer-normalize-specifiers-1 (specifiers) "Subroutine of `display-buffer-normalize-specifiers'. SPECIFIERS is the SPECIFIERS argument of `display-buffer'." (let (normalized entry) (cond ((not specifiers) nil) ((listp specifiers) ;; If SPECIFIERS is a list, we assume it is a list of specifiers. (dolist (specifier specifiers) (cond ((consp specifier) (setq normalized (cons specifier normalized))) ((symbolp specifier) ;; Might be a macro specifier, try to expand it (the cdr is a ;; list and we have to reverse it later, so do it one at a ;; time). (let ((entry (assq specifier display-buffer-macro-specifiers))) (dolist (item (cdr entry)) (setq normalized (cons item normalized))))))) ;; Reverse list. (nreverse normalized)) ((and (not (eq specifiers 'other-window)) (setq entry (assq specifiers display-buffer-macro-specifiers))) ;; A macro specifier. (cdr entry)) ((memq pop-up-frames '(nil unset)) ;; Pop up a new window. (cdr (assq 'other-window display-buffer-macro-specifiers))) (t ;; Pop up a new frame. (cdr (assq 'other-frame display-buffer-macro-specifiers)))))) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 9:24 ` martin rudalics @ 2011-06-15 16:14 ` Drew Adams 2011-06-15 16:26 ` martin rudalics 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-15 16:14 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > > (Non-nil is not the same as non-t, BTW, for both > > `pop-up-frames' and the NOT-THIS-WINDOW arg of `display-buffer'. > > If you were speaking about that arg, then any non-nil value > > has always had the same behavior as a value of t...) > > This is no more the case. That argument is called SPECIFIERS now and > certain values (like lists and certain symbols) will be reserved for a > different behavior. If you don't like such a change, you will have to > talk to someone else; I already mentioned Juri and Stefan as potential > addressees. > > Meanwhile I can offer the below substitute for > `display-buffer-normalize-specifiers-1' which should address most of > your concerns in this area. 1. The text you quoted from me was only a parenthetical remark -- see the "BTW", plus the parens. I hope that your reply to it does not constitute your complete response to this bug report. The bug is described clearly, outside of and independent of that remark. 2. Anyway, I tried your proposed redefinition of `display-buffer-normalize-specifiers-1', just in case, and it does not have any effect on this bug. See below: the `other-window' value is not something special in my code, and the fix is certainly not to treat that particular symbol as a special case. 3. If users must change all of their existing calls of the form (display-buffer buf 'SOMETHING-NON-NIL), to keep the same behavior as before, then you need to explicitly say so - in the doc. I don't mind doing that, personally, but I need to know just what the correct change is. Other users are in the same boat. FWIW, the only reason I have sometimes used a value such as a symbol `other-window' or `OTHER-WIN' instead of `t' in cases like this is to make the code a little more readable - it's just a reminder of what a non-nil arg does here. So there is nothing special in my use of `other-window' as the value, and I don't have any problem with changing such non-nil values to something else (to `t'?). 4. But is that really necessary, for you to make the changes that you need? That's for you to answer, but here are some thoughts that I hope will help. Wrt the general question of changing parameter values such as this one, i.e., defining new, specific non-nil values where previously all non-nil values were treated the same: The usual approach, and a better one in general, is to allow for the new treatment of specific non-nil values, but to still treat any other non-nil value the same as before. IOW, a priori I'm not wild about your _design_ choice of changing the meaning of arbitrary (non-specific) values. Why not just handle the specific values you want/need to handle, and let any other non-nil value do what it has always done? 5. In the case of `display-buffer', I can see that you want to handle a _list_ of SPECIFIERS, but why also introduce the "convenience" of also handling arbitrary non-list values as specifiers? Why not just interpret a list as SPECIFIERS? That would certainly break less code, since the most common non-nil values in use are probably symbols. 6. A more important question would be why not, instead of completely changing the meaning of the second parameter, add a new (optional) parameter for your SPECIFIERS needs? I know you said that Juri suggested to reuse the second parameter (NOT-THIS-WINDOW) for this, but that doesn't seem like such a great idea. That's not reuse; it's just a recipe for breaking code. 7. Anyway, this ("any non-nil value has always had the same behavior as a value of t") is just a side discussion wrt the bug reported. Please do not lose sight of the bug itself, whatever you decide about this side issue. It is particularly important that you understand, as you apparently did not when you designed this change, that non-nil `pop-up-frames' makes all `*-other-window' functions use another frame, not another window. It is an important Emacs feature that it is enough that a user customize `pop-up-frames' to non-nil, to make all other-window commands (e.g. `C-x 4' prefix) behave as other-frame commands (`C-x 5' prefix). Please DTRT. Thx. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 16:14 ` Drew Adams @ 2011-06-15 16:26 ` martin rudalics 2011-06-15 17:11 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: martin rudalics @ 2011-06-15 16:26 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > 2. Anyway, I tried your proposed redefinition of > `display-buffer-normalize-specifiers-1', just in case, and it does not have any > effect on this bug. See below: the `other-window' value is not something > special in my code, and the fix is certainly not to treat that particular symbol > as a special case. With the redefinition of `display-buffer-normalize-specifiers-1' doing (let ((pop-up-frames t)) (display-buffer (get-buffer-create "*foo*") 'other-window)) pops up a new frame. So do (let ((pop-up-frames t)) (display-buffer (get-buffer-create "*foo*") 4)) and (let ((pop-up-frames t)) (display-buffer (get-buffer-create "*foo*") "Drew")) Evaluating (setq pop-up-frames t) and subsequently doing C-x 4 b pops up the buffer in a new frame. What do you get? What more do you want? martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 16:26 ` martin rudalics @ 2011-06-15 17:11 ` Drew Adams 2011-06-15 17:44 ` martin rudalics 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-15 17:11 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > With the redefinition of `display-buffer-normalize-specifiers-1'... > subsequently doing C-x 4 b pops up the buffer in a new frame. Yes, it does. I was mistaken about that (I confused this bug with another). But are you proposing to redefine `display-buffer-normalize-specifiers-1' that way for Emacs, or are you just proposing that I redefine it locally for myself that way? The latter would not address (fix) the bug. Users (not just me) should not have `C-x 4 f' etc. change its behavior - those commands should still use another frame (for non-nil `pop-up-frames'), as they have always done. If you implement this change in Emacs, then yes, please close the bug, as your redefinition seems to fix it. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 17:11 ` Drew Adams @ 2011-06-15 17:44 ` martin rudalics 2011-06-15 17:53 ` Drew Adams 2011-06-16 8:45 ` martin rudalics 0 siblings, 2 replies; 29+ messages in thread From: martin rudalics @ 2011-06-15 17:44 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > But are you proposing to redefine `display-buffer-normalize-specifiers-1' that > way for Emacs, or are you just proposing that I redefine it locally for myself > that way? The former. > If you implement this change in Emacs, then yes, please close the bug, as your > redefinition seems to fix it. I'll do that tomorrow. Meanwhile keep it in your window.el until Sean has made the new binaries. I hope to fix also the special-display bug till then. martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 17:44 ` martin rudalics @ 2011-06-15 17:53 ` Drew Adams 2011-06-15 22:15 ` Drew Adams 2011-06-16 8:45 ` martin rudalics 1 sibling, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-15 17:53 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > > If you implement this change in Emacs, then yes, please > > close the bug, as your redefinition seems to fix it. > > I'll do that tomorrow. Meanwhile keep it in your window.el until Sean > has made the new binaries. I hope to fix also the special-display bug > till then. Thank you, Martin, especially for the latter bug. It is that one that makes the latest build unusable for me. No special hurry, BTW - I don't need to work with the latest build. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 17:53 ` Drew Adams @ 2011-06-15 22:15 ` Drew Adams 2011-06-16 13:01 ` martin rudalics 2011-06-16 13:09 ` Stefan Monnier 0 siblings, 2 replies; 29+ messages in thread From: Drew Adams @ 2011-06-15 22:15 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 BTW, can you tell me what is a reasonable substitute for tests of `pop-up-frames' now? That is, what to do about code that has (if pop-up-frames ...)? What is the replacement for such a test in Emacs 24? Thx. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 22:15 ` Drew Adams @ 2011-06-16 13:01 ` martin rudalics 2011-06-16 14:01 ` Drew Adams 2011-06-16 13:09 ` Stefan Monnier 1 sibling, 1 reply; 29+ messages in thread From: martin rudalics @ 2011-06-16 13:01 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > BTW, can you tell me what is a reasonable substitute for tests of > `pop-up-frames' now? That is, what to do about code that has (if pop-up-frames > ...)? What is the replacement for such a test in Emacs 24? Thx. Please decide together with David Engster where to bring the current discussion of bug#8857 to and try to give it an appropriate title. I can't find the idiom (if pop-up-frames in the current trunk so I would first like to know why and how it is used. `sunrise-sunset' uses (if pop-up-windows but I'm quite confident that this is not TRT to do. martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-16 13:01 ` martin rudalics @ 2011-06-16 14:01 ` Drew Adams 2011-06-16 15:08 ` martin rudalics 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-16 14:01 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > > BTW, can you tell me what is a reasonable substitute for tests of > > `pop-up-frames' now? That is, what to do about code that > > has (if pop-up-frames ...)? What is the replacement for such > > a test in Emacs 24? Thx. > > Please decide together with David Engster where to bring the current > discussion of bug#8857 to and try to give it an appropriate title. Sorry, I haven't followed that bug at all, and I have no idea what you're saying here. > I can't find the idiom (if pop-up-frames in the current trunk > so I would first like to know why and how it is used. How about looking at the Emacs sources before you made your changes? ;-) If you grep the Emacs 20, 21, 22, or 23 Lisp source code for `pop-up-frames' you will see lots of hits, some of which are tests of its value. For example (Emacs 23.3): From help.el: (cond ((or pop-up-frames...)...) From pcvs-util.el (let ((pop-up-windows (or pop-up-windows pop-up-frames)) From diary-lib.el (let* ((pop-up-frames (or pop-up-frames ... From rmailsum.el (if (and (one-window-p) pop-up-windows (not pop-up-frames)) From sendmail.el (if (and (or nil ; ?????? ... (and pop-up-frames (one-window-p))...) From inf-lisp.el (let ((pop-up-frames ;; Be willing to use another frame ;; that already has the window in it. (or pop-up-frames (get-buffer-window inferior-lisp-buffer t)))) Anyway, I meant in user code - my code. I'm not trying to update the Emacs sources. I use such tests in only a couple of places. They are of course based on the (original) meaning of `pop-up-frames': non-nil means `display-buffer' uses a separate frame. Nothing special. So the question is how to test that user intention using the latest Emacs design. From my code: ;; If non-nil `pop-up-frames' then inhibit showing annotation. (let ((bookmark-automatically-show-annotations (and bookmark-automatically-show-annotations (not pop-up-frames)))) ;; Use separate frames instead of windows if `pop-up-frames' ;; is non-nil or if prefix arg is negative. (cond (...) ((or pop-up-frames option) (while file-list (find-file-other-frame... ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-16 14:01 ` Drew Adams @ 2011-06-16 15:08 ` martin rudalics 2011-06-16 16:03 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: martin rudalics @ 2011-06-16 15:08 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > How about looking at the Emacs sources before you made your changes? ;-) If you > grep the Emacs 20, 21, 22, or 23 Lisp source code for `pop-up-frames' you will > see lots of hits, some of which are tests of its value. For example (Emacs > 23.3): > >>From help.el: > (cond ((or pop-up-frames...)...) > ... All these tests will be removed/replaced in due time because these variables are obsolete now. > I use such tests in only a couple of places. They are of course based on the > (original) meaning of `pop-up-frames': non-nil means `display-buffer' uses a > separate frame. And that was incorrect already in Emacs 23. The value 'graphic-only should have been dealt with separately. > Nothing special. > > So the question is how to test that user intention using the latest Emacs > design. From my code: > > ;; If non-nil `pop-up-frames' then inhibit showing annotation. > (let ((bookmark-automatically-show-annotations > (and bookmark-automatically-show-annotations > (not pop-up-frames)))) > > ;; Use separate frames instead of windows if `pop-up-frames' > ;; is non-nil or if prefix arg is negative. > (cond (...) > ((or pop-up-frames option) > (while file-list (find-file-other-frame... Code shouldn't try to guess the user's intentions in the first place: The strategy, in increasing priority, is - users express their intentions in `display-buffer-alist', - the code can suggest a better solution by passing a second argument to the buffer display function, - users can override the code by setting the override specifier in `display-buffer-alist'. Code should only express suggestions in the sense that "displaying the buffer in this or that way is best to my knowledge". The user can accept that suggestion or override it. In most cases, however, code should not suggest anything and leave the decision to the user. Obviously, if your code is targeted only at users not customizing `display-buffer-alist', you can test `pop-up-frames' as before, taking care of the special values 'unset (which means the user doesn't bother) and 'graphic-only. One benefit of this is that if `pop-up-frames' is nil, the user has explicitly delared that she doesn't want to pop up new frames with your code. martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-16 15:08 ` martin rudalics @ 2011-06-16 16:03 ` Drew Adams 2011-06-17 15:46 ` martin rudalics 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-16 16:03 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > >> I can't find the idiom (if pop-up-frames in the current trunk > >> so I would first like to know why and how it is used. > > > > How about looking at the Emacs sources before you made > > your changes? ;-) Re-reading that now, I see that it could be misinterpreted. I meant that even if you find no such tests in the current Emacs code (i.e., after your changes, which would be understandable, since you have probably removed them), there are such occurrences in the Emacs code prior to your changes - i.e. Emacs 23.3, and even in a build from two weeks ago. You said that you found no occurrences of (if pop-up-frames...) in the source code. My point is that there are plenty of occurrences of nil/non-nil tests of `pop-up-frames' in the Emacs 23/22/21/20/... source code. grep for `pop-up-frames', not just for "(if pop-up-frames". > > If you grep the Emacs 20, 21, 22, or 23 Lisp source code for > > `pop-up-frames' you will see lots of hits, some of which are > > tests of its value. For example (Emacs 23.3): > > From help.el: (cond ((or pop-up-frames...)...) > > All these tests will be removed/replaced in due time because these > variables are obsolete now. No doubt. The question was about what to replace such tests with. I would even expect (like to see) an entry in etc/NEWS that addresses this specifically. It is typical when some construct becomes unrecommended or deprecated to provide specific info about just what to use in its stead. What is the recommended replacement for a nil/non-nil test of `pop-up-frames'? > > I use such tests in only a couple of places. They are of > > course based on the (original) meaning of `pop-up-frames': > > non-nil means `display-buffer' uses a separate frame. > > And that was incorrect already in Emacs 23. The value 'graphic-only > should have been dealt with separately. Not if the code in question involves only graphic displays. In any case, that is irrelevant to my concern. Think Emacs 22 (or 21 or 20 or 19 or 18), if you prefer. My code in a couple of places, and the Emacs 22 source code in many places, effects a nil/non-nil test of `pop-up-frames'. What is the proper replacement for that, i.e., to get the same behavior? > > Nothing special. So the question is how to test that user > > intention using the latest Emacs design. From my code: > > > > ;; If non-nil `pop-up-frames' then inhibit showing annotation. > > (let ((bookmark-automatically-show-annotations > > (and bookmark-automatically-show-annotations > > (not pop-up-frames)))) > > > > ;; Use separate frames instead of windows if `pop-up-frames' > > ;; is non-nil or if prefix arg is negative. > > (cond (...) > > ((or pop-up-frames option) > > (while file-list (find-file-other-frame... > > 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? How about forgetting for a moment what you think code should and shouldn't do, and just let us know what the replacement for a nil/non-nil test of `pop-up-frames' is? > The strategy, in increasing priority, is > > - users express their intentions in `display-buffer-alist', 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'. > - the code can suggest a better solution by passing a second > argument to the buffer display function, > > - users can override the code by setting the override specifier in > `display-buffer-alist'. That's all too vague for me, I'm afraid. What is the answer to the question? How to reproduce (e.g. by testing `display-buffer-alist') the same behavior that testing `pop-up-frames' as a nil/non-nil value gave before? > Code should only express suggestions in the sense that "displaying the > buffer in this or that way is best to my knowledge". The user can > accept that suggestion or override it. In most cases, however, code > should not suggest anything and leave the decision to the user. Please stop with the "should"s regarding programming style etc. - that's not very helpful. Emacs code has always bound some user variables. There is nothing special or sacrosanct about `pop-up-frames' in this regard. Take a look at the many bindings of `case-fold-search'... In general, user settings "should" prevail, but there are cases where it can make sense for code to override the user's preferred default behavior (customization), including by binding a user option. Whether or not a _given_ binding is appropriate is another matter. But the blanket idea that code "should not" bind user options is a non-starter, at least for me. We can certainly agree to disagree about this. But I will suggest that your point of view on it seems quite rigid, and it is unsupported by historical experience - within either the Emacs sources or third-party code. Recognize that no one is saying that your code "should" bind any given option. It is you who is apparently declaring that _all_ code must _never_ bind _any_ user option. That is a quite rigid/doctrinaire view, no? > 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! It does not matter in the end whether I think the new design is better or worse than before, or better or worse than some possible alternative, or even whether I understand it. In any case, I want/need to support it in my code. I'm not redesigning Emacs here - you are. 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? > taking care of the special values 'unset (which means the user > doesn't bother) and 'graphic-only. 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-16 16:03 ` Drew Adams @ 2011-06-17 15:46 ` martin rudalics 2011-06-17 18:31 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: martin rudalics @ 2011-06-17 15:46 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > I would even expect (like to see) an entry in etc/NEWS that addresses this > specifically. It is typical when some construct becomes unrecommended or > deprecated to provide specific info about just what to use in its stead. 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. > In any case, that is irrelevant to my concern. Think Emacs 22 (or 21 or 20 or > 19 or 18), if you prefer. My code in a couple of places, and the Emacs 22 > source code in many places, effects a nil/non-nil test of `pop-up-frames'. What > is the proper replacement for that, i.e., to get the same behavior? > >> > Nothing special. So the question is how to test that user >> > intention using the latest Emacs design. From my code: >> > >> > ;; If non-nil `pop-up-frames' then inhibit showing annotation. >> > (let ((bookmark-automatically-show-annotations >> > (and bookmark-automatically-show-annotations >> > (not pop-up-frames)))) >> > >> > ;; Use separate frames instead of windows if `pop-up-frames' >> > ;; is non-nil or if prefix arg is negative. >> > (cond (...) >> > ((or pop-up-frames option) >> > (while file-list (find-file-other-frame... >> >> 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 you want to do is the same thing help functions tried before I wrote the `with-help-window' macro. Earlier, help tried to guess from the settings of user options where `with-output-to-temp-buffer' would put the buffer. And the guesses were so often wrong that users (including you) complained continuously. So what's good for the functions you peruse should be good for the functions you write. With Emacs 24 a user can specify that the buffer should go into a new window on the selected frame if a window of the desired height can be created and in a new frame otherwise. Which means that the user always gets a window of the desired size. You can't check whether the user wants a new frame by looking at `display-buffer-alist' alone. 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. > How about forgetting for a moment what you think code should and shouldn't do, > and 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. > 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. > That's all too vague for me, I'm afraid. What is the answer to the question? > How to reproduce (e.g. by testing `display-buffer-alist') the same behavior that > testing `pop-up-frames' as a nil/non-nil value gave before? 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'. > Please stop with the "should"s regarding programming style etc. - that's not > very helpful. I received complaints that applications impose a certain method for displaying a buffer and the users didn't have a chance to change that. Why can't we finally let _the user_ decide what `display-buffer' should do? > Emacs code has always bound some user variables. There is > nothing special or sacrosanct about `pop-up-frames' in this regard. Take a look > at the many bindings of `case-fold-search'... > > In general, user settings "should" prevail, but there are cases where it can > make sense for code to override the user's preferred default behavior > (customization), including by binding a user option. Whether or not a _given_ > binding is appropriate is another matter. But the blanket idea that code > "should not" bind user options is a non-starter, at least for me. > > We can certainly agree to disagree about this. We disagree. > But I will suggest that your point of view on it seems quite rigid, and it is > unsupported by historical experience - within either the Emacs sources or > third-party code. Recognize that no one is saying that your code "should" bind > any given option. It is you who is apparently declaring that _all_ code must > _never_ bind _any_ user option. That is a quite rigid/doctrinaire view, no? I think code is better off if it respects the user. >> 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. > It does not matter in the end whether I think the new design is better or worse > than before, or better or worse than some possible alternative, or even whether > I understand it. In any case, I want/need to support it in my code. I'm not > redesigning Emacs here - you are. 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. >> taking care of the special values 'unset (which means the user >> doesn't bother) and 'graphic-only. > > 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. Maybe the new code does what you want. martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 15:46 ` martin rudalics @ 2011-06-17 18:31 ` Drew Adams 2011-06-19 17:43 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-17 18:31 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 18:31 ` Drew Adams @ 2011-06-19 17:43 ` Drew Adams 2011-06-19 18:50 ` martin rudalics 2011-06-19 20:13 ` Drew Adams 0 siblings, 2 replies; 29+ messages in thread From: Drew Adams @ 2011-06-19 17:43 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 [-- Attachment #1: Type: text/plain, Size: 480 bytes --] FYI - This bug is fixed by the second version of window that you sent me today, Martin. To see that it is fixed, load the attached file after emacs -Q, then do this (same recipe as originally): M-x find-library-other-window RET frame.el RET Buffer frame.el is now shown in a separate frame, not just a separate window as before your latest window.el. (P.S. The attached file assumes your latest window.el is in the current directory and named "window-2011-06-19a-MARTIN.el".) [-- Attachment #2: throw-8865.el --] [-- Type: application/octet-stream, Size: 958 bytes --] ; emacs -Q (setq pop-up-frames t) (require 'find-func) (load-file "window-2011-06-19a-MARTIN.el") (defun find-library-other-window (library) "Find the Emacs-Lisp source of LIBRARY in another window." (interactive (let* ((path (cons (or find-function-source-path load-path) (find-library-suffixes))) (def (if (eq (function-called-at-point) 'require) (save-excursion (backward-up-list) (forward-char) (backward-sexp -2) (thing-at-point 'symbol)) (thing-at-point 'symbol)))) (when def (setq def (and (locate-file-completion def path 'test) def))) (list (completing-read "Library name: " 'locate-file-completion path nil nil nil def)))) (let ((buf (find-file-noselect (find-library-name library)))) (pop-to-buffer buf 'other-window))) ; M-x find-library-other-window RET frame.el RET ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-19 17:43 ` Drew Adams @ 2011-06-19 18:50 ` martin rudalics 2011-06-19 20:13 ` Drew Adams 1 sibling, 0 replies; 29+ messages in thread From: martin rudalics @ 2011-06-19 18:50 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > FYI - This bug is fixed by the second version of window that you sent me today, [...] > (P.S. The attached file assumes your latest window.el is in the current > directory and named "window-2011-06-19a-MARTIN.el".) This bug was already fixed (and closed) a couple of days ago ;-) martin ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-19 17:43 ` Drew Adams 2011-06-19 18:50 ` martin rudalics @ 2011-06-19 20:13 ` Drew Adams 1 sibling, 0 replies; 29+ messages in thread From: Drew Adams @ 2011-06-19 20:13 UTC (permalink / raw) To: 'martin rudalics'; +Cc: 8865 However, I would still appreciate some guidance wrt replacing current (pre Emacs 24) tests of `pop-up-frames' and, more generally, the use of `display-buffer-alist' (both as a user and wrt code that would test its value). IOW, there are open questions about `display-buffer-alist' raised in this bug thread. Even as some of these bugs introduced by your changes get fixed, so that the new Emacs code becomes more correctly backward-compatible wrt `pop-up-frames', the goal is to move away from `pop-up-frames'. So that is where more guidance would be helpful, for both users and elisp programmers. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 22:15 ` Drew Adams 2011-06-16 13:01 ` martin rudalics @ 2011-06-16 13:09 ` Stefan Monnier 2011-06-16 14:02 ` Drew Adams 1 sibling, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-06-16 13:09 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > BTW, can you tell me what is a reasonable substitute for tests of > `pop-up-frames' now? That is, what to do about code that has (if > pop-up-frames ...)? What is the replacement for such a test in Emacs > 24? Thx. Depends on the intention behind that test, I guess. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-16 13:09 ` Stefan Monnier @ 2011-06-16 14:02 ` Drew Adams 2011-06-17 2:44 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-16 14:02 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 8865 > > BTW, can you tell me what is a reasonable substitute for tests of > > `pop-up-frames' now? That is, what to do about code that has (if > > pop-up-frames ...)? What is the replacement for such a > > test in Emacs 24? Thx. > > Depends on the intention behind that test, I guess. The intention of that test has to be to determine whether `pop-up-frames' is nil or non-nil, since that was the original design of `pop-up-frames'. Non-nil was designed to mean that `display-buffer' uses another frame. From the Emacs 20-23 doc string (and probably ever since the variable existed - probably Emacs 18): "Non-nil means `display-buffer' should make a separate frame." Emacs 23 added a particular non-nil value, `graphic-only', but the simple nil/non-nil test behavior is what I'm after and is what the Emacs source code has used as well - it's generally graphic displays that my code is concerned with wrt frames. See my reply to Martin for examples, if that helps. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-16 14:02 ` Drew Adams @ 2011-06-17 2:44 ` Stefan Monnier 2011-06-17 15:08 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-06-17 2:44 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 >> Depends on the intention behind that test, I guess. > The intention of that test has to be to determine whether > `pop-up-frames' is nil or non-nil, since that was the original design > of `pop-up-frames'. You're describing the test, not its intention. > Non-nil was designed to mean that `display-buffer' uses another frame. Actually, it's a bit more complex than that, since display-buffer may use another frame even if pop-up-frames is nil (e.g. via special-display-buffer-names), or it may use the same frame even when pop-up-frames is non-nil, e.g. if it's already displayed. Do you have some example to point to, so we can try and see what new predicate to define to provided the needed info? Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 2:44 ` Stefan Monnier @ 2011-06-17 15:08 ` Drew Adams 2011-06-17 16:21 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-17 15:08 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 8865 > >> Depends on the intention behind that test, I guess. > > The intention of that test has to be to determine whether > > `pop-up-frames' is nil or non-nil, since that was the > > original design of `pop-up-frames'. > > You're describing the test, not its intention. The intention has to include what happens - what the test does, or else the intention was not correctly realized in practice. My question was about replacing such a test. The common denominator of the intentions behind using such tests is what all of those tests do (have in common): distinguish nil `pop-up-frames' from non-nil. Nothing more. The behavior that results from distinguishing nil from non-nil `pop-to-frames' prior to Martin's changes is the behavior I want to reproduce after Martin's changes. If it is not enough now (to get the same behavior as before) to just test `pop-up-frames' for nil/non-nil, or if there is a new preferred way, then I want to use that new alternative (with Emacs 24). In sum, if you say "X is deprecated" or no longer recommended then please add "Use Y instead", where you are _specific_ about how to accomplish the _same_ thing. That does not mean just saying "Use `display-buffer-alist' instead of `pop-up-frames', if there is no obvious one-to-one mapping. That is all we say currently in the "This variable is obsolete" guidance. It might be enough for there, but I'm asking for more explanation/detail/guidance. As Martin replied to Thierry vis-a-vis his figuring out `display-buffer-alist' in its relation to `pop-to-buffer': "I didn't expect anyone even to try to understand this." Likewise for its relation to `pop-up-frames': a little more explanation is in order, to guide users. > > Non-nil was designed to mean that `display-buffer' uses > > another frame. > > Actually, it's a bit more complex than that, since display-buffer may > use another frame even if pop-up-frames is nil (e.g. via > special-display-buffer-names), or it may use the same frame even when > pop-up-frames is non-nil, e.g. if it's already displayed. I was being succinct, as in the first line of the doc string: "Whether `display-buffer' should make a separate frame." But I also went into more detail, just as you do. > Do you have some example to point to, so we can try and see what new > predicate to define to provided the needed info? See my reply to Martin. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 15:08 ` Drew Adams @ 2011-06-17 16:21 ` Stefan Monnier 2011-06-17 18:31 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-06-17 16:21 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > My question was about replacing such a test. The common denominator of the > intentions behind using such tests is what all of those tests do (have in > common): distinguish nil `pop-up-frames' from non-nil. Nothing more. If that's all you want to do, then "(if pop-up-frames" is (trivially) the only answer. But I'm pretty sure that's not the answer you're looking for because I'm pretty sure that "test if pop-up-frames is non-nil" was *not* the intention behind the code. Now, it might be true that the coder doesn't know his own intention. It's a common problem. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 16:21 ` Stefan Monnier @ 2011-06-17 18:31 ` Drew Adams 2011-06-17 21:46 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-17 18:31 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 8865 > > My question was about replacing such a test. The common > > denominator of the intentions behind using such tests is > > what all of those tests do (have in common): distinguish > > nil `pop-up-frames' from non-nil. Nothing more. > > If that's all you want to do, then "(if pop-up-frames" is (trivially) > the only answer. Well, yes, in Emacs 20-23. But if `pop-up-frames' is being deprecated then what is the _replacement_ for such a test, going forward? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 18:31 ` Drew Adams @ 2011-06-17 21:46 ` Stefan Monnier 2011-06-17 23:55 ` Drew Adams 0 siblings, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2011-06-17 21:46 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 >> > My question was about replacing such a test. The common >> > denominator of the intentions behind using such tests is >> > what all of those tests do (have in common): distinguish >> > nil `pop-up-frames' from non-nil. Nothing more. >> If that's all you want to do, then "(if pop-up-frames" is (trivially) >> the only answer. > Well, yes, in Emacs 20-23. But if `pop-up-frames' is being deprecated > then what is the _replacement_ for such a test, going forward? If your point is to test pop-up-frames, then by all means do that. And if it disappears, then change your code so it doesn't signal an error. As long as you don't give me the intention behind the check, there is no better answer. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 21:46 ` Stefan Monnier @ 2011-06-17 23:55 ` Drew Adams 2011-06-18 1:51 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Drew Adams @ 2011-06-17 23:55 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 8865 > >> > My question was about replacing such a test. The common > >> > denominator of the intentions behind using such tests is > >> > what all of those tests do (have in common): distinguish > >> > nil `pop-up-frames' from non-nil. Nothing more. > >> If that's all you want to do, then "(if pop-up-frames" is > >> (trivially) the only answer. > > > Well, yes, in Emacs 20-23. But if `pop-up-frames' is being > > deprecated then what is the _replacement_ for such a test, > > going forward? > > If your point is to test pop-up-frames, then by all means do that. No, why do you keep saying that? My point _in Emacs 20-23_ was to test `pop-up-frames'. I'm looking to do for Emacs 24+ whatever is appropriate, to get the same or very similar behavior. My point is _not_ to test `pop-up-frames' in Emacs 24+, but to test whatever is now recommended instead of `pop-up-frames', in order to get the same/similar behavior as before. Don't you have the same problem in the Emacs sources? There are plenty of tests of `pop-up-frames' there. How will you be replacing them? I have only two such tests in my code. I'm trying to learn what to do in their stead. You say in effect "don't test `pop-up-frames' anymore", and my question is OK, what do I test instead to get the same effect? > And if it disappears, then change your code so it doesn't signal > an error. As long as you don't give me the intention behind the > check, there is no better answer. The intention (in Emacs < 24) was to key the code's behavior off of `pop-up-frames' as specified by the user, in order to DTRT based on the intention about `display-buffer' and separate frames that the user communicated via `pop-up-frames'. For Emacs 24+ the intention is to key the behavior off of the new variable that replaces `pop-up-frames', whatever it is. I realize that there is no simple variable that corresponds to `pop-up-frames'. I'm asking about whatever is equivalent (as much as possible) and can be similarly tested - presumably some part of `display-buffer-alist'. What is an equivalent test, for `d-b-a'? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-17 23:55 ` Drew Adams @ 2011-06-18 1:51 ` Stefan Monnier 0 siblings, 0 replies; 29+ messages in thread From: Stefan Monnier @ 2011-06-18 1:51 UTC (permalink / raw) To: Drew Adams; +Cc: 8865 > My point _in Emacs 20-23_ was to test `pop-up-frames'. And I'm telling you that you're wrong. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' 2011-06-15 17:44 ` martin rudalics 2011-06-15 17:53 ` Drew Adams @ 2011-06-16 8:45 ` martin rudalics 1 sibling, 0 replies; 29+ messages in thread From: martin rudalics @ 2011-06-16 8:45 UTC (permalink / raw) To: 8865-done Fixed on trunk in revision 104603. martin ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-06-19 20:13 UTC | newest] Thread overview: 29+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-14 18:14 bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' Drew Adams 2011-06-14 19:08 ` martin rudalics 2011-06-14 19:43 ` Drew Adams 2011-06-15 9:24 ` martin rudalics 2011-06-15 16:14 ` Drew Adams 2011-06-15 16:26 ` martin rudalics 2011-06-15 17:11 ` Drew Adams 2011-06-15 17:44 ` martin rudalics 2011-06-15 17:53 ` Drew Adams 2011-06-15 22:15 ` Drew Adams 2011-06-16 13:01 ` martin rudalics 2011-06-16 14:01 ` Drew Adams 2011-06-16 15:08 ` martin rudalics 2011-06-16 16:03 ` Drew Adams 2011-06-17 15:46 ` martin rudalics 2011-06-17 18:31 ` Drew Adams 2011-06-19 17:43 ` Drew Adams 2011-06-19 18:50 ` martin rudalics 2011-06-19 20:13 ` Drew Adams 2011-06-16 13:09 ` Stefan Monnier 2011-06-16 14:02 ` Drew Adams 2011-06-17 2:44 ` Stefan Monnier 2011-06-17 15:08 ` Drew Adams 2011-06-17 16:21 ` Stefan Monnier 2011-06-17 18:31 ` Drew Adams 2011-06-17 21:46 ` Stefan Monnier 2011-06-17 23:55 ` Drew Adams 2011-06-18 1:51 ` Stefan Monnier 2011-06-16 8:45 ` martin rudalics
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.