From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer' Date: Thu, 26 Oct 2017 07:01:51 -0700 (PDT) Message-ID: References: <4d0c5535-246a-4356-914f-3c8d030ba9c9@default> <59F0412F.9090206@gmx.at> <22c73180-e9a6-416f-9e28-da98d07908f8@default> <59F1957F.80900@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="__1509026512751245940abhmp0002.oracle.com" X-Trace: blaine.gmane.org 1509026616 30283 195.159.176.226 (26 Oct 2017 14:03:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 26 Oct 2017 14:03:36 +0000 (UTC) To: martin rudalics , 28978@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 26 16:03:30 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7ikk-0006Ls-Qj for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Oct 2017 16:03:23 +0200 Original-Received: from localhost ([::1]:53106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7ikq-0002hP-HU for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Oct 2017 10:03:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7ikV-0002YV-7t for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2017 10:03:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7ikQ-0005Qy-Ph for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2017 10:03:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54727) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e7ikQ-0005QL-K7 for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2017 10:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e7ikQ-0001j1-44 for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2017 10:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2017 14:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28978 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28978-submit@debbugs.gnu.org id=B28978.15090265246565 (code B ref 28978); Thu, 26 Oct 2017 14:03:02 +0000 Original-Received: (at 28978) by debbugs.gnu.org; 26 Oct 2017 14:02:04 +0000 Original-Received: from localhost ([127.0.0.1]:35175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7ijU-0001hp-DU for submit@debbugs.gnu.org; Thu, 26 Oct 2017 10:02:04 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:22867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7ijR-0001hK-OD for 28978@debbugs.gnu.org; Thu, 26 Oct 2017 10:02:02 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9QE1snB017230 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Oct 2017 14:01:55 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9QE1rHp003635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Oct 2017 14:01:53 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9QE1qtZ013131; Thu, 26 Oct 2017 14:01:53 GMT In-Reply-To: <59F1957F.80900@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (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" Xref: news.gmane.org gmane.emacs.bugs:139006 Archived-At: --__1509026512751245940abhmp0002.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > > I don't call `make-frame' to create frame `*Completions*'. > > It is created when ` 1on1-display-*Completions*-frame' is > > called, and that is done by `special-display-function'. > > I showed the code for that in my previous message. >=20 > The 'minibuffer' parameter must be set up specially by whoever calls > =E2=80=98make-frame=E2=80=99. If this is not done, you can't change it a= fterwards. The > default value of =E2=80=98special-display-function=E2=80=99 is > =E2=80=98special-display-popup-frame=E2=80=99 and I don't see the latter = setting up the > 'minibuffer' parameter anywhere. I use the default value of `special-display-function', `special-display-popup-frame'. I don't call `make-frame' for `*Completions*'. I just provide an alist to `special-display-buffer-names'. That alist includes, as its second element, function `1on1-display-*Completions*-frame', which displays the frame. This is `special-display-buffer-names': (("*Completions*" 1on1-display-*Completions*-frame ((background-color . "LavenderBlush2") (mouse-color . "VioletRed") (cursor-color . "VioletRed") (menu-bar-lines . 0) (tool-bar-lines . 0) (width . 100))) ("*Help*" 1on1-display-*Help*-frame ((background-color . "Thistle") (mouse-color . "Blue Violet") (cursor-color . "Blue Violet") (height . 40)))) The only thing that matters there is `1on1-display-*Completions*-frame'. > > I don't ever set parameter `minibuffer' explicitly for > > *Completions*. I'm guessing that it has always gotten > > set automatically when frame input was redirected from > > frame *Completions* to the standalone minibuffer. > > > > (It is redirected to `completion-reference-buffer' if > > the minibuffer is not active (and if `c-r-b' is not > > frame *Completions*)). >=20 > Maybe you mean "focus redirection" here which is something > different from setting up the 'minibuffer' parameter. Yes, I mean input/focus redirection, with `redirect-frame-focus'. I'm guessing that redirecting focus is somehow behind the changed value of parameter `minibuffer' for frame `*Completions*'. The redirection of frame focus is the only connection I'm aware of between those two frames. I don't change parameter `minibuffer' for *Completions*, that I'm aware of. Frame *Completions* is created by the special-display code, just by my using `special-display-buffer-names'. I don't create it directly - I don't call `make-frame' for it. If it is now getting the wrong value of parameter `minibuffer' I don't see how it could be my code that is doing that. =20 > I understand that you want that parameter to have a non-nil value there. > So make sure that it is. For this you will have to debug your earlier > version to see how they set up the 'miniuffer' parameter and compare > them with the current version to see how it fails to do that. I have no idea what part of the special-display code might have managed parameter `minibuffer' before vs now, or whether that is done in Emacs C code or Emacs Lisp code. I don't know what has changed in the Emacs code. However, I realize now that I reported the exact opposite of the real problem. Apologies for that. The problem is NOT that (1) PREVIOUSLY, frame *Completions* had a `minibuffer' parameter whose value was the active minibuffer window (on the minibuffer frame) and (2) NOW, frame *Completions* has a nil `minibuffer' parameter. The problem is that (1) PREVIOUSLY, frame *Completions* had a nil `minibuffer' and (2) NOW, frame *Completions* has a `minibuffer' parameter whose value is the active minibuffer window (on the minibuffer frame). IOW, the problem is that the separate, dedicated frame *Completions* somehow gets a `minibuffer' parameter (whose value is the minibuffer window on the minibuffer frame). `*Completions*' is not a minibuffer frame. The only minibuffer frame has a `minibuffer' parameter whose value is `only' - the value is not a minibuffer _window_. Does the problem description make more sense now? Sorry for the confusion. I am not setting parameter `minibuffer'. The only connection I know of between the *Completions* frame and the standalone minibuffer frame is the focus redirection. Is it possible that that redirection code now mistakenly gives a non-nil `minibuffer' parameter to the frame whose input focus is redirected to the minibuffer frame? Attached is the debug output that I see, in case it helps. The cause of my problem seems to be that somehow frame `*Completions*' is getting a non-nil parameter `minibuffer' - the value being the minibuffer window (on the minibuffer frame). Or do you interpret the attached debug info differently? Hoping you can set me straight about this. I don't think I should need to do anything different in my code, but if I need to make some minor adjustment for some change in Emacs, please let me know what I'll need to do. So far, this seems like an Emacs bug, to me. --__1509026512751245940abhmp0002.oracle.com Content-Type: application/octet-stream; name="throw-bug-28978.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="throw-bug-28978.el" KGRlZnVuIGljaWNsZS1kZWxldGUtd2luZG93cy1vbiAoYnVmZmVyKQogICJEZWxldGUgYWxsIHdp bmRvd3Mgc2hvd2luZyBCVUZGRVIuCklmIHN1Y2ggYSB3aW5kb3cgaXMgYWxvbmUgaW4gaXRzIGZy YW1lLCB0aGVuIGRlbGV0ZSB0aGUgZnJhbWUgLSB1bmxlc3MKaXQgaXMgdGhlIG9ubHkgZnJhbWUg b3IgYSBzdGFuZGFsb25lIG1pbmlidWZmZXIgZnJhbWUuIgogIChpbnRlcmFjdGl2ZQogICAobGlz dCAobGV0ICgoZW5hYmxlLXJlY3Vyc2l2ZS1taW5pYnVmZmVycyAgdCkpCiAgICAgICAgICAgKHJl YWQtYnVmZmVyICJSZW1vdmUgYWxsIHdpbmRvd3Mgc2hvd2luZyBidWZmZXI6ICIgKGN1cnJlbnQt YnVmZmVyKSAnZXhpc3RpbmcpKSkpCiAgKHNldHEgYnVmZmVyICAoZ2V0LWJ1ZmZlciBidWZmZXIp KQogIChtZXNzYWdlICIxMTEsIEJVRjogJVMiIGJ1ZmZlcikKICAod2hlbiBidWZmZXIKICAgIDs7 IEF2b2lkIGVycm9yIG1lc3NhZ2UgIkF0dGVtcHQgdG8gZGVsZXRlIG1pbmlidWZmZXIgb3Igc29s ZSBvcmRpbmFyeSB3aW5kb3ciLgogICAgKG1lc3NhZ2UgIjIyMiwgdGhpcy1idWYtZnJzOiAlUywg dGhpcyBmcjogJVMiIChpY2ljbGUtZnJhbWVzLW9uIGJ1ZmZlcikgKGNhciAoaWNpY2xlLWZyYW1l cy1vbiBidWZmZXIpKSkKICAgIChsZXQqICgodGhpcy1idWZmZXItZnJhbWVzICAoaWNpY2xlLWZy YW1lcy1vbiBidWZmZXIpKQogICAgICAgICAgICh0aGlzLWZyYW1lICAgICAgICAgIChjYXIgdGhp cy1idWZmZXItZnJhbWVzKSkKICAgICAgICAgICBtaW5pLXBhcmFtKQogICAgICAobWVzc2FnZSAi MzMzLCBmci12aXNpYjogJVMsIG9ubHktMTogJVMsIG1pbmlwYXJhbTogJVMsIGVxOiAlUyIKICAg ICAgICAgICAgICAgKGZyYW1lLXZpc2libGUtcCB0aGlzLWZyYW1lKQogICAgICAgICAgICAgICAo bnVsbCAoY2RyIHRoaXMtYnVmZmVyLWZyYW1lcykpCiAgICAgICAgICAgICAgIChjZHIgKGFzc29j ICdtaW5pYnVmZmVyIChmcmFtZS1wYXJhbWV0ZXJzIHRoaXMtZnJhbWUpKSkKICAgICAgICAgICAg ICAgKGVxIChjZHIgKGFzc29jICdtaW5pYnVmZmVyIChmcmFtZS1wYXJhbWV0ZXJzIHRoaXMtZnJh bWUpKSkgKGFjdGl2ZS1taW5pYnVmZmVyLXdpbmRvdykpCiAgICAgICAgICAgICAgICkKICAgICAg KHVubGVzcyAoYW5kIHRoaXMtZnJhbWUKICAgICAgICAgICAgICAgICAgIChmcmFtZS12aXNpYmxl LXAgdGhpcy1mcmFtZSkKICAgICAgICAgICAgICAgICAgIChudWxsIChjZHIgdGhpcy1idWZmZXIt ZnJhbWVzKSkgOyBPbmx5IG9uZSBmcmFtZSBzaG93cyBCVUZGRVIuCiAgICAgICAgICAgICAgICAg ICAoc2V0cSBtaW5pLXBhcmFtIDsgPD09PT09PT09PT09PT09PT09PT09PT09PT09CiAgICAgICAg ICAgICAgICAgICAgICAgICAoY2RyIChhc3NvYyAnbWluaWJ1ZmZlciAoZnJhbWUtcGFyYW1ldGVy cyB0aGlzLWZyYW1lKSkpKQogICAgICAgICAgICAgICAgICAgKGVxIG1pbmktcGFyYW0gKGFjdGl2 ZS1taW5pYnVmZmVyLXdpbmRvdykpIDsgSGFzIGFuIGFjdGl2ZSBtaW5pYnVmZmVyLgogICAgICAg ICAgICAgICAgICAgKHNhdmUtd2luZG93LWV4Y3Vyc2lvbgogICAgICAgICAgICAgICAgICAgICAo c2VsZWN0LWZyYW1lIHRoaXMtZnJhbWUpCiAgICAgICAgICAgICAgICAgICAgIChvbmUtd2luZG93 LXAgdCAnU0VMRUNURUQtRlJBTUUtT05MWSkpKSA7IE9ubHkgb25lIHdpbmRvdy4KICAgICAgICAo bWVzc2FnZSAiNDQ0LCBtdXN0IGJlIG9uZSB3aW4iKQogICAgICAgIChsZXQgKHdpbikKICAgICAg ICAgIChkb2xpc3QgKGZyICB0aGlzLWJ1ZmZlci1mcmFtZXMpCiAgICAgICAgICAgIChzZXRxIHdp biAgKGdldC1idWZmZXItd2luZG93IGJ1ZmZlciBmcikpCiAgICAgICAgICAgIChzZWxlY3Qtd2lu ZG93IHdpbikKICAgICAgICAgICAgKG1lc3NhZ2UgIjU1NSwgb25lLXdpbjogJVMsIG5vdC0xLWZy OiAlUyIgKG9uZS13aW5kb3ctcCB0KSAoY2RyICh2aXNpYmxlLWZyYW1lLWxpc3QpKSkKICAgICAg ICAgICAgKGlmIChhbmQgKG9uZS13aW5kb3ctcCB0KSAgKGNkciAodmlzaWJsZS1mcmFtZS1saXN0 KSkpIDsgU29sZSB3aW5kb3cgYnV0IG5vdCBzb2xlIGZyYW1lLgogICAgICAgICAgICAgICAgKGRl bGV0ZS1mcmFtZSkKICAgICAgICAgICAgICAoZGVsZXRlLXdpbmRvdyAoc2VsZWN0ZWQtd2luZG93 KSkpKSkpKSkpCgpJbiBFbWFjcyAyNC41IEkgc2VlIHRoaXMgZGVidWcgb3V0cHV0OgoKMTExLCBC VUY6ICM8YnVmZmVyICpDb21wbGV0aW9ucyo+CjIyMiwgdGhpcy1idWYtZnJzOiAoIzxmcmFtZSAq Q29tcGxldGlvbnMqIDA1MmQzNzc4PiksIHRoaXMgZnI6ICM8ZnJhbWUgKkNvbXBsZXRpb25zKiAw NTJkMzc3OD4KMzMzLCBmci12aXNpYjogdCwgb25seS0xOiB0LCBtaW5pcGFyYW06IG5pbCwgZXE6 IG5pbAo0NDQsIG11c3QgYmUgb25lIHdpbgo1NTUsIG9uZS13aW46IHQsIG5vdC0xLWZyOiAoIzxm cmFtZSBkcmV3cy1saXNwLTIwIDAxNGIzNDIwPiAjPGZyYW1lICpzY3JhdGNoKiAwNDdiNjM2MD4g IzxmcmFtZSAqTWVzc2FnZXMqIDAxNWM4NTg4PiAjPGZyYW1lICpDb21wbGV0aW9ucyogMDUyZDM3 Nzg+KQoKQnV0IGluIEVtYWNzIDI2IHByZXRlc3QgMSBJIHNlZSB0aGlzIG91dHB1dDoKCjExMSwg QlVGOiAjPGJ1ZmZlciAqQ29tcGxldGlvbnMqPgoyMjIsIHRoaXMtYnVmLWZyczogKCM8ZnJhbWUg KkNvbXBsZXRpb25zKiAwMDAwMDAwMDBjYWNmNmM4PiksIHRoaXMgZnI6ICM8ZnJhbWUgKkNvbXBs ZXRpb25zKiAwMDAwMDAwMDBjYWNmNmM4PgozMzMsIGZyLXZpc2liOiB0LCBvbmx5LTE6IHQsIG1p bmlwYXJhbTogIzx3aW5kb3cgNiBvbiAgKk1pbmlidWYtMSo+LCBlcTogdAo= --__1509026512751245940abhmp0002.oracle.com--