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 11:14:47 -0800 (PST) Message-ID: 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> <85c8c268-b3dc-42ff-8bc5-bb1e5786ecb2@default> <56802FEA.9080103@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 1451243725 4226 80.91.229.3 (27 Dec 2015 19:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Dec 2015 19:15:25 +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 20:15:11 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 1aDGmb-0000fa-J9 for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Dec 2015 20:15:09 +0100 Original-Received: from localhost ([::1]:42493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDGma-0003fr-Re for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Dec 2015 14:15:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDGmV-0003eF-TE for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 14:15:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDGmU-0004FK-FF for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 14:15:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDGmU-0004FG-BV for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 14:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aDGmU-0006FD-8L for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2015 14:15: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 19:15: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.145124369923970 (code B ref 10873); Sun, 27 Dec 2015 19:15:02 +0000 Original-Received: (at 10873) by debbugs.gnu.org; 27 Dec 2015 19:14:59 +0000 Original-Received: from localhost ([127.0.0.1]:44764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDGmQ-0006EX-P3 for submit@debbugs.gnu.org; Sun, 27 Dec 2015 14:14:59 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:36008) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDGmO-0006EE-Mw for 10873@debbugs.gnu.org; Sun, 27 Dec 2015 14:14:57 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBRJEna8009080 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 19:14:50 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBRJEnCC008826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 19:14:49 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBRJEmjL025428; Sun, 27 Dec 2015 19:14:49 GMT In-Reply-To: <56802FEA.9080103@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: aserv0022.oracle.com [141.146.126.234] 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:110829 Archived-At: > >> > *Completions* is not a modal window. > >> > >> I don't mind to disagree here. > > > > Not sure it is important to discuss this, but what is your > > disagreement? >=20 > I consider the window showing *Completions* modal. That's clear. But what is your reason (evidence) for saying that. > >> 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. >=20 > It is modal. How so? In what way? IOW, why do you think so? > But since Emacs is always nice to its users it has its own > interpretation of modality. It shows modal windows where the user wants > them and allows the user to do virtually anything while they are shown. Then in what way are they modal? It sounds like you have an original meaning of modal in mind. What is it? > There's one restriction: Emacs expects the user to be nice to it as > well. >=20 > Emacs also has shy windows like the one from Ispell. These go away when > the user doesn't pay attention to them. Modal windows are a bit more > insistent. But as I mentioned earlier their only rules are: A modal > window should disappear immediately when it's no more needed but till > then it should remain continuously visible. Ah, so that's what you mean by "modal window". Not that a user is prevented from doing something else than interact with it, but that (a) it remains visible until (b) it is no longer needed, when it disappears. That is not the usual meaning of "modal", but OK, good to know. I imagine that (a) is unnecessary, unless you are suggesting that a user cannot remove such a window. I'm guessing that you perhaps mean, by (a), that no other automatically displayed window takes its place, and that it is not otherwise removed automatically. > And finally we have what you probably would consider modal: Dialogs like > that of Emacs asking you whether it should save a buffer when exiting. > There you won't be able to send a bug report until you have either quit > or given an appropriate answer. >=20 > > I argue only that (1) the bug-reporting window(s) should be visible >=20 > They usually are except for a few cases involving dedicated windows and > unsplittable frames. OK, so only those cases should manifest the bug. > > 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. >=20 > All this is coded in Elisp. Why don't you give it a try? Sorry; I am not trying to fix the bug, myself. And if I did, I'm sure that you or someone else would reject the result of my effort. I am only trying to help by explaining the bug report, and the bug as I see it. HTH.