[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-
bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH]
Sun, 27 May 2012 15:21:22 +0200
>> 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
> frame (if `one-window-p') and (b) burial of the buffer. And this should
> 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
> alone seems to remove/hide the window - great. And that is why more people
> 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
> 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
> point to a reasonable situation where it does not DTRT - IOW, where what it
> 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).