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

[Drew Adams]

> It was disabled by `dired-pop-to-buffer'.  Already fixed in my patch.

I see.

>  >> Would the attached patch fix it?
>  >
>  > For my own complete setup, yes.  But that's no doubt 
>  > because I take other measures elsewhere.
>  >
>  > For the recipe I gave, however (see above), no.  The 
>  > separate `*Deletions*' frame popped up just becomes
>  > iconified.  It is still available as a frame (and
>  > as a buffer).  It is still in the list of frames, and
>  > it is thus shown in the MS Windows task bar.
> 
> Have you set `frame-auto-hide-function' to `delete-frame'?

In my own setup, yes.  No doubt that is why I don't have a problem with it.

But that's not a reason that users with just the two settings I mentioned should
see this problem.

Whatever the cause (and various user configs can lead to this), if the buffer is
displayed in a separate frame there is _no_ reason, ever, to keep this frame (or
its window or its buffer).  Occam says delete it - don't just "hide" it.

This is part of the logic of this particular user interaction.  And yes, I
realize that there is no general definition of such a "dialog" interaction in
Emacs (yet).  But in handling this particular interaction it is clear to the
code and its designers that the frame+window+buffer have no further use.

Knowing that, the code should DTRT.  Iconifying here makes no sense, even if a
user might choose iconifying in general as his preference for
`frame-auto-hide-function'.  That option is about hiding a frame.  There is no
reason to hide this frame.  There is no reason to keep this frame (or its window
or buffer).

That's the point.  It is not about `frame-auto-hide-function', which is a user
preference about hiding frames.  It is about the logic of this particular user
interaction and the raison d'etre for this buffer/window/frame.  When they no
longer have any reason for existing they should be deleted - regardless of the
value of `frame-auto-hide-function'.

> The current handling of `special-display-regexps' seems to 
> override the way Emacs 22 behaved in this regard.

It is good in general that `special-display-regexps' be respected.