Subject: bug#8856: 24.0.50; regression: special-display-frame is no longer dedicated

From: martin rudalics <[email-masked]>
Date: Sun, 26 Jun 2011 17:54:34 +0200

> I don't have a recipe to reproduce these latter symptoms.  But perhaps this is
 > all due to the window not being dedicated.

The window was dedicated initially but due to another `display-buffer'
call "reusing it" it became undedicated again.

Please use the `display-buffer-in-window' function below which doesn't
reset the status when the buffer remains unchanged.

martin

(defun display-buffer-in-window (buffer window specifiers)
   "Display BUFFER in WINDOW and raise its frame if needed.
WINDOW must be a live window and defaults to the selected one.
Return WINDOW.

SPECIFIERS must be a list of buffer display specifiers, see the
documentation of `display-buffer-alist' for a description."
   (setq buffer (normalize-live-buffer buffer))
   (setq window (normalize-live-window window))
   (let* ((old-frame (selected-frame))
	 (new-frame (window-frame window))
	 (dedicated (cdr (assq 'dedicated specifiers)))
	 (no-other-window (cdr (assq 'no-other-window specifiers))))
     ;; Show BUFFER in WINDOW.
     (unless (eq buffer (window-buffer window))
       ;; If we show another buffer in window, undedicate it first.
       (set-window-dedicated-p window nil))
     (set-window-buffer window buffer)
     (when dedicated
       (set-window-dedicated-p window dedicated))
     (when no-other-window
       (set-window-parameter window 'no-other-window t))
     (unless (or (eq old-frame new-frame)
		(not (frame-visible-p new-frame))
		;; Assume the selected frame is already visible enough.
		(eq new-frame (selected-frame))
		;; Assume the frame from which we invoked the minibuffer
		;; is visible.
		(and (minibuffer-window-active-p (selected-window))
		     (eq new-frame
			 (window-frame (minibuffer-selected-window)))))
       (raise-frame new-frame))
     ;; Return window.
     window))