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: Sun, 2 Oct 2011 08:35:00 -0700 Message-ID: <72F08D70CD7048C491DBB6CBE4C2A5DA@us.oracle.com> References: <87hb3thebv.fsf@escher.home> <4E86D879.7060105@gmx.at><87r52xkp0l.fsf@escher.home> <4E86F22B.5060007@gmx.at> <4E874831.3060709@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 1317569754 1210 80.91.229.12 (2 Oct 2011 15:35:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 Oct 2011 15:35:54 +0000 (UTC) Cc: 9639@debbugs.gnu.org, 'Stephen Berman' To: "'Stefan Monnier'" , "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 02 17:35:50 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 1RAO4z-0006J3-Lo for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Oct 2011 17:35:49 +0200 Original-Received: from localhost ([::1]:39129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAO4z-0002Se-6q for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Oct 2011 11:35:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAO4w-0002Rn-03 for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2011 11:35:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAO4u-0002eT-DZ for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2011 11:35:45 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAO4u-0002eP-Ab for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2011 11:35:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RAO69-00026S-QR for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2011 11:37:01 -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: Sun, 02 Oct 2011 15:37:01 +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.13175697848039 (code B ref 9639); Sun, 02 Oct 2011 15:37:01 +0000 Original-Received: (at 9639) by debbugs.gnu.org; 2 Oct 2011 15:36:24 +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 1RAO5X-00025b-Ok for submit@debbugs.gnu.org; Sun, 02 Oct 2011 11:36:24 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RAO5T-00025S-JC for 9639@debbugs.gnu.org; Sun, 02 Oct 2011 11:36:21 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p92FYwkf001702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Oct 2011 15:35:00 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p92FYuA7003596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Oct 2011 15:34:57 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p92FYo4p001909; Sun, 2 Oct 2011 10:34:51 -0500 Original-Received: from dradamslap1 (/10.159.59.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 02 Oct 2011 08:34:50 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: AcyAm7FQR18zDG0PRE24YPjO11RMsAAeRemw X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E8884A4.0132,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 02 Oct 2011 11:37:01 -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:52068 Archived-At: > This shared code can provide a hook to let the user choose > how the frame gets hidden, Why make users jump through hoops and hooks? Provide a user option. (And removing is not "hiding". And even hiding does not leave behind little icons.) > but the default should be to iconify since that's how it's > worked until now Oh, that's rich. If you resist bug reports long enough, sure, you can then claim that "that's how it's worked until now", and that's the reason it should continue to be the default ("since"). But no, that's not how it worked, even as recently as Emacs 22, IIRC. At least in Emacs 18,...21,22 quitting the debugger, say, does _not_ iconify a dedicated *Backtrace* frame - it simply _deletes_ it - behavior that makes sense. Seems to me this iconification is something that you introduced. Iconifying is hardly "how it worked" before that. emacs -Q ; Emacs 22 (setq special-display-regexps '("[ ]?[*][^*]+[*]")) M-: (/ 0) q ; in buffer *Backtrace*. Poof - the frame is _deleted_. So by your logic, "since" that's _not_ how it worked throughout Emacs's history until you introduced the iconification bug/feature, the traditional default behavior should be restored: delete the frame. > (and also because I think it's a safer default, in the > sense that iconifying throws away less information than deleting the > frame). You did add "in the sense that", but it's not about _safety_. Deleting a frame does not destroy any important information (buffer/file content etc.). And nothing prevents you from saving the frame position, shape, and size for your own use - e.g. in a register. Do that in a hook if you like. But the default behavior should simply do what a user expects: _remove_ the frame. That could be done by making it invisible or deleting it. Making it invisible would save all of your precious frame info, BTW. Invisibility, like deletion (and unlike iconification), is instantaneous and unclutters the display, and it would presumably be a reasonable compromise. In principle, it should address both your concerns and mine. Supposedly, there are some bugs associated with invisible frames, but it's not clear just what they are (?). Maybe it's time to find out (and fix them). In sum, invisibility would probably be an acceptable compromise default. Iconifying as default should be a non-starter - a bad idea. > the choice doesn't depend on the caller, AFAIK, but on the user. Which means it should be easily customizable by the user - a user option, not just hooks.