From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#9639: 24.0.90; Problem with bury-buffer in minibuffer-hide-completions Date: Sat, 1 Oct 2011 07:38:33 -0700 Message-ID: <944D5D429FE44884ABAFF93521DEBB73@us.oracle.com> References: <87hb3thebv.fsf@escher.home> <4E86D879.7060105@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1317479946 11929 80.91.229.12 (1 Oct 2011 14:39:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 1 Oct 2011 14:39:06 +0000 (UTC) Cc: 9639@debbugs.gnu.org To: "'martin rudalics'" , "'Stephen Berman'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 01 16:38:57 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RA0iP-0004uk-52 for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2011 16:38:57 +0200 Original-Received: from localhost ([::1]:41151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RA0iO-0003ft-Pd for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2011 10:38:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RA0iL-0003fb-01 for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2011 10:38:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RA0iJ-0005dq-TT for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2011 10:38:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RA0iJ-0005dm-Qc for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2011 10:38:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RA0jT-00080c-8V for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2011 10:40:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2011 14:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9639 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9639-submit@debbugs.gnu.org id=B9639.131747998830760 (code B ref 9639); Sat, 01 Oct 2011 14:40:02 +0000 Original-Received: (at 9639) by debbugs.gnu.org; 1 Oct 2011 14:39:48 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RA0jD-000805-7X for submit@debbugs.gnu.org; Sat, 01 Oct 2011 10:39:47 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RA0j9-0007zv-BT for 9639@debbugs.gnu.org; Sat, 01 Oct 2011 10:39:44 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p91EcR5x017464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Oct 2011 14:38:29 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p91EcRGs019681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Oct 2011 14:38:27 GMT Original-Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p91EcLJt011590; Sat, 1 Oct 2011 09:38:22 -0500 Original-Received: from dradamslap1 (/10.159.37.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 01 Oct 2011 07:38:21 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E86D879.7060105@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: AcyAGcjmkhXVNDRPQN2UmUCzqAC+vQAKg7Dw X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E8725E6.007A:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 01 Oct 2011 10:40:03 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:52044 Archived-At: > Presumably `minibuffer-hide-completions' should iconify a standalone > completions frame I have not been following this thread, but NO, it should *delete* a standalone completions frame, not iconify it. Better yet, the behavior should be customizable (delete, make invisible, iconify, put on a different tab,...), but the _default_ behavior should simply be to *delete* the frame. 1. The analogy to `delete-window' is `delete-frame', and that is just what the behavior here (at least the default behavior) should be: delete the frame. 2. There is no _need_ to iconify a frame that we no longer need (!). 3. Iconifying, at least on Windows, takes longer and distracts the user, sweeping an animation across the screen. 4. If someone binds the window-manager `iconify-frame' event to do something slightly different then things can be even worse: (define-key special-event-map [iconify-frame] 'foobar) 5. Iconifying puts icons (of one form or another) on the desktop. There is no general need for a *Completions* buffer icon. Occam's razor. Anyone really needing to access buffer *Completions* to see the candidate completions from the _last_ command can just use C-x C-b. 6. If *Completions* is always created as a standalone frame, then there is no need to save an icon for it. The buffer is one thing, the frame/icon is another. If you want the frame always created in the same position with the same size or something (the only argument Stefan has ever given for iconifying, AFAIK), then just _create_ it that way each time. 7. Just because Stefan's own use case prefers iconifying is _no reason_ to hard-code iconifying as the behavior. That's several reasons why iconifying is a bad idea. What's the argument _for_ iconifying? Only this: Stefan likes it. He likes it because it saves the frame position and size. That's the only reason that's ever been given, AFAIK. Position, shape, and size of a standalone frame can be handled at its creation, as is usual in Emacs. There is no need to create an icon just to save that info here.