[Top][All Lists]

[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-

From: Drew Adams
Subject: bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames'
Date: Fri, 6 Apr 2012 07:44:08 -0700

>  > emacs -Q
>  > (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
>  > (setq pop-up-frame t)
> I suppose you mean (setq pop-up-frames t)


> but apparently this variable is no more supported by `display-buffer'
> (I'm not sure whether that's by design).

I don't know what you mean by that.  Dunno whether it is supported by
`display-buffer, but I do still use `pop-up-frames' and it works fine in general
(apart from this bug, AFAIK).  And I thought you took care to ensure that it
did, for Emacs 24.

>  > C-x d whatever-dir
>  > Mark 4 files for deletion.  Hit `x'.  Answer `yes'.
>  > The *Deletions* frame remains displayed.
> 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.

And on Windows at least, iconification is quite distracting.  The frame does not
simply disappear (and simultaneously get added to the task bar).  The frame
zooms down to the task bar in an animated fashion.  Quite annoying.

There is no need for either the frame or the window - or the buffer for that
matter, after the deletions are done (or the copies or whatever
`dired-mark-pop-up' was used for).

By Occam's razor, no need means Emacs should not keep these things around
vestigially - especially not so that users encounter them. 

> This is NOT a generic fix - it might fail miserably if the buffer in
> question is shown in two windows simultaneously.  Apparently 
> this is no great issue in the case at hand since
> `dired-pop-to-buffer' already calls `get-buffer-window'.
> I earlier provided a variable called `display-buffer-window'
> for this and related issues but Stefan didn't like it.

FWIW, the fix I sent still works.  Perhaps it can be improved upon to satisfy
whatever other needs you see that it does not quite satisfy?

One way or another, the regression needs to be fixed.  Things were OK back in
Emacs 22.  There should be no reason why we cannot make them OK again in this

In Emacs 22 the buffer was not shown in a separate frame, disrespecting
`special-display-regexps'.  I prefer (slightly) that the latter be respected, so
that the buffer is shown in a separate frame.  But only if the frame, like a
pop-up window, is completely removed when done.

Given the choice between your fix and the Emacs 22 behavior, I vastly prefer the
latter: no distraction, simple, over and done with, never see `*Deletions*' or
whatever again.

Thanks for trying to fix this, Martin.  I hope we can find a solution that is
satisfactory.  The fix I sent is good enough for me, but I understand if it is
not good enough for you.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]