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

[martin rudalics]

>> IIUC your patch works regardless of the value of
>> `frame-auto-hide-function'.  The problem of your patch is that in
>>    (if (one-window-p) (delete-frame) (delete-window))
>> the window for showing the buffer may have been _reused_ in which case
>> deleting is certainly the wrong solution.
>
> I do not understand how/why that window would or should be reused.

When a user sets both `pop-up-frames' and `pop-up-windows' to nil,
usually a window gets reused.  If this is the only window on its frame
and there are no other frames, the `delete-frame' call causes an error
because it's within the scope of the `save-window-excursion'.

> Especially between the time it becomes displayed and the end of the calling
> function.  The window is only for the user interaction of confirming (or not)
> the operation on the marked files.
>
> The existing code seems to reflect this aim in that it uses
> `save-window-excursion'.  What is still missing is (a) deletion of the window 
or
> frame (if `one-window-p') and (b) burial of the buffer.  And this should 
happen
> always, regardless of what the user does, including `C-g'.

If the window was reused, the previous buffer should be shown.  In
practice, this is handled by the `save-window-excursion' unless a window
on another frame gets reused.

> If the buffer is not shown in a separate frame then the 
`save-window-excursion'
> alone seems to remove/hide the window - great.  And that is why more people 
are
> not complaining about this regression, IMO.
>
> But if the buffer is shown in a separate frame (e.g. due to
> `special-buffer-regexps') then `save-window-excursion' is simply not 
sufficient.
> The frame remains displayed after the user interaction, regardless of what the
> user does during the interaction (including `C-g').
>
> Attached is a patch against the latest source code.  AFAIK it DTRT.  Can 
anyone
> point to a reasonable situation where it does not DTRT - IOW, where what it 
does
> is inappropriate?  If not, can this please be installed for Emacs 24.1, to
> eliminate this regression?  Thx.

Your new patch is better since it moves the frame deletion out of the
scope of the window excursion.  It's still not OK when a window on
another frame gets reused but I think that use case can be ignored at
the moment (it's neither provided by any of the stock buffer display
functions nor is it handled by the present code anyway).

martin