RE: Usage examples of dedicated windows and popup frames?

["Drew Adams" <drew.adams@oracle.com>]

> >>> Maybe we could make the *Completions* frame (optionally) invisible
> >>> instead of iconfying it?

Whatever we decide to do, the behavior should be easily under user control.  We
can decide on a _default_ behavior (iconify, delete, make invisible, do
nothing,...), but the user should be able to choose (easily).

> >> What's "invisible" in this respect?  (In any case, I'd try it out.)
> >
> > Hmm, invisible is invisible, see section 28.10 of the Elisp manual.
> > That is, we could make the frame optionally invisible and make it
> > visible again when it's needed.  For example, when I evaluate the
> > following three forms step by step
> > (setq my-frame (make-frame))
> > (make-frame-invisible my-frame)
> > (make-frame-visible my-frame)
> > my-frame is visible and has input focus after the third step.
> 
> Yes, that's nice.  I think that's better as a default action 
> for frames showing completion, because it's less distracting if
> iconification is animated, and it doesn't clutter the window
> manager switcher with temporary frames you usually don't want to
> switch to anyway.

I have used invisible frames.

But, FWIW, every time I wrote something about invisible frames here I heard back
from "those who know" (TM) that invisible frames are broken, i.e., there are
some problems with them (things that don't work).

I never found out what those problematic things were or why they
wouldn't/couldn't be fixed.  Just mentioning this.  Maybe there are some
problems with invisible frames.

> > If I do
> > (let ((frame (selected-frame)))
> >   (make-frame-visible my-frame)
> >   (raise-frame frame))
> > as third step, the original frame is in the foreground,
> 
> Yes, here, too.
> 
> > and if I do
> > (let ((frame (selected-frame)))
> >   (make-frame-visible my-frame)
> >   (redirect-frame-focus my-frame frame))
> > as third step, my-frame is risen but typing input goes to 
> > the original frame.
> 
> After evaluating that form, my emacs froze so that I had to kill it.
> C-g didn't work anymore.  However, I cannot reproduce that with emacs
> -Q...

My take on the _default_ behavior (see above wrt user control) is that the frame
should be deleted, not made invisible (and not iconified).

I use frames a lot.  Invisible frames constitute a useful set of frames for
frame and frame-configuration operations.  I do not want temporary frames such
as those for user input dialogs to clutter up the list of invisible frames when
they are "removed".  That's not removal, it's simply non-display.

An analogy that everyone is familiar with is having "invisible" (i.e.,
undisplayed) buffers around.  You might not be very familiar with manipulating
frames or sets of frames, including those that are invisible, but you sure are
familiar with doing somewhat similar things with buffers.

For buffers, we even went to the trouble of creating a special (syntactic) class
of buffers that are ignored by many operations: those whose names start with a
space char.  That's a hack (OK, but rudimentary) to distinguish the unimportant
"invisible" buffers from the other "invisible" buffers.

Let's not go that way wrt invisible frames.  AFAICT, there is no need to keep
temporary, dialog frames around, in any state, once their raison d'etre (the
dialog) is finished.

Adding temporary user-input dialog pop-up frames (such as *Completions* or the
list of marked files for a Dired operation) to the set of invisible frames is
not the way to go, at least for anyone who actually uses invisible frames.

That should at least not be the default behavior, IMO.  Doing that would make
using invisible frames even less useful than it is today (where there are
supposedly a few problems).

The default behavior should be to _delete_ the frame, IMO.  A temporary, pop-up
frame generally has no need to live on, even in some phantom state.  Get it out
of there altogether.  If there is another dialog then a new frame will be popped
up for it - nothing lost, no problem.