From: "Drew Adams" <drew.adams@oracle.com>
To: "'martin rudalics'" <rudalics@gmx.at>
Cc: 7533@debbugs.gnu.org
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 [thread overview]
Message-ID: <7F573FD9970448A282AF763F35489AA3@us.oracle.com> (raw)
In-Reply-To: <4F7F0386.6030909@gmx.at>
> 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.
next prev parent reply other threads:[~2012-04-06 15:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 18:35 bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2010-12-02 19:05 ` martin rudalics
2010-12-02 19:22 ` Drew Adams
2010-12-03 8:17 ` martin rudalics
2010-12-03 16:22 ` Drew Adams
2010-12-03 18:16 ` martin rudalics
2010-12-03 18:33 ` Drew Adams
2010-12-03 18:41 ` martin rudalics
2010-12-04 22:44 ` Chong Yidong
2010-12-16 18:27 ` Drew Adams
2010-12-17 6:32 ` martin rudalics
2010-12-17 15:32 ` Drew Adams
2010-12-17 16:12 ` martin rudalics
2010-12-17 16:55 ` Drew Adams
2010-12-17 18:09 ` martin rudalics
2010-12-17 18:40 ` Drew Adams
2010-12-21 6:48 ` Chong Yidong
2010-12-03 20:27 ` Stefan Monnier
2012-04-05 20:23 ` Drew Adams
2012-04-06 14:02 ` martin rudalics
2012-04-06 14:44 ` Drew Adams
2012-04-06 14:53 ` martin rudalics
2012-04-06 15:34 ` Drew Adams [this message]
2012-04-06 15:47 ` martin rudalics
2012-04-06 16:10 ` Drew Adams
2012-04-06 16:56 ` martin rudalics
2012-04-06 17:08 ` Drew Adams
2012-04-18 14:32 ` Drew Adams
2012-05-25 20:52 ` Drew Adams
2012-05-26 17:55 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' [PATCH] Drew Adams
2012-05-27 13:21 ` martin rudalics
2012-05-27 14:33 ` Drew Adams
2011-01-18 22:14 ` bug#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Drew Adams
2012-09-05 14:30 ` martin rudalics
2012-09-05 14:33 ` Drew Adams
2012-10-03 9:11 ` martin rudalics
2012-10-03 15:52 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7F573FD9970448A282AF763F35489AA3@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=7533@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).