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

[Drew Adams]

> It's a pain to get ten files from there one by one.  Can't 
> you pack them and send them in an attachment together with
> the throw-... file?  I suppose you have them in one and the
> same directory and a thing like 7-zip around.  So this
> should be much easier for you ...

There are several bulk download methods for Icicles, if you feel that
right-clicking 10 times is onerous:

http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Libraries#toc5

Try one of the 3 download scripts (see the first two bullets).  If you don't
like any of the bulk download methods then I will send a 7zip archive to you by
mail - let me know.
 
>  > (let ((comp-buf  (get-buffer-create "*Completions*")))
>  >   (unless (get-buffer-window comp-buf 'visible)
>  >     (save-selected-window
>  >       (display-buffer comp-buf t 0) ; <== the problem, no doubt
>  >       (deactivate-mark))))
> 
> Could you explain what you think that happens, happens 
> instead, or does not happen here?  "0" won't do anything
> `display-buffer' without that argument would not have done
> anyway: Search all visible and iconified frames for a window
> showing comp-buf.

(Again, to be sure we're on the same page, this is a call to `display-buffer'
for Emacs prior to your changes.  Perhaps I need to modify it now, for Emacs
24+.)

The code above is Icicles code.  Icicles does not require users to use non-nil
`pop-up-frames' (and most do not probably).  In my own, personal setup I use
non-nil `pop-up-frames', but this code needs to work with any value of that
option.

You are the expert on `display-buffer', but this is my understanding.  From the
`display-buffer' doc string:

Emacs 20:

 If FRAME is 0, search all visible and iconified frames.
 If FRAME is nil, search only the selected frame
  (actually the last nonminibuffer frame),
  unless `pop-up-frames' is non-nil,
  which means search visible and iconified frames.

Emacs 22 says the same, but it adds "or `display-buffer-reuse-frames'" to
`pop-up-frames'.

Emacs 23 and Emacs 24 before your changes say the same as Emacs 22, but they
distinguish the `graphic-only' case of non-nil for pop-up-frames.

The Elisp manual says essentially the same thing.  The Emacs 23.3 manual says
only this about a nil value for FRAME (but it then lists a long page of other
options that also affect the behavior of `display-buffer').

 `nil' means consider windows on the selected frame.
 (Actually, the last non-minibuffer frame.)

IIUC, in the above code, I do not want nil for FRAME, because I do not want only
the selected frame checked for a *Completions* window.

> Maybe there are reasons why this argument is needed and I
> should put back its semantics but I never found one and
> don't find one here.

Do you see one now?  Am I missing something?

> IIUC the code tests whether it finds a visible window showing 
> comp-buf.  If it doesn't, either because the window doesn't
> exist or is not visible, it tries to get one on an iconified
> frame or make a new frame

New window, not new frame - no?

Unless `pop-up-frames is non-nil etc.  Again, please keep in mind that this is
general code for users with all possible values of `pop-up-frames' etc.

> and deactivate the mark there.  So you probably raise the frame of
> com-buf and then want to redirect focus from the comp-buf 
> window to your
> minibuffer window which probably was selected here, and finally you
> reselect the minibuffer window because of the `save-selected-window'.
> But for some reason the comp-buf window remains selected.  Is it that
> what you see?

I guess so.  I don't know about the explanation of why, but yes, as I described
earlier, for some reason the new *Completions* frame is getting the input
(keyboard) focus.  It is supposed to be a frame that always has its keyboard
input redirected to the minibuffer frame.

I suspect it's better to concentrate on the problem of input focus rather than
speaking only in terms of window/frame selection.  The new *Completions* frame
_appears_ selected even prior to your changes (as shown by the window mgr border
color, for instance), but the input focus is always correctly redirected to the
minibuffer frame.

That is the change (problem): the keyboard input focus.  It seems (symptom, not
explanation) as if the frame is no longer being correctly redirected, in terms
of input focus.

> Note: In all examples you sent me before you didn't have a thing like
> `save-selected-window' around a `display-buffer' call.

Not sure what you're saying there.  Is that not a good idea?

Thx - Drew