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#10873: 24.0.93; `report-emacs-bug' obscures bug-reporting buffer (!) Date: Sun, 27 Dec 2015 10:00:51 -0800 (PST) Message-ID: <85c8c268-b3dc-42ff-8bc5-bb1e5786ecb2@default> References: <1716A09ADF16453DAA29A726CB402BA5@us.oracle.com> <87sirsc1lg.fsf@building.gnus.org> <281e9d1f-0853-4498-bd4f-7510213c0cab@default> <43f2b0b2-fafc-43a9-b56a-120b90878cbc@default> <838u4hk0um.fsf@gnu.org> <56800C2E.80300@gmx.at> <0286fb63-edbc-448f-ae07-738ed5ef8f78@default> <56801A8C.2080605@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1451239291 7582 80.91.229.3 (27 Dec 2015 18:01:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Dec 2015 18:01:31 +0000 (UTC) Cc: 10873@debbugs.gnu.org, larsi@gnus.org To: martin rudalics , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 27 19:01:18 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aDFd5-0007Ez-8w for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Dec 2015 19:01:15 +0100 Original-Received: from localhost ([::1]:42328 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDFd4-0006ia-Og for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Dec 2015 13:01:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDFcx-0006eH-O3 for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 13:01:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDFcs-0005mt-Jb for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 13:01:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDFcs-0005mf-D6 for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 13:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aDFcs-0002mG-7T for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 13:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Dec 2015 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10873 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10873-submit@debbugs.gnu.org id=B10873.145123926010655 (code B ref 10873); Sun, 27 Dec 2015 18:01:02 +0000 Original-Received: (at 10873) by debbugs.gnu.org; 27 Dec 2015 18:01:00 +0000 Original-Received: from localhost ([127.0.0.1]:44674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDFcq-0002lm-B4 for submit@debbugs.gnu.org; Sun, 27 Dec 2015 13:01:00 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28943) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDFcp-0002lN-M3 for 10873@debbugs.gnu.org; Sun, 27 Dec 2015 13:00:59 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBRI0r1a029170 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 18:00:54 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tBRI0r1L031225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 18:00:53 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tBRI0qPs022227; Sun, 27 Dec 2015 18:00:53 GMT In-Reply-To: <56801A8C.2080605@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:110811 Archived-At: > > *Completions* is not a modal window. >=20 > I don't mind to disagree here. Not sure it is important to discuss this, but what is your disagreement? > > And it is not the case that > > users cannot or should not start another activity (related or > > unrelated) while the minibuffer is active or *Completions* is shown. >=20 > Agreed. That's precisely why the *Completions* window is dedicated. >=20 > > Certainly users should not be proscribed from having a completion > > in progress while they file a bug report. Think, for instance, of > > `enable-recursive-minibuffers'. Or think of keys that invoke > > commands from the minibuffer - commands that might do nearly > > anything. Or think of wanting to refer to the *Completions* > > buffer while filling out a bug report. >=20 > Agreed, again. >=20 > > The bug-reporting code should not make any special assumptions > > about other user activity that might be in progress or done "in > > parallel". It should not assume that either it or some other > > activity is modal. A truly modal activity will in any case do > > its best to prevent anything else from interfering. > > > > Certainly preparing a bug report is NOT a modal activity, >=20 > The modal activity in the case at hand is picking up a completion. That's not modal, if by that you mean that you cannot (or even that you should not) do anything else until you choose a completion candidate. You can do all kinds of things while the minibuffer is waiting for you to choose a candidate. There is nothing modal about this. > > Since it is a regression it should not be impossible or unfeasible > > to obtain the pre-regression behavior again. >=20 > Easy. Find someone who makes the *Completions* window non-dedicated > again. My interest in this bug is exhausted already. I don't argue that the implementation should return to what it was before Emacs 23. Nor do I argue that the *Completions* window should not be dedicated. I argue only that (1) the bug-reporting window(s) should be visible and (2) other windows should not be removed. A start might be to combine the instructions/help window with the reporting window. The reporting window already has lots of instructional text in it. Using a separate page in that window for the help info would go a long way toward stopping the reporting window from being occluded. It might even help if the order of creation of the two bug windows were reversed (dunno). What happens now is that the more important of the two windows is hidden and the less important of the two is shown - just the help. That's not ideal.