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

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

>  > For emacs -Q:
>  >
>  > Without my fix and with your patch the frame is iconified, 
>  > without changing `frame-auto-hide-function'.
>  >
>  > Without my fix and with your patch the frame is deleted, if
>  > `frame-auto-hide-function' is `delete-frame'.
> 
> That's what this option has been meant for.

Yes, in the general case.  It is a general user option.  IMO, it does not apply
here, that is, it should not govern the behavior here.

>  > I can't judge what it should default to because I hardly ever
>  > use multiple frames and never use `dired'.

We've been around the default-value barn several times already.  Stefan wants
iconifying as the default.  I'm happy if users can at least customize it to get
deletion.

>  > My point was that users should not have to customize this 
>  > option just to fix this regression.  It is reasonable for
>  > a user to prefer iconifying for frames that s?he wants to
>  > keep, but still, naturally, want this frame to be deleted, as
>  > it has no reason for being anymore.
> 
> We can consider adding a third value for `frame-auto-hide-function'.

I think that's blowing things out of proportion.  There is no need for a user
option for this.  A user option is for general behavior.  Unless, that is, you
can characterize such behavior as a general class that is recognizable.  But I
thought that was the problem: no "dialog" thingy exists.

IMO, the proper fix here is specific to this command.  And to any others that we
run into that pop up a frame only temporarily, for the duration of some well
defined (recognizable) user interaction.

>  > If you were not averse to binding a user option for a 
>  > local use, perhaps you could just bind `frame-auto-hide-function'
>  > to `delete-frame' for the duration of the command.  That should
>  > DTRT, and such a temporary binding should not bother
>  > anyone (IMHO).
> 
> If we decide that deleting the frame is the correct solution in this
> particular case, the most simple option is to call `quit-window' with
> both arguments t, thus killing the buffer as well.

Sounds good to me, IIUC.  Does anyone claim that deleting the frame (& window &
buffer) is not the correct solution in this situation?