RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

I thought this had been fixed. CVS shows that the code and doc string are still
problematic. The only thing that was done was to comment out the silly
`lower-frame' and `make-frame(-in)-visible' dance and add a comment saying that
that was harmful and silly. (That at least stopped the frame from being
lowered.)

I sent this code (*twice*), which DTRT. It simply displays the buffer in another
frame. (If it's important, you can add null bindings for `same-window-*' and
return the selected window, as before.)

(defun display-buffer-other-frame (buffer)
  "Show BUFFER in another frame, but don't select it.
See documentation of `display-buffer' for more information."
  (interactive "BDisplay buffer in other frame: ")
  (let ((win (selected-window)))
    (switch-to-buffer-other-frame buffer)
    (select-window win)
    (select-frame-set-input-focus (window-frame win))))

That suggestion was ignored. 

At least on Windows, with the change that was made instead, the command doesn't
just display the buffer in another frame. It also selects the buffer, so it does
the same thing as `switch-to-buffer-other-frame'. Displaying a buffer is not the
same as switching to it. We don't need two different commands with two key
bindings to switch to a buffer in another frame.

On Windows, at least, frame focus changes when you display a buffer the way the
current code does. You need to explicitly set the frame focus back to the
original window, to not have it change. Perhaps there is another way - dunno.

If this command is supposed to do what its name suggests, then it is implemented
wrong, IMO. Do it a different way, if you want, but please do what the command
name says, not something else.

In any case, the doc string is (still) incorrect. The first line is still
identical to that of `switch-to-buffer-other-frame', and it still implies that
the buffer is selected (which it is, on Windows, but which is presumably not the
intention).

Why is it so hard to get such a simple correction made? A 13-mail thread, for
nada. Why just add a complex comment about the old code being brain-dead,
instead of DTRT? One of us is not getting it.

Here is the current definition:

(defun display-buffer-other-frame (buffer)
  "Switch to buffer BUFFER in another frame.
This uses the function `display-buffer' as a subroutine; see its
documentation for additional customization information."
  (interactive "BDisplay buffer in other frame: ")
  (let ((pop-up-frames t)
          same-window-buffer-names same-window-regexps
        (old-window (selected-window))
          new-window)
    (setq new-window (display-buffer buffer t))
    ;; This may have been here in order to prevent the new frame from hiding
    ;; the old frame.  But it does more harm than good.
    ;; Maybe we should call `raise-window' on the old-frame instead?  --Stef
    ;;(lower-frame (window-frame new-window))

    ;; This may have been here in order to make sure the old-frame gets the
    ;; focus.  But not only can it cause an annoying flicker, with some
    ;; window-managers it just makes the window invisible, with no easy
    ;; way to recover it.  --Stef
    ;;(make-frame-invisible (window-frame old-window))
    ;;(make-frame-visible (window-frame old-window))
    ))

> From: Drew Adams Sent: Sunday, March 09, 2008 11:01 AM
> Is the command `display-buffer-other-frame' useful as it is currently
> designed? It displays a buffer in another frame, but it also lowers
> that frame among all window-manager windows. Even if the buffer was
> already displayed in another frame, that frame is still lowered behind
> all others.
>  
> That hardly seems like TRT. If you ask to display a buffer, you don't
> want it to be buried out of sight behind all other window-manager
> windows.
>  
> Aside from the question of its usefulness, I wonder about its doc
> string. The first line of the doc string is identical to the first
> line of the doc string of `switch-to-buffer-other-frame': "Switch to
> buffer BUFFER in another frame." 
>  
> But `display-buffer-other-frame' does *not* switch to the buffer (it
> does not select it); it simply displays it (in a not-very-visible
> fashion). Contrast that with the doc string of `display-buffer', whose
> first line explicitly says that the buffer is not selected: "Make
> BUFFER appear in some window but don't select it."
>  
> Command `display-buffer-other-frame' is not documented in any manual -
> perhaps for good reason. It seems half-baked, to me.