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#7533: 24.0.50; `dired-mark-pop-up': delete frame afterwards if `pop-up-frames' Date: Fri, 3 Dec 2010 08:22:51 -0800 Message-ID: <1880532436F6447B97DC61F6050FF29F@us.oracle.com> References: <90E09641E9264B37932D2315E5E7E2EA@us.oracle.com> <4CF7EDED.5090500@gmx.at> <44FB8E26FD824BB18AE8A367F560C091@us.oracle.com> <4CF8A7B2.5080306@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 1291394734 24134 80.91.229.12 (3 Dec 2010 16:45:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Dec 2010 16:45:34 +0000 (UTC) Cc: 7533@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 03 17:45:30 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1POYlF-0005FN-KD for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Dec 2010 17:45:29 +0100 Original-Received: from localhost ([127.0.0.1]:60137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POYl6-0007Ak-3o for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Dec 2010 11:45:20 -0500 Original-Received: from [140.186.70.92] (port=40090 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POYl1-000791-0R for bug-gnu-emacs@gnu.org; Fri, 03 Dec 2010 11:45:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POYky-0004hq-2q for bug-gnu-emacs@gnu.org; Fri, 03 Dec 2010 11:45:14 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1POYky-0004hg-1G for bug-gnu-emacs@gnu.org; Fri, 03 Dec 2010 11:45:12 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1POYKg-0003dk-DD; Fri, 03 Dec 2010 11:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Dec 2010 16:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7533 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7533-submit@debbugs.gnu.org id=B7533.129139303813942 (code B ref 7533); Fri, 03 Dec 2010 16:18:02 +0000 Original-Received: (at 7533) by debbugs.gnu.org; 3 Dec 2010 16:17:18 +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 1POYJx-0003co-KB for submit@debbugs.gnu.org; Fri, 03 Dec 2010 11:17:18 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1POYJu-0003cZ-Ao for 7533@debbugs.gnu.org; Fri, 03 Dec 2010 11:17:15 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB3GMvVd029214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Dec 2010 16:22:58 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB36otkF025383; Fri, 3 Dec 2010 16:22:56 GMT Original-Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 841948351291393373; Fri, 03 Dec 2010 08:22:53 -0800 Original-Received: from dradamslap1 (/10.159.244.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Dec 2010 08:22:52 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcuSwpfmCfbU1kWsRN2WxvFkVRkclwAQFafQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <4CF8A7B2.5080306@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 03 Dec 2010 11:18:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:42108 Archived-At: > > But what's the right test? It is _not_ `pop-up-frames' non-nil, > > because users can do other things than that to cause a new > > frame to be created for this dialog. What's needed is a test of > > whether a frame was newly created for this dialog buffer. > > What's the code for that test? > > In the past, routines usually tested the settings of variables like > `pop-up-windows' or `pop-up-frames' to guess the expected behavior of > `display-buffer'. In most cases the guesses were correct. In a few > corner cases they failed and the example you cite above is > one of them. What do you mean by "in the past"? In the past I saw no such problem as that reported in this bug. (On the contrary - this annoyance was introduced in Emacs 23 - see below.) > Here I have two things: A window parameter that tells for each window > whether the current buffer is the first buffer shown in it and a > separate global variable which gives some rudimentary > information about what the last `display-buffer' invocation did to find a > suitable window. The former exists independently of `display-buffer' so it > also works for a "manually" constructed or reused window or frame. The latter is > `display-buffer' specific and is mainly used for providing some feedback > about the change of the entire window configuration. Please be specific. What window parameter? What global variable? Just what are you trying to say? I can't even tell whether you're saying that you _have_ a solution or there _is no_ solution. I repeat: "what's the right test?" What's the solution? > > The bug report is about the annoyance of not deleting a > > new frame that was created (using whatever mechanism, including non-nil > > `pop-up-frames') for dialog purposes. When the dialog is finished, > > such a new frame should disappear. Users should not need to > > manually delete it. > > There's no formal definition of "dialog purpose" in Emacs and it's not > easy to do that in general. No one's asking for a "formal definition" of anything. The *Deletions* (or whatever) window that lists the files that will be acted on if you type `yes' is supplementary help for answering the prompt - nothing more. Its only reason for being displayed ends as soon as you've answered the prompt. I call that a dialog: ask a question and pop up some help for understanding the question, then remove the displayed help when the question is answered. You can call it anything you want. No "formal definition" is needed here, AFAICS. If for some reason we cannot fix this, with all of the fancy artillary we have in Emacs 24, then please at least regress to the sane behavior of older releases. Until Emacs 23, the help buffer here (e.g. *Marked Files*, *Deletions*, whatever) was always popped up as a window, not as a frame, even if you had non-nil `pop-up-frames'. And that window was (naturally) deleted when you type yes/no. That behavior was fine (IMO). We've "progressed" to a PITA (introduced in 23). If you can obtain similar behavior for a popup frame, fine. If not, then please restore the pre-23.2 design for such dialogs. > The major problem to address is whether and > how such a dialog can be disrupted by other activities and > how to resume it at a later time. If it's a major problem and you will end up complicating things further in order to solve it, then I vote for a return to the simple behavior of the past. That at least was not annoying and did not force users to manually close frames. Thx.