emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Usage examples of dedicated windows and popup frames?


From: Drew Adams
Subject: RE: Usage examples of dedicated windows and popup frames?
Date: Fri, 8 Jul 2011 10:38:14 -0700

> >> "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 via email to

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