From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 'Tassilo Horn' <tassilo@member.fsf.org>, emacs-devel@gnu.org
Subject: RE: Usage examples of dedicated windows and popup frames?
Date: Fri, 8 Jul 2011 10:38:14 -0700 [thread overview]
Message-ID: <198B70C8FDE848DD848627322A55D774@us.oracle.com> (raw)
In-Reply-To: <jwvaacoson0.fsf-monnier+emacs@gnu.org>
> >> "They" should be iconified automatically and only one
> >> frame should be (re-)used for *Completions*.
>
> > What happens to the frame should be under _user_ control.
> > At least it should be possible to choose frame deletion
> > rather than iconification.
>
> I know, Drew. You've made your point obnoxiously clear
> several times already. ... your rant.
Huh? What rant? What's obnoxious about explaining the situation on Windows?
You and I have discussed automatic frame iconifying in the context of Emacs bug
reports involving `bury-buffer', but AFAIK automatic frame iconifying has never
come up on emacs-devel (even in the context of `bury-buffer').
And although you have argued (in bug threads) that `bury-buffer' should iconify
the frame, this is the first time (AFAIK) that you have stated that a
*Completions* frame "should be iconified". A fortiori, it is the first time I
have responded to such a proposal - anywhere, obnoxiously or otherwise.
Besides, AFAIK, nowhere (neither here nor in a bug thread) have I mentioned
before the second annoyance from iconifying: that of adding to the Emacs
list/menu in the Windows task bar. Until now, IIRC, I have mentioned (to you,
not emacs-devel) only the annoyance of the Windows iconifying animation, not the
task-bar list/menu annoyance.
> But here, I'm talking about "the current intended default
> behavior"
I see. I didn't know that was the current intended behavior for *Completions*
with non-nil `pop-up-frames' (having never seen it in any Emacs version), and I
didn't realize that's all you were saying.
I thought you were saying that this is what you think _should_ happen in the
future - a proposal as the proper fix for the problem Tassilo reported, and not
just a description of the currently intended behavior. Ambiguity of English
"should".
When you argued that `bury-buffer' "should" hard-code iconify a dedicated frame
you did mean more than just "that's what the current design is" - you argued in
favor of that approach. I thought that's what you were doing here too:
proposing iconifying as the solution to the *Completions* frame problem.
next prev parent reply other threads:[~2011-07-08 17:38 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 14:19 Usage examples of dedicated windows and popup frames? Tassilo Horn
2011-07-08 14:47 ` Richard Riley
2011-07-08 14:49 ` John Yates
2011-07-08 16:11 ` Stefan Monnier
2011-07-08 16:34 ` Drew Adams
2011-07-08 16:51 ` Stefan Monnier
2011-07-08 17:38 ` Drew Adams [this message]
2011-07-08 17:54 ` Tassilo Horn
2011-07-08 18:55 ` Stefan Monnier
2011-07-09 13:00 ` martin rudalics
2011-07-09 15:03 ` Drew Adams
2011-07-10 0:43 ` chad
2011-07-10 9:00 ` martin rudalics
2011-07-10 9:43 ` Drew Adams
2011-07-12 17:47 ` chad
2011-07-12 18:55 ` Drew Adams
2011-07-13 6:24 ` martin rudalics
2011-07-13 23:09 ` chad
2011-07-10 23:45 ` undisplay temporary dialog buffers when done [was: ... dedicated windows and popup frames] Drew Adams
2011-07-09 17:22 ` Usage examples of dedicated windows and popup frames? Tassilo Horn
2011-07-10 9:00 ` martin rudalics
2011-07-10 9:39 ` Tassilo Horn
2011-07-10 15:30 ` martin rudalics
2011-07-10 16:00 ` Tassilo Horn
2011-07-10 21:13 ` Drew Adams
2011-07-08 16:11 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=198B70C8FDE848DD848627322A55D774@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=tassilo@member.fsf.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.