RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

>  >> 1. Goto *scratch* and eval the form above.
>  >> 2. (def<TAB> ==> a comletion frame pops up *and gets input focus*
>  >
>  > This input focus issue is a problem, indeed, but AFAIK 
>  > it's one that's difficult to fix.
> 
> Drew uses `redirect-frame-focus' and from what I can tell after
> experimenting a bit with his code it seems to work.

Yes, but I do that explicitly as part of my setup, and only for the
`*Completions*' frame.  I know ahead of time that Emacs will use buffer
`*Completions*', and I know that its input focus should be redirected to the
minibuffer frame (by default).

But as I mentioned, there are occasionally some other frames that pop up in a
context where the focus should remain in the minibuffer.  In my case, buffers
named `*...*' are special-display (dedicated), so they pop up in separate
frames.  Only rarely is such a buffer used as part of a dialog, but it can
happen, breaking the necessary input focus.

Some such pop-up frames are in fact for completion.  Some vanilla and 3rd-party
Emacs code uses completion with a buffer other than `*Completions*'.  Nothing
inherently wrong with that, but it thus steps outside my workaround of
redirecting the `*Completions*' frame focus to the minibuffer frame.

For instance, after `M-e' in Isearch, `M-TAB' completes, and if there is more
than one candidate then it pops up buffer `*Isearch completions*' (not
`*Completions*').

Since that buffer name matches my `special-display-regexps', it gets a separate,
dedicated frame.  And when the new frame is created Windows gives it the focus,
taking the focus away from the minibuffer frame.  Without some extra, workaround
coding for such a case the user needs to click the minibuffer frame to get the
focus back where it belongs.

And obviously a user cannot really special-code or customize to deal with each
such pop-up frame that might arise.  Nothing prevents a library (vanilla or
otherwise) from popping up a buffer whose name matches
`special-display-regexps', including for completion or another context where the
focus should not move to another frame.

And then there's the problem of removing that popped-up frame when the dialog is
finished.  Similarly, there I can foresee the problem in the case of
`*Completions*' and handle it specially (knowing the completion dialog).  Not so
in the general case (unknown).

Again, in practice there are only very few such pop-up dialog frames, other than
`*Completions*'.  But there is still a general problem, even if it is rare
because I've taken care of it for the main case (`*Completions*').

I know that you know all of this already.  Just mentioning it to complete the
thread info a bit.


Perhaps we could add a way for code to indicate that it is displaying a given
buffer only for the purpose and duration of a user dialog, and thus:

a. For that duration the buffer's frame (if separate) would have its input focus
redirected to the minibuffer's frame.

b. After the dialog finishes, the buffer's frame (if separate) would be deleted.

E.g., something like: (with-dialog-buffer BUF ...)

Perhaps something like that could be a way to handle the general case (providing
that coders actually used it).