* Re: Inconsistent behaviour of display-buffer, pop-to-buffer
2008-03-01 4:27 ` Inconsistent behaviour of display-buffer, pop-to-buffer Otto Maddox
@ 2008-03-05 21:05 ` Chong Yidong
2009-01-04 19:20 ` bug#30: marked as done (Inconsistent behaviour of display-buffer, pop-to-buffer) Emacs bug Tracking System
1 sibling, 0 replies; 3+ messages in thread
From: Chong Yidong @ 2008-03-05 21:05 UTC (permalink / raw)
To: bug-gnu-emacs
"Otto Maddox" <ottomaddox@fastmail.fm> writes:
> When running Emacs on either X or Mac OS X:
>
> ;; Similar to display-buffer-other-frame, but without all the
> ;; raise-frame, make-frame-{in,}visible stuff. The point is to
> ;; illustrate annoyingly inconsistent behaviour of display-buffer.
> (defun my-display-buffer (buf)
> (let ((pop-up-frames t)
> same-window-buffer-names
> same-window-regexps)
> (display-buffer buf t)))
>
> Create but don't display a buffer named "foo":
> (get-buffer-create "foo")
>
> Pop up a new frame, selected and WITH focus:
> (my-display-buffer "foo")
>
> Go back to the original frame with C-x 5 o
>
> Pop up the "foo" frame, selected but WITHOUT focus this time:
> (my-display-buffer "foo")
I'll take a look at this, but my feeling is that this is a window
manager issue. The window manager automatically selects any new frame
that Emacs creates, and this is not necessarily something we can (or
should) change.
^ permalink raw reply [flat|nested] 3+ messages in thread* bug#30: marked as done (Inconsistent behaviour of display-buffer, pop-to-buffer)
2008-03-01 4:27 ` Inconsistent behaviour of display-buffer, pop-to-buffer Otto Maddox
2008-03-05 21:05 ` Chong Yidong
@ 2009-01-04 19:20 ` Emacs bug Tracking System
1 sibling, 0 replies; 3+ messages in thread
From: Emacs bug Tracking System @ 2009-01-04 19:20 UTC (permalink / raw)
To: martin rudalics
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
Your message dated Sun, 04 Jan 2009 20:10:00 +0100
with message-id <49610988.9000607@gmx.at>
and subject line Re: Inconsistent behaviour of display-buffer, pop-to-buffer
has caused the Emacs bug report #30,
regarding Inconsistent behaviour of display-buffer, pop-to-buffer
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)
--
30: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=30
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
[-- Attachment #2: Type: message/rfc822, Size: 6330 bytes --]
From: "Otto Maddox" <ottomaddox@fastmail.fm>
To: bug-gnu-emacs@gnu.org
Subject: Inconsistent behaviour of display-buffer, pop-to-buffer
Date: Sat, 01 Mar 2008 04:27:23 +0000
Message-ID: <1204345643.1966.1239939351@webmail.messagingengine.com>
When running Emacs on either X or Mac OS X:
;; Similar to display-buffer-other-frame, but without all the
;; raise-frame, make-frame-{in,}visible stuff. The point is to
;; illustrate annoyingly inconsistent behaviour of display-buffer.
(defun my-display-buffer (buf)
(let ((pop-up-frames t)
same-window-buffer-names
same-window-regexps)
(display-buffer buf t)))
Create but don't display a buffer named "foo":
(get-buffer-create "foo")
Pop up a new frame, selected and WITH focus:
(my-display-buffer "foo")
Go back to the original frame with C-x 5 o
Pop up the "foo" frame, selected but WITHOUT focus this time:
(my-display-buffer "foo")
????
Again, go back to the original frame with C-x 5 o and also do
C-x b foo RET to make "foo" the current buffer. Two issues this time.
The other "foo" frame is not raised but a new frame is unnecessarily
created (the doc says that pop-up-frames means that visible and
iconified frames should be searched). Also, the newly created frame
is WITH focus this time:
(my-display-buffer "foo")
The same inconsistent behaviour happens if you substitute
pop-to-buffer for display-buffer in the definition of
my-display-buffer, which seems definitely buggy because the doc for
pop-to-buffer says that it should select the buffer.
In GNU Emacs 22.1.1 (powerpc-apple-darwin8.9.0, Carbon Version 1.6.0)
of 2007-06-08
--
Otto Maddox
ottomaddox@fastmail.fm
--
http://www.fastmail.fm - The professional email service
[-- Attachment #3: Type: message/rfc822, Size: 1971 bytes --]
From: martin rudalics <rudalics@gmx.at>
To: 30-done@emacsbugs.donarmstrong.com
Cc: ottomaddox@fastmail.fm
Subject: Re: Inconsistent behaviour of display-buffer, pop-to-buffer
Date: Sun, 04 Jan 2009 20:10:00 +0100
Message-ID: <49610988.9000607@gmx.at>
This bug should now have been resolved for CVS Emacs by the following
two fixes:
2008-09-11 Martin Rudalics <rudalics@gmx.at>
* window.el (pop-to-buffer): If the window for buffer-or-name is
not on the selected frame, raise that window's frame and give it
input focus. (Bug#745)
2009-01-04 Martin Rudalics <rudalics@gmx.at>
* window.el (display-buffer): When a buffer is displayed in the
selected and some other window, and not-this-window is non-nil,
try to return that other window instead of popping up a new
frame. (Bug#30)
Thanks for reporting, martin.
^ permalink raw reply [flat|nested] 3+ messages in thread