[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 08:34:56 -0700 |
> It was disabled by `dired-pop-to-buffer'. Already fixed in my patch.
I see.
> >> 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.
>
> Have you set `frame-auto-hide-function' to `delete-frame'?
In my own setup, yes. No doubt that is why I don't have a problem with it.
But that's not a reason that users with just the two settings I mentioned should
see this problem.
Whatever the cause (and various user configs can lead to this), if the buffer is
displayed in a separate frame there is _no_ reason, ever, to keep this frame (or
its window or its buffer). Occam says delete it - don't just "hide" it.
This is part of the logic of this particular user interaction. And yes, I
realize that there is no general definition of such a "dialog" interaction in
Emacs (yet). But in handling this particular interaction it is clear to the
code and its designers that the frame+window+buffer have no further use.
Knowing that, the code should DTRT. Iconifying here makes no sense, even if a
user might choose iconifying in general as his preference for
`frame-auto-hide-function'. That option is about hiding a frame. There is no
reason to hide this frame. There is no reason to keep this frame (or its window
or buffer).
That's the point. It is not about `frame-auto-hide-function', which is a user
preference about hiding frames. It is about the logic of this particular user
interaction and the raison d'etre for this buffer/window/frame. When they no
longer have any reason for existing they should be deleted - regardless of the
value of `frame-auto-hide-function'.
> The current handling of `special-display-regexps' seems to
> override the way Emacs 22 behaved in this regard.
It is good in general that `special-display-regexps' be respected.
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/05
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames',
Drew Adams <=
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', martin rudalics, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/06
- bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames', Drew Adams, 2012/04/18