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 08:51:21 -0800 (PST) Message-ID: <0286fb63-edbc-448f-ae07-738ed5ef8f78@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> 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 1451235150 12513 80.91.229.3 (27 Dec 2015 16:52:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Dec 2015 16:52:30 +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 17:52:14 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 1aDEYH-0002rg-AV for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Dec 2015 17:52:13 +0100 Original-Received: from localhost ([::1]:42089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDEYG-0000nx-MW for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Dec 2015 11:52:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDEYB-0000nJ-Ow for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 11:52:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDEY6-00005X-OU for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 11:52:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDEY6-00005T-Kk for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 11:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aDEY6-0007qm-Cl for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 11:52: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 16:52: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.145123509230118 (code B ref 10873); Sun, 27 Dec 2015 16:52:02 +0000 Original-Received: (at 10873) by debbugs.gnu.org; 27 Dec 2015 16:51:32 +0000 Original-Received: from localhost ([127.0.0.1]:44593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDEXb-0007pi-TR for submit@debbugs.gnu.org; Sun, 27 Dec 2015 11:51:32 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:17612) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDEXZ-0007pT-QW for 10873@debbugs.gnu.org; Sun, 27 Dec 2015 11:51:30 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBRGpNxM007636 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 16:51:23 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBRGpNgJ010486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 16:51:23 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tBRGpM1g003288; Sun, 27 Dec 2015 16:51:22 GMT In-Reply-To: <56800C2E.80300@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: userv0022.oracle.com [156.151.31.74] 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:110796 Archived-At: > >> This bug is still 100% reproducible in an Emacs 25 build of 2015-12-1= 0: >=20 > There's not much I can do about this. I can give a simpler recipe with > emacs -Q: Type C-h f set- RET and see the *Completions* window pop up. > Then type M-x report-emacs-bug. >=20 > OT1H the window showing the *Completions* buffer is softly dedicated to > that buffer. This is necessary to make sure that an intermittent > =E2=80=98display-buffer=E2=80=99 does not steal that window for showing a= nother buffer. > Windows showing *Completions* should disappear immediately when they are > no more needed but till then they should be continuously visible. >=20 > OTOH =E2=80=98report-emacs-bug=E2=80=99 apparently assumes that it always= has two > windows at its disposal - one for the message and one for help. This > assumption misfires with the recipe at hand. (Note that my machine in > addition also displays a warning from =E2=80=98compose-mail=E2=80=99 whic= h gets usually > immediately buried when showing either the message or the help.) >=20 > IMO this report is the result of a cockpit error. As long as a "modal" > window like that showing *Completions* is open, users should not start > an unrelated activity, including that of writing a bug report. >=20 > If, however, people think that =E2=80=98report-emacs-bug=E2=80=99 should = always succeed > showing both of its windows in every conceivable context, we can do that > easily by calling =E2=80=98delete-other-windows=E2=80=99 before =E2=80=98= display-buffer=E2=80=99. This > will clearly misfire for people showing more than two windows per frame. Wrt: > IMO this report is the result of a cockpit error. As long as a "modal" > window like that showing *Completions* is open, users should not start > an unrelated activity, including that of writing a bug report. The bug report shows a simple recipe; it does not purport to show a realistic use case. *Completions* is not a modal window. 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. 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. 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, and it should not prevent a user from interacting with Emacs in other ways while the report is being prepared. Nor should it assume that the user will not continue to interact with Emacs in other ways before the report is finished and sent. Use of the minibuffer should not be proscribed or curtailed just because bug reporting wants to display some other windows. And use of other, non-bug reporting, windows should not be foregone just because bug reporting wants to display some additional windows. What should happen is that the bug-reporting windows should both be visible. Or at the very least, the most important, not the least important, of these two windows should be visible. And as the original bug report said: This is a regression starting with Emacs 23. Since it is a regression it should not be impossible or unfeasible to obtain the pre-regression behavior again.