all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.




  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.