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

[Drew Adams]

>  > M-x set-variable RET
>  >  special-display-regexps RET
>  >  ("[ ]?[*][^*]+[*]") RET
> 
> You shouldn't include the buffer in `special-display-regexps' in the
> first place.  Or, write a separate entry for such buffers.

That, my friend, is utterly ridiculous.  Why not just tell me I shouldn't use
Emacs because it inconveniences you?

That's why we have option `special-display-regexps'.  I _want_ such buffers to
be displayed in a separate frame whenever they are displayed.

And no, I do not want to be obliged to specify separately the name of each
buffer that Emacs might decide to use in a temporary dialog to provide info for
a dialog question.

That's just silly.  That you would even bring it up, let alone proclaim it as a
rule ("you shouldn't") suggests bad faith.

The fact that when using `C', `x', etc. in Dired Emacs cannot tell that the
temporary display of a pop-up buffer is no longer needed after you hit RET, and
that Emacs does not remove such a frame like it removes a temporary pop-up
window, is a failing on Emacs's part.

The word "brain-dead" comes to mind (for Emacs, not for you).  The world's best
editor was not built to act like this.  From a user perspective this is a
regression since Emacs 22.  Until release 23 Emacs was completely sane in this
respect - since Day One.

I've mentioned a couple of possible workarounds, the best of which is to just
return to the Emacs 22 behavior.

But ideally the code should be fixed to remove the frame when the Dired command
interaction is finished.  There is no reason to show the buffer after the
operation is done.  That buffer is a list of objects that _will_ be acted on
_if_ you confirm.  After you confirm (or deny) its display has no raison d'etre.

Apparently you think that the proper fix of removing the frame is too hard to
implement for some reason.  In that case I request that we return to the sane
behavior of Emacs 22.

>  > Alternatively, restore the behavior in Emacs 22, where even if
>  > `special-display-regexps' would normally cause the buffer 
>  > to be displayed in a separate frame it is not: it is popped
>  > up in a window of the current frame.
> 
> Not necessarily: Try customizing `dired-shrink-to-fit' to nil.

emacs -Q in Emacs 22 does exactly what I described: it pops up a window, not a
frame, and it removes the window when the user dialog is finished.

(And `dired-shrink-to-fit' should simply be removed.  The only reason it ever
existed was for people on connections less than 1200 baud (300, 900).  See
Richard's comment in the source code.)

Sounds like you are just _searching_ for reasons to defend this regression and
not fix this bug.