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: Mon, 28 Dec 2015 02:44:56 -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> <56810A01.3060609@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 1451299584 11744 80.91.229.3 (28 Dec 2015 10:46:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Dec 2015 10:46:24 +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 Mon Dec 28 11:46: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 1aDVJa-0000i7-5e for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Dec 2015 11:46:10 +0100 Original-Received: from localhost ([::1]:44151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDVJZ-0008IX-Cq for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Dec 2015 05:46:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDVJV-0008IS-PH for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2015 05:46:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDVJS-00030r-Fu for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2015 05:46:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDVJS-00030m-CD for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2015 05:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aDVJR-00010d-Sk for bug-gnu-emacs@gnu.org; Mon, 28 Dec 2015 05:46:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Dec 2015 10:46:01 +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.14512995093811 (code B ref 10873); Mon, 28 Dec 2015 10:46:01 +0000 Original-Received: (at 10873) by debbugs.gnu.org; 28 Dec 2015 10:45:09 +0000 Original-Received: from localhost ([127.0.0.1]:45343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDVIb-0000zP-5r for submit@debbugs.gnu.org; Mon, 28 Dec 2015 05:45:09 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:22545) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aDVIZ-0000zB-Kz for 10873@debbugs.gnu.org; Mon, 28 Dec 2015 05:45:08 -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 tBSAixvD009028 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Dec 2015 10:44:59 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBSAiwYQ007628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Dec 2015 10:44:58 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBSAiwTO011056; Mon, 28 Dec 2015 10:44:58 GMT In-Reply-To: <56810A01.3060609@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:110891 Archived-At: > >> I consider the window showing *Completions* modal. > > > > That's clear. But what is your reason (evidence) for saying > > that. >=20 > That if you don't consider the window modal you will run into all sorts > of problems like the one that is the subject of this thread. I'll give > you a more realistic scenario. Assume that you have a directory ~/foo/ > with two files say foo1 and foo2 and a directory ~/bar/ with two files > say bar1 and bar2. Now do >=20 > emacs -Q > M-x customize-option RET abbrev-file-name RET > Put ~/foo/ into the editable field, point at its end and do > M-x widget-complete RET > Now do > C-x 5 2 > M-x customize-option RET custom-file RET > Select "File", put ~/bar/ into the editable field, point at its end and > do > M-x widget-complete RET > again. Note that at this moment you have changed the contents of the > *Completions* windows in _both_ frames. If you now return to the first > frame and select a completion like bar1, nothing will happen (in the > best case). You already made clear, further down in your previous mail, what you mean by "modal". And I already said OK, I understand now what you mean by "modal", even if that is not what is usually mean by a modal dialog/UI. In a (truly) modal UI you would not be able to move from one to the other like that. That was my point: *Completions* is not modal (in the usual sense). In fact, in Emacs there are very few dialogs that are modal. `yes-or-no-p', `y-or-n-p', and maybe query-replace are about the only things that come to mind. > This is the same cockpit error as the one from your scenario: > *Completions* windows are modal and should be treated accordingly, > that is, nicely. "Modal" in your special sense of "(a) *Completions* remains visible until (b) it is no longer needed, when it disappears." And yes, we agree that a user can mess up if s?he fools around. That comes, BTW, precisely from the fact that these dialogs are _not_ modal (in the usual sense). Because they are not modal, you can mix them up - neither insists on all your attention until it is done. > > Ah, so that's what you mean by "modal window". Not that a user > > is prevented from doing something else than interact with it, >=20 > A user is allowed to do something else as long as she behaves nicely. > That's the price she has to pay for not being "prevented from doing > something else than interact with it". The user in the scenario > above does not behave nicely Agreed. I would put it differently (Emacs gives you enough rope to hang yourself), but yes, if you want to put it that way. > and neither do you when you want to report a bug while the > *Completions* windows is shown. Nope. I disagree completely. There is nothing wrong with doing what I described. I even gave a couple related use cases. It is always possible with Emacs to mess yourself up by doing something stupid. That doesn't mean that leaving *Completions* open while filing a bug report is stupid. In your scenario above the mess came from trying to reuse *Completions* and expecting no crosstalk. And even in the scenario above, BTW, it is possible to accomplish what the user tried sanely, using a recursive minibuffer. Start one completion; recursive minibuffer for another completion; finish that; resume the first completion. No big deal. > Such users are punished. Oh c'mon, Martin. This is a bug, not punishment for being a bad user and not treating Emacs nicely. > > 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. >=20 > All assumptions are off when you violate (a) or (b). And? Did you mean, by (a), only that the window is not removed automatically? Or did you mean that a user cannot remove it? If the former (which is what I hope you meant), it's up to Emacs not to violate (a) (i.e., not to remove it automatically until (b)). And I think it must be the former, because I don't see that Emacs prevents the user from removing the window. And if the user removes the window then presumbably it is no longer needed. Or maybe you mean that the user removes it accidentally? Even then, I don't see the problem. If there were a real problem with removing the window then Emacs should not let the user remove it. And I don't even understand what it means (for Emacs or for the user) to violate (b). This is all a bit too vague and hypothetical for me, I'm afraid. I don't have the impression I'm being much help now, as I can't really follow your point.