bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'

[Drew Adams]

>  > But what's the right test?  It is _not_ `pop-up-frames' non-nil,
>  > because users can do other things than that to cause a new 
>  > frame to be created for this dialog.  What's needed is a test of
>  > whether a frame was newly created for this dialog buffer.
>  > What's the code for that test?
> 
> In the past, routines usually tested the settings of variables like
> `pop-up-windows' or `pop-up-frames' to guess the expected behavior of
> `display-buffer'.  In most cases the guesses were correct.  In a few
> corner cases they failed and the example you cite above is 
> one of them.

What do you mean by "in the past"?  In the past I saw no such problem as that
reported in this bug.  (On the contrary - this annoyance was introduced in Emacs
23 - see below.)

> Here I have two things: A window parameter that tells for each window
> whether the current buffer is the first buffer shown in it and a
> separate global variable which gives some rudimentary 
> information about what the last `display-buffer' invocation did to find a 
> suitable window. The former exists independently of `display-buffer' so it 
> also works for a "manually" constructed or reused window or frame.  The latter
is
> `display-buffer' specific and is mainly used for providing some feedback
> about the change of the entire window configuration.

Please be specific.  What window parameter?  What global variable?  Just what
are you trying to say?  I can't even tell whether you're saying that you _have_
a solution or there _is no_ solution.

I repeat: "what's the right test?"  What's the solution?

>  > The bug report is about the annoyance of not deleting a 
>  > new frame that was created (using whatever mechanism, including non-nil 
>  > `pop-up-frames') for dialog purposes.  When the dialog is finished,
>  > such a new frame should disappear.  Users should not need to
>  > manually delete it.
> 
> There's no formal definition of "dialog purpose" in Emacs and it's not
> easy to do that in general.

No one's asking for a "formal definition" of anything.  The *Deletions* (or
whatever) window that lists the files that will be acted on if you type `yes' is
supplementary help for answering the prompt - nothing more.  Its only reason for
being displayed ends as soon as you've answered the prompt.

I call that a dialog: ask a question and pop up some help for understanding the
question, then remove the displayed help when the question is answered.  You can
call it anything you want.  No "formal definition" is needed here, AFAICS.

If for some reason we cannot fix this, with all of the fancy artillary we have
in Emacs 24, then please at least regress to the sane behavior of older
releases.

Until Emacs 23, the help buffer here (e.g. *Marked Files*, *Deletions*,
whatever) was always popped up as a window, not as a frame, even if you had
non-nil `pop-up-frames'.  And that window was (naturally) deleted when you type
yes/no.  That behavior was fine (IMO).  We've "progressed" to a PITA (introduced
in 23).

If you can obtain similar behavior for a popup frame, fine.  If not, then please
restore the pre-23.2 design for such dialogs.

> The major problem to address is whether and
> how such a dialog can be disrupted by other activities and 
> how to resume it at a later time.

If it's a major problem and you will end up complicating things further in order
to solve it, then I vote for a return to the simple behavior of the past.  That
at least was not annoying and did not force users to manually close frames.

Thx.