From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 13 14:06:12 2012 Received: (at submit) by debbugs.gnu.org; 13 Jul 2012 18:06:12 +0000 Received: from localhost ([127.0.0.1]:39711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SpkFn-0007IC-6M for submit@debbugs.gnu.org; Fri, 13 Jul 2012 14:06:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49081) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SpkFh-0007Hx-E2 for submit@debbugs.gnu.org; Fri, 13 Jul 2012 14:06:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpkAA-00030R-7W for submit@debbugs.gnu.org; Fri, 13 Jul 2012 14:00:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:43419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpkAA-00030N-4l for submit@debbugs.gnu.org; Fri, 13 Jul 2012 14:00:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpkA5-0003ZG-AJ for bug-gnu-emacs@gnu.org; Fri, 13 Jul 2012 14:00:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpkA4-0002zv-2L for bug-gnu-emacs@gnu.org; Fri, 13 Jul 2012 14:00:17 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:32003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpkA3-0002zp-Rl for bug-gnu-emacs@gnu.org; Fri, 13 Jul 2012 14:00:15 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6DI0Evm031783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Jul 2012 18:00:14 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6DI0DNx005086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jul 2012 18:00:13 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6DI0CSd031950 for ; Fri, 13 Jul 2012 13:00:12 -0500 Received: from dradamslap1 (/10.159.222.206) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jul 2012 11:00:12 -0700 From: "Drew Adams" To: Subject: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Fri, 13 Jul 2012 11:00:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1hIVbwuf9cwOvhQ7CsAOX1WrOvVw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) This is part of the ongoing saga of trying to get Emacs to DTRT with buffers popped up only to serve as info while Emacs asks a question requiring a response. IF you use a standalone minibuffer frame, AND the popped up buffer is special-display (e.g. because of `special-display-regexps'), AND you are on MS Windows (which automatically shifts the focus to a new frame that it creates), THEN: 1. When you try to exit Emacs with active processes, Emacs pops up a new frame for buffer `*Process List*' and asks you about killing them. 2. But the minibuffer frame no longer has the focus! So when you type your answer (e.g. "yes") Emacs tries to insert it as text in buffer `*Process List*'. Poor Emacs. Please do something to fix this. For inspiration, perhaps look to `dired-mark-pop-up' which does something similar but gets it right. See perhaps `dired-pop-to-buffer'. Better would be to fix this ask-for-input-after-popping-up-some-info problem generally, obviously. But a fix for just this particular query will be better than nothing. At least Dired DTRT now wrt focus - that's already something. Of course, for Dired I still have to modify `dired-mark-pop-up' anyway, to have it delete the window or frame popped up, afterward, and bury its buffer. See bug #7533 - a patch was provided for this but AFAIK Emacs Dev has never applied it. In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600) of 2012-06-10 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include' From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 14 09:32:25 2012 Received: (at 11939) by debbugs.gnu.org; 14 Jul 2012 13:32:25 +0000 Received: from localhost ([127.0.0.1]:40438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sq2SO-0007zq-Do for submit@debbugs.gnu.org; Sat, 14 Jul 2012 09:32:25 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:59094) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sq2SK-0007zg-MS for 11939@debbugs.gnu.org; Sat, 14 Jul 2012 09:32:22 -0400 Received: (qmail invoked by alias); 14 Jul 2012 13:26:34 -0000 Received: from 62-47-47-202.adsl.highway.telekom.at (EHLO [62.47.47.202]) [62.47.47.202] by mail.gmx.net (mp017) with SMTP; 14 Jul 2012 15:26:34 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19GJ+UIcTBGszGm2MLzcpTQAUdYTL21bmmm966/kr 3w58CdD5QrAlBP Message-ID: <500173A5.3040608@gmx.at> Date: Sat, 14 Jul 2012 15:27:01 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070601080905090706060001" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------070601080905090706060001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > IF you use a standalone minibuffer frame, AND the popped up buffer is > special-display (e.g. because of `special-display-regexps'), AND you are > on MS Windows (which automatically shifts the focus to a new frame that > it creates), THEN: > > 1. When you try to exit Emacs with active processes, Emacs pops up a new > frame for buffer `*Process List*' and asks you about killing them. > > 2. But the minibuffer frame no longer has the focus! So when you type > your answer (e.g. "yes") Emacs tries to insert it as text in buffer > `*Process List*'. Poor Emacs. What is your value of `minibuffer-auto-raise'? Maybe `yes-or-no-p' should do `select-frame-set-input-focus' in your case. What happens usually when you ask a `yes-or-no-p' question in a non-minibuffer frame? > Please do something to fix this. I'm afraid, most people here can't reproduce your problem. We probably have to invent some new option to handle it. In any case, we'd have to investigate the underlying problem. > For inspiration, perhaps look to > `dired-mark-pop-up' which does something similar but gets it right. See > perhaps `dired-pop-to-buffer'. > > Better would be to fix this ask-for-input-after-popping-up-some-info > problem generally, obviously. But a fix for just this particular > query will be better than nothing. > > At least Dired DTRT now wrt focus - that's already something. > > Of course, for Dired I still have to modify `dired-mark-pop-up' anyway, to have > it delete the window or frame popped up, afterward, and bury its buffer. See > bug #7533 - a patch was provided for this but AFAIK Emacs Dev has never applied > it. Try to load the attached file and tell me which problems you see. Thanks, martin --------------070601080905090706060001 Content-Type: application/emacs-lisp; name="with-temp-buffer-window.el" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="with-temp-buffer-window.el" Ozs7IEF1dG9tYXRpYyByZXNpemluZyBvZiB0ZW1wb3JhcnkgYnVmZmVycy4NCihkZWZjdXN0 b20gdGVtcC1idWZmZXItbWF4LWhlaWdodA0KICAobGFtYmRhIChidWZmZXIpDQogICAgKGlm IChlcSAoc2VsZWN0ZWQtd2luZG93KSAoZnJhbWUtcm9vdC13aW5kb3cpKQ0KCSgvICh4LWRp c3BsYXktcGl4ZWwtaGVpZ2h0KSAoZnJhbWUtY2hhci1oZWlnaHQpIDIpDQogICAgICAoLyAo LSAoZnJhbWUtaGVpZ2h0KSAyKSAyKSkpDQogICJNYXhpbXVtIGhlaWdodCBvZiBhIHdpbmRv dyBkaXNwbGF5aW5nIGEgdGVtcG9yYXJ5IGJ1ZmZlci4NClRoaXMgaXMgZWZmZWN0aXZlIG9u bHkgd2hlbiBUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSBpcyBlbmFibGVkLg0KVGhlIHZhbHVl IGlzIHRoZSBtYXhpbXVtIGhlaWdodCAoaW4gbGluZXMpIHdoaWNoDQpgcmVzaXplLXRlbXAt YnVmZmVyLXdpbmRvdycgd2lsbCBnaXZlIHRvIGEgd2luZG93IGRpc3BsYXlpbmcgYQ0KdGVt cG9yYXJ5IGJ1ZmZlci4gIEl0IGNhbiBhbHNvIGJlIGEgZnVuY3Rpb24gdG8gYmUgY2FsbGVk IHRvDQpjaG9vc2UgdGhlIGhlaWdodCBmb3Igc3VjaCBhIGJ1ZmZlci4gIEl0IGdldHMgb25l IGFyZ3VtZW50LCB0aGUNCmJ1ZmZlciwgYW5kIHNob3VsZCByZXR1cm4gYSBwb3NpdGl2ZSBp bnRlZ2VyLiAgQXQgdGhlIHRpbWUgdGhlDQpmdW5jdGlvbiBpcyBjYWxsZWQsIHRoZSB3aW5k b3cgdG8gYmUgcmVzaXplZCBpcyBzZWxlY3RlZC4iDQogIDp0eXBlICcoY2hvaWNlIGludGVn ZXIgZnVuY3Rpb24pDQogIDpncm91cCAnaGVscA0KICA6dmVyc2lvbiAiMjQuMiIpDQoNCihk ZWZjdXN0b20gdGVtcC1idWZmZXItcmVzaXplLWZyYW1lcyBuaWwNCiAgIk5vbi1uaWwgbWVh bnMgYHRlbXAtYnVmZmVyLXJlc2l6ZS1tb2RlJyBjYW4gcmVzaXplIGZyYW1lcy4NCkEgZnJh bWUgY2FuIGJlIHJlc2l6ZWQgaWYgYW5kIG9ubHkgaWYgaXRzIHJvb3Qgd2luZG93IGlzIGEg bGl2ZQ0Kd2luZG93LiAgVGhlIGhlaWdodCBvZiB0aGUgcm9vdCB3aW5kb3cgaXMgc3ViamVj dCB0byB0aGUgdmFsdWVzIG9mDQpgdGVtcC1idWZmZXItbWF4LWhlaWdodCcgYW5kIGB3aW5k b3ctbWluLWhlaWdodCcuIg0KICA6dHlwZSAnYm9vbGVhbg0KICA6dmVyc2lvbiAiMjQuMiIN CiAgOmdyb3VwICdoZWxwKQ0KDQooZGVmaW5lLW1pbm9yLW1vZGUgdGVtcC1idWZmZXItcmVz aXplLW1vZGUNCiAgIlRvZ2dsZSBhdXRvLXNocmlua2luZyB0ZW1wIGJ1ZmZlciB3aW5kb3dz IChUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSkuDQpXaXRoIGEgcHJlZml4IGFyZ3VtZW50IEFS RywgZW5hYmxlIFRlbXAgQnVmZmVyIFJlc2l6ZSBtb2RlIGlmIEFSRw0KaXMgcG9zaXRpdmUs IGFuZCBkaXNhYmxlIGl0IG90aGVyd2lzZS4gIElmIGNhbGxlZCBmcm9tIExpc3AsDQplbmFi bGUgdGhlIG1vZGUgaWYgQVJHIGlzIG9taXR0ZWQgb3IgbmlsLg0KDQpXaGVuIFRlbXAgQnVm ZmVyIFJlc2l6ZSBtb2RlIGlzIGVuYWJsZWQsIHRoZSB3aW5kb3dzIGluIHdoaWNoIHdlDQpz aG93IGEgdGVtcG9yYXJ5IGJ1ZmZlciBhcmUgYXV0b21hdGljYWxseSByZWR1Y2VkIGluIGhl aWdodCB0bw0KZml0IHRoZSBidWZmZXIncyBjb250ZW50cywgYnV0IG5ldmVyIG1vcmUgdGhh bg0KYHRlbXAtYnVmZmVyLW1heC1oZWlnaHQnIG5vciBsZXNzIHRoYW4gYHdpbmRvdy1taW4t aGVpZ2h0Jy4NCg0KVGhpcyBtb2RlIGlzIHVzZWQgYnkgYGhlbHAnLCBgYXByb3BvcycgYW5k IGBjb21wbGV0aW9uJyBidWZmZXJzLA0KYW5kIHNvbWUgb3RoZXJzLiINCiAgOmdsb2JhbCB0 IDpncm91cCAnaGVscA0KICAoaWYgdGVtcC1idWZmZXItcmVzaXplLW1vZGUNCiAgICAgIDs7 IGBoZWxwLW1ha2UteHJlZnMnIG1heSBhZGQgYSBgYmFjaycgYnV0dG9uIGFuZCB0aHVzIGlu Y3JlYXNlIHRoZQ0KICAgICAgOzsgdGV4dCBzaXplLCBzbyBgcmVzaXplLXRlbXAtYnVmZmVy LXdpbmRvdycgbXVzdCBiZSBydW4gKmFmdGVyKiBpdC4NCiAgICAgIChhZGQtaG9vayAndGVt cC1idWZmZXItc2hvdy1ob29rICdyZXNpemUtdGVtcC1idWZmZXItd2luZG93ICdhcHBlbmQp DQogICAgKHJlbW92ZS1ob29rICd0ZW1wLWJ1ZmZlci1zaG93LWhvb2sgJ3Jlc2l6ZS10ZW1w LWJ1ZmZlci13aW5kb3cpKSkNCg0KKGRlZnVuIHJlc2l6ZS10ZW1wLWJ1ZmZlci13aW5kb3cg KCZvcHRpb25hbCB3aW5kb3cpDQogICJSZXNpemUgV0lORE9XIHRvIGZpdCBpdHMgY29udGVu dHMuDQpXSU5ET1cgY2FuIGJlIGFueSBsaXZlIHdpbmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhl IHNlbGVjdGVkIG9uZS4NCg0KRG8gbm90IG1ha2UgV0lORE9XIGhpZ2hlciB0aGFuIGB0ZW1w LWJ1ZmZlci1tYXgtaGVpZ2h0JyBub3INCnNtYWxsZXIgdGhhbiBgd2luZG93LW1pbi1oZWln aHQnLiAgRG8gbm90aGluZyBpZiB0aGUgc2VsZWN0ZWQNCndpbmRvdyBpcyBub3QgdmVydGlj YWxseSBjb21iaW5lZCBvciBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUNCnNjcm9sbGVkIG91 dCBvZiB2aWV3LiINCiAgKHNldHEgd2luZG93ICh3aW5kb3ctbm9ybWFsaXplLWxpdmUtd2lu ZG93IHdpbmRvdykpDQogIChsZXQgKChoZWlnaHQgKGlmIChmdW5jdGlvbnAgdGVtcC1idWZm ZXItbWF4LWhlaWdodCkNCgkJICAgIChmdW5jYWxsIHRlbXAtYnVmZmVyLW1heC1oZWlnaHQg KHdpbmRvdy1idWZmZXIgd2luZG93KSkNCgkJICB0ZW1wLWJ1ZmZlci1tYXgtaGVpZ2h0KSkp DQogICAgKGNvbmQNCiAgICAgKChhbmQgKHBvcy12aXNpYmxlLWluLXdpbmRvdy1wIChwb2lu dC1taW4pIHdpbmRvdykNCgkgICAod2luZG93LWNvbWJpbmVkLXAgd2luZG93KSkNCiAgICAg IChmaXQtd2luZG93LXRvLWJ1ZmZlciB3aW5kb3cgaGVpZ2h0KSkNCiAgICAgKChhbmQgdGVt cC1idWZmZXItcmVzaXplLWZyYW1lcw0KCSAgIChlcSB3aW5kb3cgKGZyYW1lLXJvb3Qtd2lu ZG93IHdpbmRvdykpDQoJICAgKG1lbXEgKGNhciAod2luZG93LXBhcmFtZXRlciB3aW5kb3cg J3F1aXQtcmVzdG9yZSkpDQoJCSA7OyBJZiAnc2FtZSBpcyB0b28gc3Ryb25nLCB3ZSBtaWdo dCBhZGRpdGlvbmFsbHkgY2hlY2sNCgkJIDs7IHdoZXRoZXIgdGhlIHNlY29uZCBlbGVtZW50 IGlzICdmcmFtZS4NCgkJICcoc2FtZSBmcmFtZSkpKQ0KICAgICAgKGxldCAoKGZyYW1lICh3 aW5kb3ctZnJhbWUgd2luZG93KSkpDQoJKGZpdC1mcmFtZS10by1idWZmZXINCgkgZnJhbWUg KCsgKGZyYW1lLWhlaWdodCBmcmFtZSkNCgkJICAoLSAod2luZG93LXRvdGFsLXNpemUgd2lu ZG93KSkNCgkJICBoZWlnaHQpKSkpKSkpDQoNCihkZWZ2YXIgdGVtcC1idWZmZXItd2luZG93 LXNldHVwLWhvb2sgbmlsDQogICJOb3JtYWwgaG9vayBydW4gYnkgYHdpdGgtdGVtcC1idWZm ZXItd2luZG93JyBiZWZvcmUgYnVmZmVyIGRpc3BsYXkuDQpUaGlzIGhvb2sgaXMgcnVuIGJ5 IGB3aXRoLXRlbXAtYnVmZmVyLXdpbmRvdycgd2l0aCB0aGUgYnVmZmVyIHRvIGJlDQpkaXNw bGF5ZWQgY3VycmVudC4iKQ0KDQooZGVmdmFyIHRlbXAtYnVmZmVyLXdpbmRvdy1zaG93LWhv b2sgbmlsDQogICJOb3JtYWwgaG9vayBydW4gYnkgYHdpdGgtdGVtcC1idWZmZXItd2luZG93 JyBhZnRlciBidWZmZXIgZGlzcGxheS4NClRoaXMgaG9vayBpcyBydW4gYnkgYHdpdGgtdGVt cC1idWZmZXItd2luZG93JyB3aXRoIHRoZSBidWZmZXINCmRpc3BsYXllZCBhbmQgY3VycmVu dCBhbmQgaXRzIHdpbmRvdyBzZWxlY3RlZC4iKQ0KDQooZGVmdW4gdGVtcC1idWZmZXItd2lu ZG93LXNldHVwIChidWZmZXItb3ItbmFtZSkNCiAgIlNldCB1cCB0ZW1wb3JhcnkgYnVmZmVy IHNwZWNpZmllZCBieSBCVUZGRVItT1ItTkFNRSANClJldHVybiB0aGUgYnVmZmVyLiINCiAg KGxldCAoKG9sZC1kaXIgZGVmYXVsdC1kaXJlY3RvcnkpDQoJKGJ1ZmZlciAoZ2V0LWJ1ZmZl ci1jcmVhdGUgYnVmZmVyLW9yLW5hbWUpKSkNCiAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciBi dWZmZXINCiAgICAgIChraWxsLWFsbC1sb2NhbC12YXJpYWJsZXMpDQogICAgICAoc2V0cSBk ZWZhdWx0LWRpcmVjdG9yeSBvbGQtZGlyKQ0KOzsgICAgICAgKGRlbGV0ZS1hbGwtb3Zlcmxh eXMpDQogICAgICAoc2V0cSBidWZmZXItcmVhZC1vbmx5IG5pbCkNCiAgICAgIChzZXRxIGJ1 ZmZlci1maWxlLW5hbWUgbmlsKQ0KICAgICAgKHNldHEgYnVmZmVyLXVuZG8tbGlzdCB0KQ0K ICAgICAgKGxldCAoKGluaGliaXQtcmVhZC1vbmx5IHQpDQoJICAgIChpbmhpYml0LW1vZGlm aWNhdGlvbi1ob29rcyB0KSkNCgkoZXJhc2UtYnVmZmVyKQ0KCShydW4taG9va3MgJ3RlbXAt YnVmZmVyLXdpbmRvdy1zZXR1cC1ob29rKSkNCiAgICAgIDs7IFJldHVybiB0aGUgYnVmZmVy Lg0KICAgICAgYnVmZmVyKSkpDQoNCihkZWZ1biB0ZW1wLWJ1ZmZlci13aW5kb3ctc2hvdyAo Jm9wdGlvbmFsIGJ1ZmZlcikNCiAgIlNob3cgdGVtcG9yYXJ5IGJ1ZmZlciBCVUZGRVIgaW4g YSB3aW5kb3cuDQpSZXR1cm4gdGhlIHdpbmRvdyBzaG93aW5nIEJVRkZFUi4iDQogIChsZXQg KHdpbmRvdyBmcmFtZSkNCiAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciBidWZmZXINCiAgICAg IChzZXQtYnVmZmVyLW1vZGlmaWVkLXAgbmlsKQ0KICAgICAgKHNldHEgYnVmZmVyLXJlYWQt b25seSB0KQ0KICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkNCiAgICAgICh3aGVuIChz ZXRxIHdpbmRvdyAoZGlzcGxheS1idWZmZXIgYnVmZmVyKSkNCgkoc2V0cSBmcmFtZSAod2lu ZG93LWZyYW1lIHdpbmRvdykpDQoJKHVubGVzcyAoZXEgZnJhbWUgKHNlbGVjdGVkLWZyYW1l KSkNCgkgIChyYWlzZS1mcmFtZSBmcmFtZSkpDQoJKHNldHEgbWluaWJ1ZmZlci1zY3JvbGwt d2luZG93IHdpbmRvdykNCgkoc2V0LXdpbmRvdy1oc2Nyb2xsIHdpbmRvdyAwKQ0KCSh3aXRo LXNlbGVjdGVkLXdpbmRvdyB3aW5kb3cNCgkgIChydW4taG9va3MgJ3RlbXAtYnVmZmVyLXdp bmRvdy1zaG93LWhvb2spDQoJICAod2hlbiB0ZW1wLWJ1ZmZlci1yZXNpemUtbW9kZQ0KCSAg ICAocmVzaXplLXRlbXAtYnVmZmVyLXdpbmRvdyB3aW5kb3cpKSkNCgk7OyBSZXR1cm4gdGhl IHdpbmRvdy4NCgl3aW5kb3cpKSkpDQoNCihkZWZtYWNybyB3aXRoLXRlbXAtYnVmZmVyLXdp bmRvdyAoYnVmZmVyLW9yLW5hbWUgcXVpdC1mdW5jdGlvbiAmcmVzdCBib2R5KQ0KICAiRXZh bHVhdGUgQk9EWSBhbmQgZGlzcGxheSBidWZmZXIgc3BlY2lmaWVkIGJ5IEJVRkZFUi1PUi1O QU1FLg0KQlVGRkVSLU9SLU5BTUUgbXVzdCBzcGVjaWZ5IGVpdGhlciBhIGxpdmUgYnVmZmVy IG9yIHRoZSBuYW1lIG9mIGENCmJ1ZmZlci4gIElmIG5vIGJ1ZmZlciB3aXRoIHN1Y2ggYSBu YW1lIGV4aXN0cywgY3JlYXRlIG9uZS4NCg0KTWFrZSBzdXJlIHRoZSBzcGVjaWZpZWQgYnVm ZmVyIGlzIGVtcHR5IGJlZm9yZSBldmFsdWF0aW5nIEJPRFkuDQpEbyBub3QgbWFrZSB0aGF0 IGJ1ZmZlciBjdXJyZW50IGZvciBCT0RZLiAgSW5zdGVhZCwgYmluZA0KYHN0YW5kYXJkLW91 dHB1dCcgdG8gdGhhdCBidWZmZXIsIHNvIHRoYXQgb3V0cHV0IGdlbmVyYXRlZCB3aXRoDQpg cHJpbjEnIGFuZCBzaW1pbGFyIGZ1bmN0aW9ucyBpbiBCT0RZIGdvZXMgaW50byB0aGF0IGJ1 ZmZlci4NCg0KQWZ0ZXIgZXZhbHVhdGluZyBCT0RZLCBtYXJrIHRoZSBzcGVjaWZpZWQgYnVm ZmVyIHVubW9kaWZpZWQgYW5kDQpyZWFkLW9ubHkgYW5kIGRpc3BsYXkgaXQgaW4gYSB3aW5k b3cuICBBdXRvLXNocmluayB0aGUgd2luZG93IGlmDQpgdGVtcC1idWZmZXItcmVzaXplLW1v ZGUnIGlzIGVuYWJsZWQuDQoNClJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgQk9EWSB1 bmxlc3MgUVVJVC1GVU5DVElPTiBzcGVjaWZpZXMNCmEgZnVuY3Rpb24uICBJbiB0aGF0IGNh c2UsIHJ1biB0aGUgZnVuY3Rpb24gd2l0aCB0d28gYXJndW1lbnRzIC0NCnRoZSB3aW5kb3cg c2hvd2luZyB0aGUgc3BlY2lmaWVkIGJ1ZmZlciBhbmQgdGhlIHZhbHVlIHJldHVybmVkIGJ5 DQpCT0RZIC0gYW5kIHJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgdGhhdCBmdW5jdGlv bi4NCg0KVGhpcyBjb25zdHJ1Y3QgaXMgc2ltaWxhciB0byBgd2l0aC1vdXRwdXQtdG8tdGVt cC1idWZmZXInIGJ1dA0KZG9lcyBuZWl0aGVyIHB1dCB0aGUgYnVmZmVyIGluIGhlbHAgbW9k ZSBub3IgZG9lcyBpdCBjYWxsDQpgdGVtcC1idWZmZXItc2hvdy1mdW5jdGlvbicuICBJdCBh bHNvIHJ1bnMgZGlmZmVyZW50IGhvb2tzLA0KbmFtZWx5IGB0ZW1wLWJ1ZmZlci13aW5kb3ct c2V0dXAtaG9vaycgKHdpdGggdGhlIHNwZWNpZmllZCBidWZmZXINCmN1cnJlbnQpIGFuZCBg dGVtcC1idWZmZXItd2luZG93LXNob3ctaG9vaycgKHdpdGggdGhlIHNwZWNpZmllZA0KYnVm ZmVyIGN1cnJlbnQgYW5kIHRoZSB3aW5kb3cgc2hvd2luZyBpdCBzZWxlY3RlZCkuDQoNClNp bmNlIHRoaXMgbWFjcm8gY2FsbHMgYGRpc3BsYXktYnVmZmVyJywgdGhlIHdpbmRvdyBkaXNw bGF5aW5nDQp0aGUgYnVmZmVyIGlzIHVzdWFsbHkgbm90IHNlbGVjdGVkIGFuZCB0aGUgc3Bl Y2lmaWVkIGJ1ZmZlcg0KdXN1YWxseSBub3QgbWFkZSBjdXJyZW50LiAgUVVJVC1GVU5DVElP TiBjYW4gb3ZlcnJpZGUgdGhhdC4iDQogIChkZWNsYXJlIChkZWJ1ZyB0KSkNCiAgKGxldCAo KGJ1ZmZlciAobWFrZS1zeW1ib2wgImJ1ZmZlciIpKQ0KCSh3aW5kb3cgKG1ha2Utc3ltYm9s ICJ3aW5kb3ciKSkNCgkodmFsdWUgKG1ha2Utc3ltYm9sICJ2YWx1ZSIpKSkNCiAgICBgKGxl dCogKCgsYnVmZmVyICh0ZW1wLWJ1ZmZlci13aW5kb3ctc2V0dXAgLGJ1ZmZlci1vci1uYW1l KSkNCgkgICAgKHN0YW5kYXJkLW91dHB1dCAsYnVmZmVyKQ0KCSAgICAsd2luZG93ICx2YWx1 ZSkNCiAgICAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciAsYnVmZmVyDQoJIChzZXRxICx2YWx1 ZSAocHJvZ24gLEBib2R5KSkNCgkgKHNldHEgLHdpbmRvdyAodGVtcC1idWZmZXItd2luZG93 LXNob3cgLGJ1ZmZlcikpKQ0KDQogICAgICAgKGlmIChmdW5jdGlvbnAgLHF1aXQtZnVuY3Rp b24pDQoJICAgKGZ1bmNhbGwgLHF1aXQtZnVuY3Rpb24gLHdpbmRvdyAsdmFsdWUpDQoJICx2 YWx1ZSkpKSkNCg0KKGRlZnVuIHdpbmRvdy0tZGlzcGxheS1idWZmZXIgKGJ1ZmZlciB3aW5k b3cgdHlwZSAmb3B0aW9uYWwgZGVkaWNhdGVkKQ0KICAiRGlzcGxheSBCVUZGRVIgaW4gV0lO RE9XIGFuZCBtYWtlIGl0cyBmcmFtZSB2aXNpYmxlLg0KVFlQRSBtdXN0IGJlIG9uZSBvZiB0 aGUgc3ltYm9scyBgcmV1c2UnLCBgd2luZG93JyBvciBgZnJhbWUnIGFuZA0KaXMgcGFzc2Vk IHVuYWx0ZXJlZCB0byBgZGlzcGxheS1idWZmZXItcmVjb3JkLXdpbmRvdycuIFNldA0KYHdp bmRvdy1kZWRpY2F0ZWQtcCcgdG8gREVESUNBVEVEIGlmIG5vbi1uaWwuICBSZXR1cm4gV0lO RE9XIGlmDQpCVUZGRVIgYW5kIFdJTkRPVyBhcmUgbGl2ZS4iDQogICh3aGVuIChhbmQgKGJ1 ZmZlci1saXZlLXAgYnVmZmVyKSAod2luZG93LWxpdmUtcCB3aW5kb3cpKQ0KICAgIChsZXQq ICgoZnJhbWUgKHdpbmRvdy1mcmFtZSB3aW5kb3cpKQ0KCSAgICh2aXNpYmxlIChmcmFtZS12 aXNpYmxlLXAgZnJhbWUpKSkNCiAgICAgIChkaXNwbGF5LWJ1ZmZlci1yZWNvcmQtd2luZG93 IHR5cGUgd2luZG93IGJ1ZmZlcikNCiAgICAgICh1bmxlc3MgKGVxIGJ1ZmZlciAod2luZG93 LWJ1ZmZlciB3aW5kb3cpKQ0KCShzZXQtd2luZG93LWRlZGljYXRlZC1wIHdpbmRvdyBuaWwp DQoJKHNldC13aW5kb3ctYnVmZmVyIHdpbmRvdyBidWZmZXIpDQoJKHdoZW4gZGVkaWNhdGVk DQoJICAoc2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCB3aW5kb3cgZGVkaWNhdGVkKSkpDQogICAg ICAod2hlbiAobWVtcSB0eXBlICcod2luZG93IGZyYW1lKSkNCgkoc2V0LXdpbmRvdy1wcmV2 LWJ1ZmZlcnMgd2luZG93IG5pbCkpDQoNCiAgICAgICh1bmxlc3MgKG9yIChub3QgdmlzaWJs ZSkNCgkJICA7OyBBc3N1bWUgdGhlIHNlbGVjdGVkIGZyYW1lIGlzIGFscmVhZHkgdmlzaWJs ZSBlbm91Z2guDQoJCSAgKGVxIGZyYW1lIChzZWxlY3RlZC1mcmFtZSkpDQoJCSAgOzsgQXNz dW1lIHRoZSBmcmFtZSBmcm9tIHdoaWNoIHdlIGludm9rZWQgdGhlIG1pbmlidWZmZXINCgkJ ICA7OyBpcyB2aXNpYmxlLg0KCQkgIChhbmQgKG1pbmlidWZmZXItd2luZG93LWFjdGl2ZS1w IChzZWxlY3RlZC13aW5kb3cpKQ0KCQkgICAgICAgKGVxIGZyYW1lICh3aW5kb3ctZnJhbWUg KG1pbmlidWZmZXItc2VsZWN0ZWQtd2luZG93KSkpKSkNCgkocmFpc2UtZnJhbWUgZnJhbWUp KQ0KDQogICAgICB3aW5kb3cpKSkNCg0KKGRlZnVuIHF1aXQtcmVzdG9yZS13aW5kb3cgKCZv cHRpb25hbCB3aW5kb3cgYnVyeS1vci1raWxsKQ0KICAiUXVpdCBXSU5ET1cgYW5kIGRlYWwg d2l0aCBpdHMgYnVmZmVyLg0KV0lORE9XIG11c3QgYmUgYSBsaXZlIHdpbmRvdyBhbmQgZGVm YXVsdHMgdG8gdGhlIHNlbGVjdGVkIG9uZS4NCg0KQWNjb3JkaW5nIHRvIGluZm9ybWF0aW9u IHN0b3JlZCBpbiBXSU5ET1cncyBgcXVpdC1yZXN0b3JlJyB3aW5kb3cNCnBhcmFtZXRlciBl aXRoZXIgKDEpIGRlbGV0ZSBXSU5ET1cgYW5kIGl0cyBmcmFtZSwgKDIpIGRlbGV0ZQ0KV0lO RE9XLCAoMykgcmVzdG9yZSB0aGUgYnVmZmVyIHByZXZpb3VzbHkgZGlzcGxheWVkIGluIFdJ TkRPVywNCm9yICg0KSBtYWtlIFdJTkRPVyBkaXNwbGF5IHNvbWUgb3RoZXIgYnVmZmVyIHRo YW4gdGhlIHByZXNlbnQNCm9uZS4gIElmIG5vbi1uaWwsIHJlc2V0IGBxdWl0LXJlc3RvcmUn IHBhcmFtZXRlciB0byBuaWwuDQoNCk9wdGlvbmFsIHNlY29uZCBhcmd1bWVudCBCVVJZLU9S LUtJTEwgdGVsbHMgaG93IHRvIHByb2NlZWQgd2l0aA0KdGhlIGJ1ZmZlciBvZiBXSU5ET1cu ICBUaGUgZm9sbG93aW5nIHZhbHVlcyBhcmUgaGFuZGxlZDoNCg0KYG5pbCcgbWVhbnMgdG8g bm90IGhhbmRsZSB0aGUgYnVmZmVyIGluIGEgcGFydGljdWxhciB3YXkuICBUaGlzDQogIG1l YW5zIHRoYXQgaWYgV0lORE9XIGlzIG5vdCBkZWxldGVkIGJ5IHRoaXMgZnVuY3Rpb24sIGlu dm9raW5nDQogIGBzd2l0Y2gtdG8tcHJldi1idWZmZXInIHdpbGwgdXN1YWxseSBzaG93IHRo ZSBidWZmZXIgYWdhaW4uDQoNCmBhcHBlbmQnIG1lYW5zIHRoYXQgaWYgV0lORE9XIGlzIG5v dCBkZWxldGVkLCBtb3ZlIGl0cyBidWZmZXIgdG8NCiAgdGhlIGVuZCBvZiBXSU5ET1cncyBw cmV2aW91cyBidWZmZXJzIHNvIGl0J3MgbGVzcyBsaWtlbHkgdGhhdCBhDQogIGZ1dHVyZSBp bnZvY2F0aW9uIG9mIGBzd2l0Y2gtdG8tcHJldi1idWZmZXInIHdpbGwgc3dpdGNoIHRvIGl0 Lg0KICBBbHNvLCBtb3ZlIHRoZSBidWZmZXIgdG8gdGhlIGVuZCBvZiB0aGUgZnJhbWUncyBi dWZmZXIgbGlzdC4NCg0KYGJ1cnknIG1lYW5zIHRoYXQgaWYgV0lORE9XIGlzIG5vdCBkZWxl dGVkLCByZW1vdmUgaXRzIGJ1ZmZlcg0KICBmcm9tIFdJTkRPVydTIGxpc3Qgb2YgcHJldmlv dXMgYnVmZmVycy4gIEFsc28sIG1vdmUgdGhlIGJ1ZmZlcg0KICB0byB0aGUgZW5kIG9mIHRo ZSBmcmFtZSdzIGJ1ZmZlciBsaXN0LiAgVGhpcyB2YWx1ZSBwcm92aWRlcyB0aGUNCiAgbW9z dCByZWxpYWJsZSByZW1lZHkgdG8gbm90IGhhdmUgYHN3aXRjaC10by1wcmV2LWJ1ZmZlcicg c3dpdGNoDQogIHRvIHRoaXMgYnVmZmVyIGFnYWluIHdpdGhvdXQga2lsbGluZyB0aGUgYnVm ZmVyLg0KDQpga2lsbCcgbWVhbnMgdG8ga2lsbCBXSU5ET1cncyBidWZmZXIuIg0KICAoc2V0 cSB3aW5kb3cgKHdpbmRvdy1ub3JtYWxpemUtd2luZG93IHdpbmRvdyB0KSkNCiAgKGxldCog KChidWZmZXIgKHdpbmRvdy1idWZmZXIgd2luZG93KSkNCgkgKHF1aXQtcmVzdG9yZSAod2lu ZG93LXBhcmFtZXRlciB3aW5kb3cgJ3F1aXQtcmVzdG9yZSkpDQoJIChwcmV2LWJ1ZmZlcg0K CSAgKGxldCogKChwcmV2LWJ1ZmZlcnMgKHdpbmRvdy1wcmV2LWJ1ZmZlcnMgd2luZG93KSkN CgkJIChwcmV2LWJ1ZmZlciAoY2FhciBwcmV2LWJ1ZmZlcnMpKSkNCgkgICAgKGFuZCAob3Ig KG5vdCAoZXEgcHJldi1idWZmZXIgYnVmZmVyKSkNCgkJICAgICAoYW5kIChjZHIgcHJldi1i dWZmZXJzKQ0KCQkJICAobm90IChlcSAoc2V0cSBwcmV2LWJ1ZmZlciAoY2FkciBwcmV2LWJ1 ZmZlcnMpKQ0KCQkJCSAgIGJ1ZmZlcikpKSkNCgkJIHByZXYtYnVmZmVyKSkpDQoJIHF1YWQg ZW50cnkpDQogICAgKGNvbmQNCiAgICAgKChhbmQgKG5vdCBwcmV2LWJ1ZmZlcikNCgkgICAo bWVtcSAobnRoIDEgcXVpdC1yZXN0b3JlKSAnKHdpbmRvdyBmcmFtZSkpDQoJICAgKGVxIChu dGggMyBxdWl0LXJlc3RvcmUpIGJ1ZmZlcikNCgkgICA7OyBEZWxldGUgV0lORE9XIGlmIHBv c3NpYmxlLg0KCSAgICh3aW5kb3ctLWRlbGV0ZSB3aW5kb3cgbmlsIChlcSBidXJ5LW9yLWtp bGwgJ2tpbGwpKSkNCiAgICAgIDs7IElmIHRoZSBwcmV2aW91c2x5IHNlbGVjdGVkIHdpbmRv dyBpcyBzdGlsbCBhbGl2ZSwgc2VsZWN0IGl0Lg0KICAgICAgKHdoZW4gKHdpbmRvdy1saXZl LXAgKG50aCAyIHF1aXQtcmVzdG9yZSkpDQoJKHNlbGVjdC13aW5kb3cgKG50aCAyIHF1aXQt cmVzdG9yZSkpKSkNCiAgICAgKChhbmQgKGxpc3RwIChzZXRxIHF1YWQgKG50aCAxIHF1aXQt cmVzdG9yZSkpKQ0KCSAgIChidWZmZXItbGl2ZS1wIChjYXIgcXVhZCkpDQoJICAgKGVxIChu dGggMyBxdWl0LXJlc3RvcmUpIGJ1ZmZlcikpDQogICAgICA7OyBTaG93IGFub3RoZXIgYnVm ZmVyIHN0b3JlZCBpbiBxdWl0LXJlc3RvcmUgcGFyYW1ldGVyLg0KICAgICAgKHdoZW4gKGFu ZCAoaW50ZWdlcnAgKG50aCAzIHF1YWQpKQ0KCQkgKC89IChudGggMyBxdWFkKSAod2luZG93 LXRvdGFsLXNpemUgd2luZG93KSkpDQoJOzsgVHJ5IHRvIHJlc2l6ZSBXSU5ET1cgdG8gaXRz IG9sZCBoZWlnaHQgYnV0IGRvbid0IHNpZ25hbCBhbg0KCTs7IGVycm9yLg0KCShjb25kaXRp b24tY2FzZSBuaWwNCgkgICAgKHdpbmRvdy1yZXNpemUgd2luZG93ICgtIChudGggMyBxdWFk KSAod2luZG93LXRvdGFsLXNpemUgd2luZG93KSkpDQoJICAoZXJyb3IgbmlsKSkpDQogICAg ICAoc2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCB3aW5kb3cgbmlsKQ0KICAgICAgOzsgUmVzdG9y ZSBXSU5ET1cncyBwcmV2aW91cyBidWZmZXIsIHN0YXJ0IGFuZCBwb2ludCBwb3NpdGlvbi4N CiAgICAgIChzZXQtd2luZG93LWJ1ZmZlci1zdGFydC1hbmQtcG9pbnQNCiAgICAgICB3aW5k b3cgKG50aCAwIHF1YWQpIChudGggMSBxdWFkKSAobnRoIDIgcXVhZCkpDQogICAgICA7OyBE ZWFsIHdpdGggdGhlIGJ1ZmZlciB3ZSBqdXN0IHJlbW92ZWQgZnJvbSBXSU5ET1cuDQogICAg ICAoc2V0cSBlbnRyeSAoYW5kIChlcSBidXJ5LW9yLWtpbGwgJ2FwcGVuZCkNCgkJICAgICAg IChhc3NxIGJ1ZmZlciAod2luZG93LXByZXYtYnVmZmVycyB3aW5kb3cpKSkpDQogICAgICAo d2hlbiBidXJ5LW9yLWtpbGwNCgk7OyBSZW1vdmUgYnVmZmVyIGZyb20gV0lORE9XJ3MgcHJl dmlvdXMgYW5kIG5leHQgYnVmZmVycy4NCgkoc2V0LXdpbmRvdy1wcmV2LWJ1ZmZlcnMNCgkg d2luZG93IChhc3NxLWRlbGV0ZS1hbGwgYnVmZmVyICh3aW5kb3ctcHJldi1idWZmZXJzIHdp bmRvdykpKQ0KCShzZXQtd2luZG93LW5leHQtYnVmZmVycw0KCSB3aW5kb3cgKGRlbHEgYnVm ZmVyICh3aW5kb3ctbmV4dC1idWZmZXJzIHdpbmRvdykpKSkNCiAgICAgICh3aGVuIGVudHJ5 DQoJOzsgQXBwZW5kIG9sZCBidWZmZXIncyBlbnRyeSB0byBsaXN0IG9mIFdJTkRPVydzIHBy ZXZpb3VzDQoJOzsgYnVmZmVycyBzbyBpdCdzIGxlc3MgbGlrZWx5IHRvIGdldCBzd2l0Y2hl ZCB0byBzb29uIGJ1dA0KCTs7IGBkaXNwbGF5LWJ1ZmZlci1pbi1wcmV2aW91cy13aW5kb3cn IGNhbiBuZXZlcnRoZWxlc3MgZmluZCBpdC4NCgkoc2V0LXdpbmRvdy1wcmV2LWJ1ZmZlcnMN Cgkgd2luZG93IChhcHBlbmQgKHdpbmRvdy1wcmV2LWJ1ZmZlcnMgd2luZG93KSAobGlzdCBl bnRyeSkpKSkNCiAgICAgIDs7IFJlc2V0IHRoZSBxdWl0LXJlc3RvcmUgcGFyYW1ldGVyLg0K ICAgICAgKHNldC13aW5kb3ctcGFyYW1ldGVyIHdpbmRvdyAncXVpdC1yZXN0b3JlIG5pbCkN CiAgICAgIDs7IFNlbGVjdCBvbGQgd2luZG93Lg0KICAgICAgKHdoZW4gKHdpbmRvdy1saXZl LXAgKG50aCAyIHF1aXQtcmVzdG9yZSkpDQoJKHNlbGVjdC13aW5kb3cgKG50aCAyIHF1aXQt cmVzdG9yZSkpKSkNCiAgICAgKHQNCiAgICAgIDs7IFNob3cgc29tZSBvdGhlciBidWZmZXIg aW4gV0lORE9XIGFuZCByZXNldCB0aGUgcXVpdC1yZXN0b3JlDQogICAgICA7OyBwYXJhbWV0 ZXIuDQogICAgICAoc2V0LXdpbmRvdy1wYXJhbWV0ZXIgd2luZG93ICdxdWl0LXJlc3RvcmUg bmlsKQ0KICAgICAgOzsgTWFrZSBzdXJlIHRoYXQgV0lORE9XIGlzIG5vIG1vcmUgZGVkaWNh dGVkLg0KICAgICAgKHNldC13aW5kb3ctZGVkaWNhdGVkLXAgd2luZG93IG5pbCkNCiAgICAg IChzd2l0Y2gtdG8tcHJldi1idWZmZXIgd2luZG93IGJ1cnktb3Ita2lsbCkpKQ0KDQogICAg OzsgRGVhbCB3aXRoIHRoZSBidWZmZXIuDQogICAgKGNvbmQNCiAgICAgKChub3QgKGJ1ZmZl ci1saXZlLXAgYnVmZmVyKSkpDQogICAgICgoZXEgYnVyeS1vci1raWxsICdraWxsKQ0KICAg ICAgKGtpbGwtYnVmZmVyIGJ1ZmZlcikpDQogICAgIChidXJ5LW9yLWtpbGwNCiAgICAgIChi dXJ5LWJ1ZmZlci1pbnRlcm5hbCBidWZmZXIpKSkpKQ0KDQooZGVmdW4gcXVpdC13aW5kb3cg KCZvcHRpb25hbCBraWxsIHdpbmRvdykNCiAgIlF1aXQgV0lORE9XIGFuZCBidXJ5IGl0cyBi dWZmZXIuDQpXSU5ET1cgbXVzdCBiZSBhIGxpdmUgd2luZG93IGFuZCBkZWZhdWx0cyB0byB0 aGUgc2VsZWN0ZWQgb25lLg0KV2l0aCBwcmVmaXggYXJndW1lbnQgS0lMTCBub24tbmlsLCBr aWxsIHRoZSBidWZmZXIgaW5zdGVhZCBvZg0KYnVyeWluZyBpdC4NCg0KQWNjb3JkaW5nIHRv IGluZm9ybWF0aW9uIHN0b3JlZCBpbiBXSU5ET1cncyBgcXVpdC1yZXN0b3JlJyB3aW5kb3cN CnBhcmFtZXRlciBlaXRoZXIgKDEpIGRlbGV0ZSBXSU5ET1cgYW5kIGl0cyBmcmFtZSwgKDIp IGRlbGV0ZQ0KV0lORE9XLCAoMykgcmVzdG9yZSB0aGUgYnVmZmVyIHByZXZpb3VzbHkgZGlz cGxheWVkIGluIFdJTkRPVywNCm9yICg0KSBtYWtlIFdJTkRPVyBkaXNwbGF5IHNvbWUgb3Ro ZXIgYnVmZmVyIHRoYW4gdGhlIHByZXNlbnQNCm9uZS4gIElmIG5vbi1uaWwsIHJlc2V0IGBx dWl0LXJlc3RvcmUnIHBhcmFtZXRlciB0byBuaWwuIg0KICAoaW50ZXJhY3RpdmUgIlAiKQ0K ICAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgKGlmIGtpbGwgJ2tpbGwgJ2J1cnkpKSkN Cg0KKGRlZmN1c3RvbSBmaXQtZnJhbWUtdG8tYnVmZmVyLWJvdHRvbS1tYXJnaW4gNA0KICAi Qm90dG9tIG1hcmdpbiBmb3IgYGZpdC1mcmFtZS10by1idWZmZXInLg0KVGhpcyBpcyB0aGUg bnVtYmVyIG9mIGxpbmVzIGBmaXQtZnJhbWUtdG8tYnVmZmVyJyBsZWF2ZXMgZnJlZSBhdCB0 aGUNCmJvdHRvbSBvZiB0aGUgZGlzcGxheSBpbiBvcmRlciB0byBub3Qgb2JzY3VyZSB0aGUg c3lzdGVtIHRhc2sgYmFyLiINCiAgOnR5cGUgJ2ludGVnZXINCiAgOnZlcnNpb24gIjI0LjIi DQogIDpncm91cCAnd2luZG93cykNCg0KKGRlZnVuIGZpdC1mcmFtZS10by1idWZmZXIgKCZv cHRpb25hbCBmcmFtZSBtYXgtaGVpZ2h0IG1pbi1oZWlnaHQpDQogICJBZGp1c3QgaGVpZ2h0 IG9mIEZSQU1FIHRvIGRpc3BsYXkgaXRzIGJ1ZmZlcidzIGNvbnRlbnRzIGV4YWN0bHkuDQpG UkFNRSBjYW4gYmUgYW55IGxpdmUgZnJhbWUgYW5kIGRlZmF1bHRzIHRvIHRoZSBzZWxlY3Rl ZCBvbmUuDQoNCk9wdGlvbmFsIGFyZ3VtZW50IE1BWC1IRUlHSFQgc3BlY2lmaWVzIHRoZSBt YXhpbXVtIGhlaWdodCBvZg0KRlJBTUUgYW5kIGRlZmF1bHRzIHRvIHRoZSBoZWlnaHQgb2Yg dGhlIGRpc3BsYXkgYmVsb3cgdGhlIGN1cnJlbnQNCnRvcCBsaW5lIG9mIEZSQU1FIG1pbnVz IEZJVC1GUkFNRS1UTy1CVUZGRVItQk9UVE9NLU1BUkdJTi4NCk9wdGlvbmFsIGFyZ3VtZW50 IE1JTi1IRUlHSFQgc3BlY2lmaWVzIHRoZSBtaW5pbXVtIGhlaWdodCBvZg0KRlJBTUUuIg0K ICAoaW50ZXJhY3RpdmUpDQogIChzZXRxIGZyYW1lICh3aW5kb3ctbm9ybWFsaXplLWZyYW1l IGZyYW1lKSkNCiAgKGxldCogKChyb290IChmcmFtZS1yb290LXdpbmRvdyBmcmFtZSkpDQoJ IChmcmFtZS1taW4taGVpZ2h0DQoJICAoKyAoLSAoZnJhbWUtaGVpZ2h0IGZyYW1lKSAod2lu ZG93LXRvdGFsLXNpemUgcm9vdCkpDQoJICAgICB3aW5kb3ctbWluLWhlaWdodCkpDQoJIChm cmFtZS10b3AgKGZyYW1lLXBhcmFtZXRlciBmcmFtZSAndG9wKSkNCgkgKHRvcCAoaWYgKGNv bnNwIGZyYW1lLXRvcCkNCgkJICAoZnVuY2FsbCAoY2FyIGZyYW1lLXRvcCkgKGNhZHIgZnJh bWUtdG9wKSkNCgkJZnJhbWUtdG9wKSkNCgkgKGZyYW1lLW1heC1oZWlnaHQNCgkgICgtICgv ICgtICh4LWRpc3BsYXktcGl4ZWwtaGVpZ2h0IGZyYW1lKSB0b3ApDQoJCShmcmFtZS1jaGFy LWhlaWdodCBmcmFtZSkpDQoJICAgICBmaXQtZnJhbWUtdG8tYnVmZmVyLWJvdHRvbS1tYXJn aW4pKQ0KCSBkZWx0YSkNCiAgICAod2hlbiAoYW5kICh3aW5kb3ctbGl2ZS1wIHJvb3QpIChu b3QgKHdpbmRvdy1zaXplLWZpeGVkLXAgcm9vdCkpKQ0KICAgICAgKHdpdGgtc2VsZWN0ZWQt d2luZG93IHJvb3QNCgkoY29uZA0KCSAoKG5vdCBtYXgtaGVpZ2h0KQ0KCSAgKHNldHEgbWF4 LWhlaWdodCBmcmFtZS1tYXgtaGVpZ2h0KSkNCgkgKChudW1iZXJwIG1heC1oZWlnaHQpDQoJ ICAoc2V0cSBtYXgtaGVpZ2h0IChtaW4gbWF4LWhlaWdodCBmcmFtZS1tYXgtaGVpZ2h0KSkp DQoJICh0DQoJICAoZXJyb3IgIiVzIGlzIGFuIGludmFsaWQgbWF4aW11bSBoZWlnaHQiIG1h eC1oZWlnaHQpKSkNCgkoY29uZA0KCSAoKG5vdCBtaW4taGVpZ2h0KQ0KCSAgKHNldHEgbWlu LWhlaWdodCBmcmFtZS1taW4taGVpZ2h0KSkNCgkgKChudW1iZXJwIG1pbi1oZWlnaHQpDQoJ ICAoc2V0cSBtaW4taGVpZ2h0IChtaW4gbWluLWhlaWdodCBmcmFtZS1taW4taGVpZ2h0KSkp DQoJICh0DQoJICAoZXJyb3IgIiVzIGlzIGFuIGludmFsaWQgbWluaW11bSBoZWlnaHQiIG1p bi1oZWlnaHQpKSkNCgkoc2V0cSBkZWx0YQ0KCSAgICAgIDs7IENvdW50IGEgZmluYWwgbmV3 bGluZSAtIHRoaXMgY29tcGVuc2F0ZXMgZm9yIHRoZQ0KCSAgICAgIDs7IG1pc3NpbmcgcG9z dC1wcm9jZXNpbmcgcGFydCBhZnRlciByZXNpemluZyB0aGUgZnJhbWUuDQoJICAgICAgKC0g KCsgKGNvdW50LXNjcmVlbi1saW5lcyBuaWwgbmlsIHQpDQoJCSAgICA7OyBGb3Igbm9uLW1p bmlidWZmZXJzIGNvdW50IHRoZSBtb2RlIGxpbmUsIGlmIGFueS4NCgkJICAgIChpZiAoYW5k IChub3QgKHdpbmRvdy1taW5pYnVmZmVyLXApKQ0KCQkJICAgICBtb2RlLWxpbmUtZm9ybWF0 KQ0KCQkJMQ0KCQkgICAgICAwKQ0KCQkgICAgOzsgQ291bnQgdGhlIGhlYWRlciBsaW5lLCBp ZiBhbnkuDQoJCSAgICAoaWYgaGVhZGVyLWxpbmUtZm9ybWF0IDEgMCkpDQoJCSAod2luZG93 LXRvdGFsLXNpemUpKSkpDQogICAgICA7OyBNb3ZlIGF3YXkgZnJvbSBmaW5hbCBuZXdsaW5l Lg0KICAgICAgKHdoZW4gKGFuZCAoZW9icCkgKGJvbHApIChub3QgKGJvYnApKSkNCgkoc2V0 LXdpbmRvdy1wb2ludCByb290IChsaW5lLWJlZ2lubmluZy1wb3NpdGlvbiAwKSkpDQogICAg ICAoc2V0LXdpbmRvdy1zdGFydCByb290IChwb2ludC1taW4pKQ0KICAgICAgKHNldC13aW5k b3ctdnNjcm9sbCByb290IDApDQogICAgICAoY29uZGl0aW9uLWNhc2UgbmlsDQoJICAoc2V0 LWZyYW1lLWhlaWdodA0KCSAgIGZyYW1lDQoJICAgKG1pbiAobWF4ICgrIChmcmFtZS1oZWln aHQgZnJhbWUpIGRlbHRhKQ0KCQkgICAgIG1pbi1oZWlnaHQpDQoJCW1heC1oZWlnaHQpKQ0K CShlcnJvciAoc2V0cSBkZWx0YSBuaWwpKSkpDQogICAgZGVsdGEpKQ0KDQo7OyBVc2FnZQ0K KGRlZnVuIHJlY292ZXItZmlsZSAoZmlsZSkNCiAgIlZpc2l0IGZpbGUgRklMRSwgYnV0IGdl dCBjb250ZW50cyBmcm9tIGl0cyBsYXN0IGF1dG8tc2F2ZSBmaWxlLiINCiAgOzsgQWN0dWFs bHkgcHV0dGluZyB0aGUgZmlsZSBuYW1lIGluIHRoZSBtaW5pYnVmZmVyIHNob3VsZCBiZSB1 c2VkDQogIDs7IG9ubHkgcmFyZWx5Lg0KICA7OyBOb3QganVzdCBiZWNhdXNlIHVzZXJzIG9m dGVuIHVzZSB0aGUgZGVmYXVsdC4NCiAgKGludGVyYWN0aXZlICJGUmVjb3ZlciBmaWxlOiAi KQ0KICAoc2V0cSBmaWxlIChleHBhbmQtZmlsZS1uYW1lIGZpbGUpKQ0KICAoaWYgKGF1dG8t c2F2ZS1maWxlLW5hbWUtcCAoZmlsZS1uYW1lLW5vbmRpcmVjdG9yeSBmaWxlKSkNCiAgICAg IChlcnJvciAiJXMgaXMgYW4gYXV0by1zYXZlIGZpbGUiIChhYmJyZXZpYXRlLWZpbGUtbmFt ZSBmaWxlKSkpDQogIChsZXQgKChmaWxlLW5hbWUgKGxldCAoKGJ1ZmZlci1maWxlLW5hbWUg ZmlsZSkpDQoJCSAgICAgKG1ha2UtYXV0by1zYXZlLWZpbGUtbmFtZSkpKSkNCiAgICAoY29u ZCAoKGlmIChmaWxlLWV4aXN0cy1wIGZpbGUpDQoJICAgICAgIChub3QgKGZpbGUtbmV3ZXIt dGhhbi1maWxlLXAgZmlsZS1uYW1lIGZpbGUpKQ0KCSAgICAgKG5vdCAoZmlsZS1leGlzdHMt cCBmaWxlLW5hbWUpKSkNCgkgICAoZXJyb3IgIkF1dG8tc2F2ZSBmaWxlICVzIG5vdCBjdXJy ZW50Ig0KCQkgIChhYmJyZXZpYXRlLWZpbGUtbmFtZSBmaWxlLW5hbWUpKSkNCgkgICgod2l0 aC10ZW1wLWJ1ZmZlci13aW5kb3cNCgkgICAgIipEaXJlY3RvcnkqIg0KCSAgICAjJyhsYW1i ZGEgKHdpbmRvdyBfdmFsdWUpDQoJCSh1bndpbmQtcHJvdGVjdA0KCQkgICAgKHllcy1vci1u by1wIChmb3JtYXQgIlJlY292ZXIgYXV0byBzYXZlIGZpbGUgJXM/ICIgZmlsZS1uYW1lKSkN CgkJICAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgJ2tpbGwpKSkNCgkgICAgKHdpdGgt Y3VycmVudC1idWZmZXIgc3RhbmRhcmQtb3V0cHV0DQoJICAgICAgKGxldCAoKHN3aXRjaGVz IGRpcmVkLWxpc3Rpbmctc3dpdGNoZXMpKQ0KCQkoaWYgKGZpbGUtc3ltbGluay1wIGZpbGUp DQoJCSAgICAoc2V0cSBzd2l0Y2hlcyAoY29uY2F0IHN3aXRjaGVzICIgLUwiKSkpDQoJCTs7 IFVzZSBpbnNlcnQtZGlyZWN0b3J5LXNhZmVseSwgbm90IGluc2VydC1kaXJlY3RvcnksDQoJ CTs7IGJlY2F1c2UgdGhlc2UgZmlsZXMgbWlnaHQgbm90IGV4aXN0LiAgSW4gcGFydGljdWxh ciwNCgkJOzsgRklMRSBtaWdodCBub3QgZXhpc3QgaWYgdGhlIGF1dG8tc2F2ZSBmaWxlIHdh cyBmb3INCgkJOzsgYSBidWZmZXIgdGhhdCBkaWRuJ3QgdmlzaXQgYSBmaWxlLCBzdWNoIGFz ICIqbWFpbCoiLg0KCQk7OyBUaGUgY29kZSBpbiB2MjAueCBjYWxsZWQgYGxzJyBkaXJlY3Rs eSwgc28gd2UgbmVlZA0KCQk7OyB0byBlbXVsYXRlIHdoYXQgYGxzJyBkaWQgaW4gdGhhdCBj YXNlLg0KCQkoaW5zZXJ0LWRpcmVjdG9yeS1zYWZlbHkgZmlsZSBzd2l0Y2hlcykNCgkJKGlu c2VydC1kaXJlY3Rvcnktc2FmZWx5IGZpbGUtbmFtZSBzd2l0Y2hlcykpKSkNCgkgICAoc3dp dGNoLXRvLWJ1ZmZlciAoZmluZC1maWxlLW5vc2VsZWN0IGZpbGUgdCkpDQoJICAgKGxldCAo KGluaGliaXQtcmVhZC1vbmx5IHQpDQoJCSA7OyBLZWVwIHRoZSBjdXJyZW50IGJ1ZmZlci1m aWxlLWNvZGluZy1zeXN0ZW0uDQoJCSAoY29kaW5nLXN5c3RlbSBidWZmZXItZmlsZS1jb2Rp bmctc3lzdGVtKQ0KCQkgOzsgQXV0by1zYXZlZCBmaWxlIHNob3VsZCBiZSByZWFkIHdpdGgg c3BlY2lhbCBjb2RpbmcuDQoJCSAoY29kaW5nLXN5c3RlbS1mb3ItcmVhZCAnYXV0by1zYXZl LWNvZGluZykpDQoJICAgICAoZXJhc2UtYnVmZmVyKQ0KCSAgICAgKGluc2VydC1maWxlLWNv bnRlbnRzIGZpbGUtbmFtZSBuaWwpDQoJICAgICAoc2V0LWJ1ZmZlci1maWxlLWNvZGluZy1z eXN0ZW0gY29kaW5nLXN5c3RlbSkpDQoJICAgKGFmdGVyLWZpbmQtZmlsZSBuaWwgbmlsIHQp KQ0KCSAgKHQgKHVzZXItZXJyb3IgIlJlY292ZXItZmlsZSBjYW5jZWxsZWQiKSkpKSkNCg0K KGRlZnVuIHNhdmUtYnVmZmVycy1raWxsLWVtYWNzICgmb3B0aW9uYWwgYXJnKQ0KICAiT2Zm ZXIgdG8gc2F2ZSBlYWNoIGJ1ZmZlciwgdGhlbiBraWxsIHRoaXMgRW1hY3MgcHJvY2Vzcy4N CldpdGggcHJlZml4IEFSRywgc2lsZW50bHkgc2F2ZSBhbGwgZmlsZS12aXNpdGluZyBidWZm ZXJzIHdpdGhvdXQgYXNraW5nLg0KSWYgdGhlcmUgYXJlIGFjdGl2ZSBwcm9jZXNzZXMgd2hl cmUgYHByb2Nlc3MtcXVlcnktb24tZXhpdC1mbGFnJw0KcmV0dXJucyBub24tbmlsLCBhc2tz IHdoZXRoZXIgcHJvY2Vzc2VzIHNob3VsZCBiZSBraWxsZWQuDQpSdW5zIHRoZSBtZW1iZXJz IG9mIGBraWxsLWVtYWNzLXF1ZXJ5LWZ1bmN0aW9ucycgaW4gdHVybiBhbmQgc3RvcHMNCmlm IGFueSByZXR1cm5zIG5pbC4gIElmIGBjb25maXJtLWtpbGwtZW1hY3MnIGlzIG5vbi1uaWws IGNhbGxzIGl0LiINCiAgKGludGVyYWN0aXZlICJQIikNCiAgKHNhdmUtc29tZS1idWZmZXJz IGFyZyB0KQ0KICAoYW5kIChvciAobm90IChtZW1xIHQgKG1hcGNhciAoZnVuY3Rpb24NCgkJ CQkgIChsYW1iZGEgKGJ1ZikgKGFuZCAoYnVmZmVyLWZpbGUtbmFtZSBidWYpDQoJCQkJCQkg ICAgIChidWZmZXItbW9kaWZpZWQtcCBidWYpKSkpDQoJCQkJKGJ1ZmZlci1saXN0KSkpKQ0K CSAgICh5ZXMtb3Itbm8tcCAiTW9kaWZpZWQgYnVmZmVycyBleGlzdDsgZXhpdCBhbnl3YXk/ ICIpKQ0KICAgICAgIChvciAobm90IChmYm91bmRwICdwcm9jZXNzLWxpc3QpKQ0KCSAgIDs7 IHByb2Nlc3MtbGlzdCBpcyBub3QgZGVmaW5lZCBvbiBNU0RPUy4NCgkgICAobGV0ICgocHJv Y2Vzc2VzIChwcm9jZXNzLWxpc3QpKQ0KCQkgYWN0aXZlKQ0KCSAgICAgKHdoaWxlIHByb2Nl c3Nlcw0KCSAgICAgICAoYW5kIChtZW1xIChwcm9jZXNzLXN0YXR1cyAoY2FyIHByb2Nlc3Nl cykpICcocnVuIHN0b3Agb3BlbiBsaXN0ZW4pKQ0KCQkgICAgKHByb2Nlc3MtcXVlcnktb24t ZXhpdC1mbGFnIChjYXIgcHJvY2Vzc2VzKSkNCgkJICAgIChzZXRxIGFjdGl2ZSB0KSkNCgkg ICAgICAgKHNldHEgcHJvY2Vzc2VzIChjZHIgcHJvY2Vzc2VzKSkpDQoJICAgICAob3IgKG5v dCBhY3RpdmUpDQoJCSAod2l0aC10ZW1wLWJ1ZmZlci13aW5kb3cgKGdldC1idWZmZXItY3Jl YXRlICIqUHJvY2VzcyBMaXN0KiIpDQoJCSAgICMnKGxhbWJkYSAod2luZG93IF92YWx1ZSkN CgkJICAgICAgICh1bndpbmQtcHJvdGVjdA0KCQkJICAgKHllcy1vci1uby1wICJBY3RpdmUg cHJvY2Vzc2VzIGV4aXN0OyBraWxsIHRoZW0gYW5kIGV4aXQgYW55d2F5PyAiKQ0KCQkJIChx dWl0LXJlc3RvcmUtd2luZG93IHdpbmRvdyAna2lsbCkpKQ0KCQkgICAobGlzdC1wcm9jZXNz ZXMgdCkpKSkpDQogICAgICAgOzsgUXVlcnkgdGhlIHVzZXIgZm9yIG90aGVyIHRoaW5ncywg cGVyaGFwcy4NCiAgICAgICAocnVuLWhvb2std2l0aC1hcmdzLXVudGlsLWZhaWx1cmUgJ2tp bGwtZW1hY3MtcXVlcnktZnVuY3Rpb25zKQ0KICAgICAgIChvciAobnVsbCBjb25maXJtLWtp bGwtZW1hY3MpDQoJICAgKGZ1bmNhbGwgY29uZmlybS1raWxsLWVtYWNzICJSZWFsbHkgZXhp dCBFbWFjcz8gIikpDQogICAgICAgKGtpbGwtZW1hY3MpKSkNCg0KKGRlZnVuIGRpcmVkLW1h cmstcG9wLXVwIChidWZmZXItb3ItbmFtZSBvcC1zeW1ib2wgZmlsZXMgZnVuY3Rpb24gJnJl c3QgYXJncykNCiAgIlJldHVybiBGVU5DVElPTidzIHJlc3VsdCBvbiBBUkdTIGFmdGVyIHNo b3dpbmcgd2hpY2ggZmlsZXMgYXJlIG1hcmtlZC4NCkRpc3BsYXlzIHRoZSBmaWxlIG5hbWVz IGluIGEgd2luZG93IHNob3dpbmcgYSBidWZmZXIgbmFtZWQNCkJVRkZFUi1PUi1OQU1FOyB0 aGUgZGVmYXVsdCBuYW1lIGJlaW5nIFwiICpNYXJrZWQgRmlsZXMqXCIuICBUaGUNCndpbmRv dyBpcyBub3Qgc2hvd24gaWYgdGhlcmUgaXMganVzdCBvbmUgZmlsZSwgYGRpcmVkLW5vLWNv bmZpcm0nDQppcyB0LCBvciBPUC1TWU1CT0wgaXMgYSBtZW1iZXIgb2YgdGhlIGxpc3QgaW4g YGRpcmVkLW5vLWNvbmZpcm0nLg0KDQpGSUxFUyBpcyB0aGUgbGlzdCBvZiBtYXJrZWQgZmls ZXMuICBJdCBjYW4gYWxzbyBiZSAodCBGSUxFTkFNRSkNCmluIHRoZSBjYXNlIG9mIG9uZSBt YXJrZWQgZmlsZSwgdG8gZGlzdGluZ3Vpc2ggdGhhdCBmcm9tIHVzaW5nDQpqdXN0IHRoZSBj dXJyZW50IGZpbGUuDQoNCkZVTkNUSU9OIHNob3VsZCBub3QgbWFuaXB1bGF0ZSBmaWxlcywg anVzdCByZWFkIGlucHV0IFwoYW4NCmFyZ3VtZW50IG9yIGNvbmZpcm1hdGlvbikuIg0KICAo aWYgKG9yIChlcSBkaXJlZC1uby1jb25maXJtIHQpDQoJICAobWVtcSBvcC1zeW1ib2wgZGly ZWQtbm8tY29uZmlybSkNCgkgIDs7IElmIEZJTEVTIGRlZmF1bHRlZCB0byB0aGUgY3VycmVu dCBsaW5lJ3MgZmlsZS4NCgkgICg9IChsZW5ndGggZmlsZXMpIDEpKQ0KICAgICAgKGFwcGx5 IGZ1bmN0aW9uIGFyZ3MpDQogICAgKGxldCAoKGJ1ZmZlciAoZ2V0LWJ1ZmZlci1jcmVhdGUg KG9yIGJ1ZmZlci1vci1uYW1lICIgKk1hcmtlZCBGaWxlcyoiKSkpKQ0KICAgICAgKHdpdGgt Y3VycmVudC1idWZmZXIgYnVmZmVyDQoJKGxldCAoKHNwbGl0LWhlaWdodC10aHJlc2hvbGQg MCkNCgkgICAgICAoZGlzcGxheS1idWZmZXItYXBwLWFjdGlvbg0KCSAgICAgICAoY29ucyAn ZGlzcGxheS1idWZmZXItYmVsb3ctc2VsZWN0ZWQgbmlsKSkpDQoJICAod2l0aC10ZW1wLWJ1 ZmZlci13aW5kb3cNCgkgICBidWZmZXINCgkgICAjJyhsYW1iZGEgKHdpbmRvdyBfdmFsdWUp DQoJICAgICAgICh1bndpbmQtcHJvdGVjdA0KCQkgICAoYXBwbHkgZnVuY3Rpb24gYXJncykN CgkJIChxdWl0LXJlc3RvcmUtd2luZG93IHdpbmRvdyAna2lsbCkpKQ0KCSAgIDs7IEhhbmRs ZSAodCBGSUxFKSBqdXN0IGxpa2UgKEZJTEUpLCBoZXJlLiAgVGhhdCB2YWx1ZSBpcw0KCSAg IDs7IHVzZWQgKG9ubHkgaW4gc29tZSBjYXNlcyksIHRvIG1lYW4ganVzdCBvbmUgZmlsZSB0 aGF0IHdhcw0KCSAgIDs7IG1hcmtlZCwgcmF0aGVyIHRoYW4gdGhlIGN1cnJlbnQgbGluZSBm aWxlLg0KCSAgIChkaXJlZC1mb3JtYXQtY29sdW1ucy1vZi1maWxlcw0KCSAgICAoaWYgKGVx IChjYXIgZmlsZXMpIHQpIChjZHIgZmlsZXMpIGZpbGVzKSkNCgkgICAocmVtb3ZlLXRleHQt cHJvcGVydGllcyAocG9pbnQtbWluKSAocG9pbnQtbWF4KQ0KCQkJCSAgICcobW91c2UtZmFj ZSBuaWwgaGVscC1lY2hvIG5pbCkpKSkpKSkpDQo= --------------070601080905090706060001-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 14 10:57:57 2012 Received: (at 11939) by debbugs.gnu.org; 14 Jul 2012 14:57:57 +0000 Received: from localhost ([127.0.0.1]:41237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sq3nA-0001ke-ME for submit@debbugs.gnu.org; Sat, 14 Jul 2012 10:57:57 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:28045) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sq3n7-0001kU-3O for 11939@debbugs.gnu.org; Sat, 14 Jul 2012 10:57:54 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6EEq75m029311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Jul 2012 14:52:08 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6EEq6tU021518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 14:52:07 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6EEq6Lc030450; Sat, 14 Jul 2012 09:52:06 -0500 Received: from dradamslap1 (/10.159.219.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jul 2012 07:52:06 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sat, 14 Jul 2012 07:51:58 -0700 Message-ID: <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500173A5.3040608@gmx.at> Thread-Index: Ac1hxEyW2AKMtUQoQBWlkoU6vkrWeAABHzHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Thanks for looking at this, Martin. > What is your value of `minibuffer-auto-raise'? It is `t'. > Maybe `yes-or-no-p' > should do `select-frame-set-input-focus' in your case. What happens > usually when you ask a `yes-or-no-p' question in a > non-minibuffer frame? No problem. The typed answer (yes/no) is inserted in the minibuffer, as expected. E.g., I type this in a buffer/frame foo.el, and then use C-x C-e to evaluate it: (yes-or-no-p "Really? ") I type "yes" and it appears in the minibuffer frame. All is fine. In the problematic contexts, a new frame is popped up and given the focus (by MS Windows). That is apparently somehow different from starting from a frame that already has the focus. If I had to guess blindly, I'd guess that it has to do with the timing/sequencing of things: Maybe in the problematic case the question is FIRST posed in the minibuffer/echo area (giving the minibuffer frame focus) and THEN the new frame is popped up and it gets the focus. Whereas maybe in the case I just tested the focus never comes back to the frame that originally had it - once the focus goes to the minibuffer frame, there is nothing that puts it back in the original frame. Just a hunch. If that is the case, maybe a fix (ugly hack) would be to do this: Whenever the minibuffer frame has focus and some other frame is created, immediately return focus to the minibuffer frame. (Dunno _how_ that might be done.) > > Please do something to fix this. > > I'm afraid, most people here can't reproduce your problem. > We probably have to invent some new option to handle it. > In any case, we'd have to investigate the underlying problem. Or perhaps look to what Dired does... > > For inspiration, perhaps look to `dired-mark-pop-up' which > > does something similar but gets it right. See perhaps > > `dired-pop-to-buffer'. > > > > Better would be to fix this ask-for-input-after-popping-up-some-info > > problem generally, obviously. But a fix for just this particular > > query will be better than nothing. > > > > At least Dired DTRT now wrt focus - that's already something. > > > > Of course, for Dired I still have to modify `dired-mark-pop-up' > > anyway, to have it delete the window or frame popped up, afterward, > > and bury its buffer. See bug #7533 - a patch was provided for > > this but AFAIK Emacs Dev has never applied it. > > Try to load the attached file and tell me which problems you see. OK, thanks for trying seriously to solve this. I know that you look into things carefully. 1. FYI - I can test only with 24.1, not something later, since other bugs still prevent my using the later Windows builds. I'm still waiting for a build more recent than 2012-07-02. Dunno whether this matters here. 2. I tried to quit Emacs (C-x C-c) after creating a shell buffer (which is in a dedicated window in a separate frame). The informative buffer that lists the active processes was popped up correctly in a separate frame as the yes-or-no question was asked. But when I tried to type yes or no, that typed input appeared nowhere. I would guess, from the fact that Windows gives the new frame the input focus, that that new frame had the focus and the input was trying to go there. But that buffer is created read-only and I saw no error message indicating that Emacs was trying to insert the input (yes/no) into a read-only buffer. No feedback at all - it's as if my typed input was silently sent to /dev/null. (That in itself is not good.) In any case, what's important is that the typed input did not go to the minibuffer frame. C-g did not then exit the question, but C-] did. But then, instead of the process-list informative buffer and frame simply disappearing, that buffer was replaced in its frame (which should have been temporary) by the buffer that was current when I hit C-x C-c. 3. I marked 3 files in Dired and hit `C'. When I tried to type the destination directory I got an error saying that buffer *Marked Files* is read-only. IOW, the typed input was sent to that information buffer (in its popped up frame) and not to the minibuffer frame. Worse: just as above for the active processes popup, after canceling the copy operation the *Marked Files* frame did not disappear. Instead, the *Marked Files* buffer was replaced in its frame by the Dired buffer. So now I had two frames with the Dired buffer, one of which was a special-display frame (which has different frame parameters, e.g. colors). I thought that the focus problem was already fixed for this in vanilla Emacs, and that the patch I sent was needed only to take care of removing the frame and burying the buffer. But with the code you sent both problems are there. In any case, if I then use the definition of `dired-mark-pop-up' that I provided then the problems (both focus and removal) go away. IOW, even after loading the code you sent, all I need to do is evaluate this and the Dired dialog works perfectly again: ;; REPLACE ORIGINAL in `dired.el': ;; ;; Delete the window or frame popped up, afterward, and bury its buffer. ;; Fixes Emacs bug #7533. ;; (defun dired-mark-pop-up (bufname op-symbol files function &rest args) "Return FUNCTION's result on ARGS after showing which files are marked. Displays the file names in a buffer named BUFNAME; nil gives \" *Marked Files*\". This uses function `dired-pop-to-buffer' to do that. FUNCTION should not manipulate files, just read input (an argument or confirmation). The window is not shown if there is just one file or OP-SYMBOL is a member of the list in `dired-no-confirm'. FILES is the list of marked files. It can also be (t FILENAME) in the case of one marked file, to distinguish that from using just the current file." (or bufname (setq bufname " *Marked Files*")) (let (result) (if (or (eq dired-no-confirm t) (memq op-symbol dired-no-confirm) ;; If FILES defaulted to the current line's file. (= (length files) 1)) (setq result (apply function args)) (with-current-buffer (get-buffer-create bufname) (erase-buffer) ;; Handle (t FILE) just like (FILE), here. ;; That value is used (only in some cases), to mean ;; just one file that was marked, rather than the current line file. (dired-format-columns-of-files (if (eq (car files) t) (cdr files) files)) (remove-text-properties (point-min) (point-max) '(mouse-face nil help-echo nil))) (unwind-protect (save-window-excursion (dired-pop-to-buffer bufname) (setq result (apply function args))) (save-excursion (condition-case nil ; Ignore error if user already deleted window. (progn (select-window (get-buffer-window bufname 0)) (if (one-window-p) (delete-frame) (delete-window))) (error nil))) (bury-buffer bufname))) result)) I thought that the patch I sent for this was going to be applied to Emacs - but it never was. I use this code everyday, with no problem. But the dialog is still broken in vanilla Emacs. Thanks for working on this, Martin. It would be great if this problem could be fixed in general (i.e., beyond just Dired). From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 14 12:25:03 2012 Received: (at 11939) by debbugs.gnu.org; 14 Jul 2012 16:25:03 +0000 Received: from localhost ([127.0.0.1]:41308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sq59T-0004ed-Ae for submit@debbugs.gnu.org; Sat, 14 Jul 2012 12:25:03 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52235) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sq59Q-0004eD-6o for 11939@debbugs.gnu.org; Sat, 14 Jul 2012 12:25:02 -0400 Received: (qmail invoked by alias); 14 Jul 2012 16:19:14 -0000 Received: from 62-47-47-202.adsl.highway.telekom.at (EHLO [62.47.47.202]) [62.47.47.202] by mail.gmx.net (mp038) with SMTP; 14 Jul 2012 18:19:14 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+yi0YcSe2yk4xj8MPgaCYY4e3qUQIeA5OjdtuwVz 0SxK6Y5PvK929Q Message-ID: <50019C2F.8060103@gmx.at> Date: Sat, 14 Jul 2012 18:19:59 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> In-Reply-To: <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > In the problematic contexts, a new frame is popped up and given the focus (by MS > Windows). That is apparently somehow different from starting from a frame that > already has the focus. OK. What happens if in in `yes-or-no-p' you use (when minibuffer-auto-raise (select-frame-set-input-focus (window-frame (minibuffer-window)))) instead of `raise-frame'? > If I had to guess blindly, I'd guess that it has to do with the > timing/sequencing of things: Maybe in the problematic case the question is FIRST > posed in the minibuffer/echo area (giving the minibuffer frame focus) and THEN > the new frame is popped up and it gets the focus. I suppose `handle-switch-frame' is called after the `yes-or-no-p'. Then even the `select-frame-set-input-focus' would not help. > Whereas maybe in the case I just tested the focus never comes back to the frame > that originally had it - once the focus goes to the minibuffer frame, there is > nothing that puts it back in the original frame. Just a hunch. > > If that is the case, maybe a fix (ugly hack) would be to do this: Whenever the > minibuffer frame has focus and some other frame is created, immediately return > focus to the minibuffer frame. (Dunno _how_ that might be done.) What happens if in `with-temp-buffer-window' you add a `save-selected-window' around (with-current-buffer ,buffer (setq ,value (progn ,@body)) (setq ,window (temp-buffer-window-show ,buffer))) > Or perhaps look to what Dired does... Dired uses a `save-window-excursion' which doesn't deal with the frame but restores the selected window - maybe that's the reason. > 1. FYI - I can test only with 24.1, not something later, since other bugs still > prevent my using the later Windows builds. I'm still waiting for a build more > recent than 2012-07-02. Dunno whether this matters here. What I sent should work with 24.1. > 2. I tried to quit Emacs (C-x C-c) after creating a shell buffer (which is in a > dedicated window in a separate frame). > > The informative buffer that lists the active processes was popped up correctly > in a separate frame as the yes-or-no question was asked. But when I tried to > type yes or no, that typed input appeared nowhere. > > I would guess, from the fact that Windows gives the new frame the input focus, > that that new frame had the focus and the input was trying to go there. But > that buffer is created read-only and I saw no error message indicating that > Emacs was trying to insert the input (yes/no) into a read-only buffer. No > feedback at all - it's as if my typed input was silently sent to /dev/null. > (That in itself is not good.) > > In any case, what's important is that the typed input did not go to the > minibuffer frame. Can you try with just `pop-up-frames' t, that is, disabling special display buffers? > [...] > I thought that the patch I sent for this was going to be applied to Emacs - but > it never was. I use this code everyday, with no problem. But the dialog is > still broken in vanilla Emacs. I understand your concerns. But we have to first find out why your system behaves differently and then try to find a general solution. BTW, has bug#11566 been resolved meanwhile? martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 14 13:18:32 2012 Received: (at 11939) by debbugs.gnu.org; 14 Jul 2012 17:18:32 +0000 Received: from localhost ([127.0.0.1]:41371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sq5zD-0006kw-7W for submit@debbugs.gnu.org; Sat, 14 Jul 2012 13:18:31 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:47769) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sq5zA-0006ko-OD for 11939@debbugs.gnu.org; Sat, 14 Jul 2012 13:18:30 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6EHCgX0023625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Jul 2012 17:12:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6EHCfUQ020372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 17:12:42 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6EHCfcv027353; Sat, 14 Jul 2012 12:12:41 -0500 Received: from dradamslap1 (/10.159.219.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jul 2012 10:12:41 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sat, 14 Jul 2012 10:12:33 -0700 Message-ID: <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50019C2F.8060103@gmx.at> Thread-Index: Ac1h3GpvFgLQfflsRACGMrPU4U2/mAAAg/NQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > OK. What happens if in in `yes-or-no-p' you use > (when minibuffer-auto-raise > (select-frame-set-input-focus > (window-frame (minibuffer-window)))) > instead of `raise-frame'? Sorry, I don't understand. `yes-or-no-p' is coded in C. Where should I change a call to raise-frame to instead use the above code? > I suppose `handle-switch-frame' is called after the `yes-or-no-p'. > Then even the `select-frame-set-input-focus' would not help. > > What happens if in `with-temp-buffer-window' you add a > `save-selected-window' around > (with-current-buffer ,buffer > (setq ,value (progn ,@body)) > (setq ,window (temp-buffer-window-show ,buffer))) I tried just that (nothing from above about modifying yes-or-no-p, since I don't understand what you mean there). It did not change anything: C-x C-c still did nothing when I typed an answer to the prompt about active processes. And again, when I hit C-] the buffer that was current before C-x C-c replaced the buffer that lists the active processes in its frame. > > Or perhaps look to what Dired does... > > Dired uses a `save-window-excursion' which doesn't deal with the frame > but restores the selected window - maybe that's the reason. > > Can you try with just `pop-up-frames' t, that is, disabling special > display buffers? OK, I tried that: still using my setup, I set `special-display-regexps' to nil then tried C-x C-c etc. That changed nothing (except that the popped up buffer appeared in a regular frame, not a special-display frame). The symptoms were identical AFAICT: input did not go to minibuffer, and quitting (C-]) left the frame but put the originally current buffer in it, replacing the processes-list buffer there. Oh, it also changed this: Now when I hit `q' in *Help*, instead of the frame being removed I get another buffer in it, substituted for *Help*. This in spite of the fact that `special-display-buffer-names' has this entry, which should make *Help* be dedicated: ("*Help*" 1on1-display-*Help*-frame ((background-color . "Thistle") (mouse-color . "Blue Violet") (cursor-color . "Blue Violet") (height . 40))) Buffer *Help* is still popped up in a new frame that has those colors, but now when I hit `q' in it the frame does not disappear and its buffer is changed. That's not what I would call "dedicated" anymore. Dunno if there is another bug here. HTH. > I understand your concerns. But we have to first find out why your > system behaves differently and then try to find a general solution. Agreed. If someone on MS Windows were willing to try oneonone.el (and set `special-display-regexps' to ("[ ]?[*][^*]+[*]")) then they would likely be able to see the behavior for themselves. (Dunno for sure whether other things in my setup are involved. If someone is really interested then we can pursue it.) > BTW, has bug#11566 been resolved meanwhile? Not at all (not that I know of/can tell). The last message in that thread is from me, and its questions were never answered. My guess is that these bugs are related, if not the same underneath. [BTW/FWIW, in #11566, there was some discussion of `select-frame' vs `select-frame-set-input-focus. I can confirm again that these definitely are not the same, and the former is not sufficient in some cases, which is why I end up calling the latter in some contexts. I noted this mentally a while ago when I encountered it again, since I recalled then that it had been suggested in that thread that `select-frame' should be sufficient.] From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 15 09:05:51 2012 Received: (at 11939) by debbugs.gnu.org; 15 Jul 2012 13:05:52 +0000 Received: from localhost ([127.0.0.1]:41978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqOWD-0001zF-Ld for submit@debbugs.gnu.org; Sun, 15 Jul 2012 09:05:50 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52931) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SqOWA-0001z7-Ux for 11939@debbugs.gnu.org; Sun, 15 Jul 2012 09:05:48 -0400 Received: (qmail invoked by alias); 15 Jul 2012 12:59:56 -0000 Received: from 62-47-62-104.adsl.highway.telekom.at (EHLO [62.47.62.104]) [62.47.62.104] by mail.gmx.net (mp016) with SMTP; 15 Jul 2012 14:59:56 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+ublNRG96uZi91LrS+91V9EUOYdm1z8wqvzhrUOJ 7beg5ta789gvkm Message-ID: <5002BEC6.3040106@gmx.at> Date: Sun, 15 Jul 2012 14:59:50 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> In-Reply-To: <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> OK. What happens if in in `yes-or-no-p' you use >> (when minibuffer-auto-raise >> (select-frame-set-input-focus >> (window-frame (minibuffer-window)))) >> instead of `raise-frame'? > > Sorry, I don't understand. `yes-or-no-p' is coded in C. Where should I change > a call to raise-frame to instead use the above code? Sorry. Do (defalias 'yes-or-no-p 'y-or-n-p) and then try. > C-x C-c still did nothing when I typed an answer to the prompt about active > processes. And again, when I hit C-] ... what command is C-] bound to? I can't type it on my keyboard ... > the buffer that was current before C-x C-c > replaced the buffer that lists the active processes in its frame. > >> > Or perhaps look to what Dired does... >> >> Dired uses a `save-window-excursion' which doesn't deal with the frame >> but restores the selected window - maybe that's the reason. >> >> Can you try with just `pop-up-frames' t, that is, disabling special >> display buffers? > > OK, I tried that: still using my setup, I set `special-display-regexps' to nil > then tried C-x C-c etc. > > That changed nothing (except that the popped up buffer appeared in a regular > frame, not a special-display frame). The symptoms were identical AFAICT: input > did not go to minibuffer, and quitting (C-]) left the frame but put the > originally current buffer in it, replacing the processes-list buffer there. But it does work with emacs -Q on your system, I suppose? So the problem seems that input doesn't get redirected to your minibuffer frame when popping up a new minibuffer-less frame. > Oh, it also changed this: Now when I hit `q' in *Help*, instead of the frame > being removed I get another buffer in it, substituted for *Help*. This in spite > of the fact that `special-display-buffer-names' has this entry, which should > make *Help* be dedicated: > > ("*Help*" 1on1-display-*Help*-frame > ((background-color . "Thistle") > (mouse-color . "Blue Violet") > (cursor-color . "Blue Violet") > (height . 40))) > > Buffer *Help* is still popped up in a new frame that has those colors, but now > when I hit `q' in it the frame does not disappear and its buffer is changed. > That's not what I would call "dedicated" anymore. Dunno if there is another bug > here. HTH. That's hardly surprising: With `pop-up-frames' t you shouldn't get a dedicated window, I suppose. > If someone on MS Windows were willing to try oneonone.el (and set > `special-display-regexps' to ("[ ]?[*][^*]+[*]")) then they would likely be able > to see the behavior for themselves. > > (Dunno for sure whether other things in my setup are involved. If someone is > really interested then we can pursue it.) Things would get simpler if you were able to supply a reasonably small file to test this so we wouldn't always have to get through your entire setup and completely lose our testing environments. For me, debugging and testing things with emacs -Q is already hard enough. >> BTW, has bug#11566 been resolved meanwhile? > > Not at all (not that I know of/can tell). The last message in that thread is > from me, and its questions were never answered. Then why do you suggest at the beginning of the current thread to >> "look to `dired-mark-pop-up' which does something similar but gets it right" if it apparently doesn't get it right anyway? > My guess is that these bugs are related, if not the same underneath. > > [BTW/FWIW, in #11566, there was some discussion of `select-frame' vs > `select-frame-set-input-focus. I can confirm again that these definitely are > not the same, and the former is not sufficient in some cases, which is why I end > up calling the latter in some contexts. I noted this mentally a while ago when > I encountered it again, since I recalled then that it had been suggested in that > thread that `select-frame' should be sufficient.] It would be fine if we were able to sketch the problem as follows: If a user has a (1) minibuffer-only frame and all other frames use that minibuffer and (2) a `yes-or-no-p' or `read-from-minibuffer' prompt pops up in a separate frame then `select-frame-set-input-focus' is needed to redirect input to that minibuffer-only frame inorder to answer the question. Can't you try to provide a test example on this basis? The Elisp manual doesn't help me at all when I try doing that. For example, if I want to know how to use `set-minibuffer-window' for setting up the minibuffer-window to use for a minibuffer-less frame, I'm completely lost. If with emacs -Q I do (let ((frame-1 (make-frame '((minibuffer . only)))) (frame-2 (make-frame '((minibuffer . nil))))) (set-minibuffer-window (frame-root-window frame-1))) then I still can't delete the initial frame because the minibuffer-window for frame-2 is that of the initial frame. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 15 11:12:55 2012 Received: (at 11939) by debbugs.gnu.org; 15 Jul 2012 15:12:55 +0000 Received: from localhost ([127.0.0.1]:42943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqQVC-0006mc-N4 for submit@debbugs.gnu.org; Sun, 15 Jul 2012 11:12:55 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:29830) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqQVA-0006mR-BD for 11939@debbugs.gnu.org; Sun, 15 Jul 2012 11:12:53 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6FF71HZ019157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jul 2012 15:07:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6FF70iF008582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 15:07:00 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6FF70kJ031512; Sun, 15 Jul 2012 10:07:00 -0500 Received: from dradamslap1 (/10.159.181.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Jul 2012 08:06:59 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sun, 15 Jul 2012 08:06:47 -0700 Message-ID: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5002BEC6.3040106@gmx.at> Thread-Index: Ac1iib3rnASF21esQ6yH2C6IU4ad4AAB8RZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Hi Martin, > >> OK. What happens if in in `yes-or-no-p' you use > >> (when minibuffer-auto-raise > >> (select-frame-set-input-focus > >> (window-frame (minibuffer-window)))) > >> instead of `raise-frame'? > > > > Sorry, I don't understand. `yes-or-no-p' is coded in C. > > Where should I change a call to raise-frame to instead use the above code? > > Sorry. Do (defalias 'yes-or-no-p 'y-or-n-p) and then try. Are you sure you mean that? AFAIK, `y-or-n-p' is not at all representative - it does not even use the minibuffer, I think: it just reads events directly. I will try to do as you instruct, if you confirm, but I do not understand how using `y-or-n-p' here can possibly help. > ... what command is C-] bound to? I can't type it on my keyboard ... `abort-recursive-edit'. `C-]' is the (only) default global binding (emacs -Q) for `abort-recursive-edit'. > > OK, I tried that: still using my setup, I set > > `special-display-regexps' to nil then tried C-x C-c etc. > > > > That changed nothing (except that the popped up buffer > > appeared in a regular frame, not a special-display frame). > > The symptoms were identical AFAICT: input > > did not go to minibuffer, and quitting (C-]) left the > > frame but put the originally current buffer in it, replacing the > > processes-list buffer there. > > But it does work with emacs -Q on your system, I suppose? I'm not sure just what the test was to be here. But I tried with emacs -Q (plus loading cygwin-mount.el & setup-cygwin.el, so that I have a bash shell on Windows). I tried first with nil `pop-up-frames' - that behaved normally, i.e., as it should. I tried then with non-nil `pop-up-frames' - and that manifested the same problem that I reported! Good news! So even *without* a standalone minibuffer and the rest of my setup, this bug is reproducible. Thanks for helping find that. (Perhaps there are additional problems, but we need not worry about those now, if any in fact exist.) So that's great news. A simple recipe: 1. On MS Windows (I'm using XP SP3). (I hope someone on Windows will confirm and help.) 2. emacs -Q 3. Load cygwin-mount.el, then setup-cygwin.el (from Emacs Wiki's Elisp Area). 4. M-x set-variable pop-up-frames t 5. M-x shell 6. C-x C-c The informative buffer *Process List* is popped up in a separate frame, which apparently gets the focus. The question about killing active processes appears in the minibuffer of the original frame (which has only buffer *shell*). Because the new frame has the focus, _you cannot answer the question_. You are forced to select the frame with the question (e.g. clicking mouse-1 on its title bar), in order to answer it and exit Emacs. A second bug (I think) is that there is NO feedback/response to your typing the answer. With focus in the *Process List* frame, which has a read-only buffer, I would expect an error message saying that the buffer is read-only. But you get NO message - nada. Not only that, but I see no such message in buffer *Messages* if I look there. Dunno why this is. > So the problem seems that input doesn't get redirected to your > minibuffer frame when popping up a new minibuffer-less frame. Seems to not depend on a standalone minibuffer frame, but yes, that seems to be the problem. Well, that's one problem, anyway. Really, I do not want the new frame popped up to have a minibuffer and pose the question about killing processes. I want the new frame to just be displayed and _not selected_ for input/output (user interaction). I do not want it to have a minibuffer. More precisely, I don't have much of an opinion in the case of a non standalone minibuffer. But in the case of a standalone minibuffer, it definitely should continue to have the input focus. That's the point, for me. It would not be a solution for me to give the new frame its own minibuffer or something and to let it keep the input focus. The user should be able to always look to the same, standalone minibuffer - the *only* minibuffer area - for all prompts and user replies. > > Oh, it also changed this: Now when I hit `q' in *Help*, > > instead of the frame being removed I get another buffer in it, > > substituted for *Help*. This in spite of the fact that > > `special-display-buffer-names' has this entry, which should > > make *Help* be dedicated: > > > > ("*Help*" 1on1-display-*Help*-frame > > ((background-color . "Thistle") > > (mouse-color . "Blue Violet") > > (cursor-color . "Blue Violet") > > (height . 40))) > > > > Buffer *Help* is still popped up in a new frame that has > > those colors, but now when I hit `q' in it the frame does not > > disappear and its buffer is changed. That's not what I would > > call "dedicated" anymore. > > That's hardly surprising: With `pop-up-frames' t you shouldn't get a > dedicated window, I suppose. Uh, if you are saying what I think you are saying then I'm afraid I disagree strongly about that. To me, that would be a regression. If a buffer is declared via `special-display-buffer-names' to be special-display, then it _must be_ special-display. That must not be violated just because `pop-up-frames' might have some particular value. I *hope* I am just misunderstanding you here - I hope you are not suggesting that `special-display-buffer-names' is no longer enough to ensure that a buffer is special-display. > >> BTW, has bug#11566 been resolved meanwhile? > > > > Not at all (not that I know of/can tell). The last message in > > that thread is from me, and its questions were never answered. > > Then why do you suggest at the beginning of the current thread to > > >> "look to `dired-mark-pop-up' which does something similar > >> but gets it right" > > if it apparently doesn't get it right anyway? I'm sorry; I was probably confused in saying that. I must have meant that it works with the patch I sent, which (I thought) was applied to Emacs (or was going to be applied). If I use Dired+ (which does what my patch does) then there is no problem, so in my daily use this is solved for the Dired but reported, but not in general (viz. this bug wrt quitting with active processes). > It would be fine if we were able to sketch the problem as > follows: If a user has a > > (1) minibuffer-only frame and all other frames use that minibuffer and > (2) a `yes-or-no-p' or `read-from-minibuffer' prompt pops up in a > separate frame > > then `select-frame-set-input-focus' is needed to redirect > input to that minibuffer-only frame inorder to answer the question. See above. What you say might well be involved (i.e., be part of a solution), but the problem (of this bug) is apparently present even without a standalone minibuffer frame. > Can't you try to provide a test example on this basis? I don't know how. I did suggest in the bug #11566 thread that perhaps `read-from-minibuffer' could do something like that systematically, and I thought briefly that I had found a general solution that way, but I soon discovered that `message' then had no effect! No messages were ever output if I did that. > The Elisp manual doesn't help me at all when I try doing that. > For example, if I want to know how to use `set-minibuffer-window' > for setting up the minibuffer-window to use for > a minibuffer-less frame, I'm completely lost. I'm sorry I can't help either, here. I know less about this than you do - especially wrt Emacs windows, for which you are the expert. > If with emacs -Q I do > (let ((frame-1 (make-frame '((minibuffer . only)))) > (frame-2 (make-frame '((minibuffer . nil))))) > (set-minibuffer-window (frame-root-window frame-1))) > > then I still can't delete the initial frame because the > minibuffer-window for frame-2 is that of the initial frame. Ah, there I can help, in a minimal way at least, by confirming. I don't know why, and I cannot really explain anything here, but yes: If you want a standalone minibuffer frame to have the _only_ minibuffer then you must do everything at load time, i.e., in .emacs. That is why I have provided bug-repro recipes in the past that used this: runemacs.exe -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs" Command `1on1-emacs' must be run before the initial frame is created. Otherwise, there will be a frame that has its own minibuffer, and you will never be able to get rid of that frame (as you discovered). IOW, it is too late to create your standalone minibuffer, once Emacs has already created a frame with a normal minibuffer. Whether this SHOULD be the case I cannot answer, but it has always been the case with Gnu Emacs, AFAIK. That is why I tell users of oneonone.el that they must do this: (require 'oneonone) (1on1-emacs) rather than just invoke `1on1-emacs' after Emacs has already created its initial frame, e.g., `M-x 1on1-emacs'. With the simple reproducible test case above, we are making real progress. I hope we can finally find a solution to this problem. My guess is that it lies at the root of a majority of the problems I've had with GNU Emacs and frames - problems that I have been trying to work around for decades. FWIW: Many Moon Ago, I used Epoch, which offered, out of the box, the ability to have a standalone minibuffer frame (they did not call it that), which stretched across the bottom of your display (by default). (No customization necessary - maybe you used a command switch when invoking the editor, I don't recall.) I found that to be a wonderful, simple, reasonable way to interact with Emacs (yes, Epoch was as much Emacs as GNU Emacs is). And I tried to reproduce that behavior in GNU Emacs. I've come close, but this problem, in particular, has always plagued me to some extent in my attempts. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 15 12:14:06 2012 Received: (at 11939) by debbugs.gnu.org; 15 Jul 2012 16:14:06 +0000 Received: from localhost ([127.0.0.1]:42976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqRSP-00088B-Ek for submit@debbugs.gnu.org; Sun, 15 Jul 2012 12:14:06 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:40530) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SqRSJ-00087c-Om for 11939@debbugs.gnu.org; Sun, 15 Jul 2012 12:14:03 -0400 Received: (qmail invoked by alias); 15 Jul 2012 16:08:07 -0000 Received: from 62-47-62-104.adsl.highway.telekom.at (EHLO [62.47.62.104]) [62.47.62.104] by mail.gmx.net (mp038) with SMTP; 15 Jul 2012 18:08:07 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19gLKonMuFgkK85Zo7ogsZh/LXDkiBxBQsePBdZLg VkvvmO8WjF7N5O Message-ID: <5002EAF4.5080107@gmx.at> Date: Sun, 15 Jul 2012 18:08:20 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> In-Reply-To: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> Content-Type: multipart/mixed; boundary="------------060001040808080405070808" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------060001040808080405070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Sorry. Do (defalias 'yes-or-no-p 'y-or-n-p) and then try. > > Are you sure you mean that? AFAIK, `y-or-n-p' is not at all representative - it > does not even use the minibuffer, I think: it just reads events directly. I > will try to do as you instruct, if you confirm, but I do not understand how > using `y-or-n-p' here can possibly help. Because you can do `select-frame-set-input-focus' with it. >> ... what command is C-] bound to? I can't type it on my keyboard ... > > `abort-recursive-edit'. `C-]' is the (only) default global binding (emacs -Q) > for `abort-recursive-edit'. My keyboard doesn't allow me to input things like C-] easily so I don't know what these do. >> But it does work with emacs -Q on your system, I suppose? > > I'm not sure just what the test was to be here. But I tried with emacs -Q (plus > loading cygwin-mount.el & setup-cygwin.el, so that I have a bash shell on > Windows). > > I tried first with nil `pop-up-frames' - that behaved normally, i.e., as it > should. I tried then with non-nil `pop-up-frames' - and that manifested the > same problem that I reported! Good news! If you get the problem with `pop-up-frames' t and not with the special display settings we have simplified the problem. > The informative buffer *Process List* is popped up in a separate frame, which > apparently gets the focus. The question about killing active processes appears > in the minibuffer of the original frame (which has only buffer *shell*). > > Because the new frame has the focus, _you cannot answer the question_. You are > forced to select the frame with the question (e.g. clicking mouse-1 on its title > bar), in order to answer it and exit Emacs. OK. > A second bug (I think) is that there is NO feedback/response to your typing the > answer. With focus in the *Process List* frame, which has a read-only buffer, I > would expect an error message saying that the buffer is read-only. But you get > NO message - nada. Not only that, but I see no such message in buffer > *Messages* if I look there. Dunno why this is. I suppose that as long as you don't type either yes or no in the original frame nothing happens at all. >> So the problem seems that input doesn't get redirected to your >> minibuffer frame when popping up a new minibuffer-less frame. > > Seems to not depend on a standalone minibuffer frame, but yes, that seems to be > the problem. Agreed. > Well, that's one problem, anyway. Really, I do not want the new frame popped up > to have a minibuffer and pose the question about killing processes. I want the > new frame to just be displayed and _not selected_ for input/output (user > interaction). I do not want it to have a minibuffer. But we must select a frame for answering the question. > More precisely, I don't have much of an opinion in the case of a non standalone > minibuffer. > > But in the case of a standalone minibuffer, it definitely should continue to > have the input focus. That's the point, for me. Why "continue"? You could invoke C-x C-c in any frame. > It would not be a solution for me to give the new frame its own minibuffer or > something and to let it keep the input focus. The user should be able to always > look to the same, standalone minibuffer - the *only* minibuffer area - for all > prompts and user replies. We'll see to that. >> > Buffer *Help* is still popped up in a new frame that has >> > those colors, but now when I hit `q' in it the frame does not >> > disappear and its buffer is changed. That's not what I would >> > call "dedicated" anymore. >> >> That's hardly surprising: With `pop-up-frames' t you shouldn't get a >> dedicated window, I suppose. > > Uh, if you are saying what I think you are saying then I'm afraid I disagree > strongly about that. To me, that would be a regression. Don't be afraid. I meant with `pop-up-frames' t and `special-display-buffer-names' and friends nil. > I'm sorry; I was probably confused in saying that. I must have meant that it > works with the patch I sent, which (I thought) was applied to Emacs (or was > going to be applied). > > If I use Dired+ (which does what my patch does) then there is no problem, so in > my daily use this is solved for the Dired but reported, but not in general (viz. > this bug wrt quitting with active processes). But your patch doesn't address the input focus issue or am I missing something? > If you want a standalone minibuffer frame to have the _only_ minibuffer then you > must do everything at load time, i.e., in .emacs. So this makes debugging more difficult for people who are not used to work with minibuffer-only frames. I have attached another version of `with-temp-buffer-window' which now explicitly shifts input focus to the frame selected at the time the macro is called. I hope this will fix the `pop-up-frames' t scenario. I'm afraid it will not fix the problem when you invoke C-x C-c in any window but the minibuffer-only window so we probably have to fix that issue separately. Please try it. martin --------------060001040808080405070808 Content-Type: application/emacs-lisp; name="with-temp-buffer-window.el" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="with-temp-buffer-window.el" Ozs7IEF1dG9tYXRpYyByZXNpemluZyBvZiB0ZW1wb3JhcnkgYnVmZmVycy4NCihkZWZjdXN0 b20gdGVtcC1idWZmZXItbWF4LWhlaWdodA0KICAobGFtYmRhIChidWZmZXIpDQogICAgKGlm IChlcSAoc2VsZWN0ZWQtd2luZG93KSAoZnJhbWUtcm9vdC13aW5kb3cpKQ0KCSgvICh4LWRp c3BsYXktcGl4ZWwtaGVpZ2h0KSAoZnJhbWUtY2hhci1oZWlnaHQpIDIpDQogICAgICAoLyAo LSAoZnJhbWUtaGVpZ2h0KSAyKSAyKSkpDQogICJNYXhpbXVtIGhlaWdodCBvZiBhIHdpbmRv dyBkaXNwbGF5aW5nIGEgdGVtcG9yYXJ5IGJ1ZmZlci4NClRoaXMgaXMgZWZmZWN0aXZlIG9u bHkgd2hlbiBUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSBpcyBlbmFibGVkLg0KVGhlIHZhbHVl IGlzIHRoZSBtYXhpbXVtIGhlaWdodCAoaW4gbGluZXMpIHdoaWNoDQpgcmVzaXplLXRlbXAt YnVmZmVyLXdpbmRvdycgd2lsbCBnaXZlIHRvIGEgd2luZG93IGRpc3BsYXlpbmcgYQ0KdGVt cG9yYXJ5IGJ1ZmZlci4gIEl0IGNhbiBhbHNvIGJlIGEgZnVuY3Rpb24gdG8gYmUgY2FsbGVk IHRvDQpjaG9vc2UgdGhlIGhlaWdodCBmb3Igc3VjaCBhIGJ1ZmZlci4gIEl0IGdldHMgb25l IGFyZ3VtZW50LCB0aGUNCmJ1ZmZlciwgYW5kIHNob3VsZCByZXR1cm4gYSBwb3NpdGl2ZSBp bnRlZ2VyLiAgQXQgdGhlIHRpbWUgdGhlDQpmdW5jdGlvbiBpcyBjYWxsZWQsIHRoZSB3aW5k b3cgdG8gYmUgcmVzaXplZCBpcyBzZWxlY3RlZC4iDQogIDp0eXBlICcoY2hvaWNlIGludGVn ZXIgZnVuY3Rpb24pDQogIDpncm91cCAnaGVscA0KICA6dmVyc2lvbiAiMjQuMiIpDQoNCihk ZWZjdXN0b20gdGVtcC1idWZmZXItcmVzaXplLWZyYW1lcyBuaWwNCiAgIk5vbi1uaWwgbWVh bnMgYHRlbXAtYnVmZmVyLXJlc2l6ZS1tb2RlJyBjYW4gcmVzaXplIGZyYW1lcy4NCkEgZnJh bWUgY2FuIGJlIHJlc2l6ZWQgaWYgYW5kIG9ubHkgaWYgaXRzIHJvb3Qgd2luZG93IGlzIGEg bGl2ZQ0Kd2luZG93LiAgVGhlIGhlaWdodCBvZiB0aGUgcm9vdCB3aW5kb3cgaXMgc3ViamVj dCB0byB0aGUgdmFsdWVzIG9mDQpgdGVtcC1idWZmZXItbWF4LWhlaWdodCcgYW5kIGB3aW5k b3ctbWluLWhlaWdodCcuIg0KICA6dHlwZSAnYm9vbGVhbg0KICA6dmVyc2lvbiAiMjQuMiIN CiAgOmdyb3VwICdoZWxwKQ0KDQooZGVmaW5lLW1pbm9yLW1vZGUgdGVtcC1idWZmZXItcmVz aXplLW1vZGUNCiAgIlRvZ2dsZSBhdXRvLXNocmlua2luZyB0ZW1wIGJ1ZmZlciB3aW5kb3dz IChUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSkuDQpXaXRoIGEgcHJlZml4IGFyZ3VtZW50IEFS RywgZW5hYmxlIFRlbXAgQnVmZmVyIFJlc2l6ZSBtb2RlIGlmIEFSRw0KaXMgcG9zaXRpdmUs IGFuZCBkaXNhYmxlIGl0IG90aGVyd2lzZS4gIElmIGNhbGxlZCBmcm9tIExpc3AsDQplbmFi bGUgdGhlIG1vZGUgaWYgQVJHIGlzIG9taXR0ZWQgb3IgbmlsLg0KDQpXaGVuIFRlbXAgQnVm ZmVyIFJlc2l6ZSBtb2RlIGlzIGVuYWJsZWQsIHRoZSB3aW5kb3dzIGluIHdoaWNoIHdlDQpz aG93IGEgdGVtcG9yYXJ5IGJ1ZmZlciBhcmUgYXV0b21hdGljYWxseSByZWR1Y2VkIGluIGhl aWdodCB0bw0KZml0IHRoZSBidWZmZXIncyBjb250ZW50cywgYnV0IG5ldmVyIG1vcmUgdGhh bg0KYHRlbXAtYnVmZmVyLW1heC1oZWlnaHQnIG5vciBsZXNzIHRoYW4gYHdpbmRvdy1taW4t aGVpZ2h0Jy4NCg0KVGhpcyBtb2RlIGlzIHVzZWQgYnkgYGhlbHAnLCBgYXByb3BvcycgYW5k IGBjb21wbGV0aW9uJyBidWZmZXJzLA0KYW5kIHNvbWUgb3RoZXJzLiINCiAgOmdsb2JhbCB0 IDpncm91cCAnaGVscA0KICAoaWYgdGVtcC1idWZmZXItcmVzaXplLW1vZGUNCiAgICAgIDs7 IGBoZWxwLW1ha2UteHJlZnMnIG1heSBhZGQgYSBgYmFjaycgYnV0dG9uIGFuZCB0aHVzIGlu Y3JlYXNlIHRoZQ0KICAgICAgOzsgdGV4dCBzaXplLCBzbyBgcmVzaXplLXRlbXAtYnVmZmVy LXdpbmRvdycgbXVzdCBiZSBydW4gKmFmdGVyKiBpdC4NCiAgICAgIChhZGQtaG9vayAndGVt cC1idWZmZXItc2hvdy1ob29rICdyZXNpemUtdGVtcC1idWZmZXItd2luZG93ICdhcHBlbmQp DQogICAgKHJlbW92ZS1ob29rICd0ZW1wLWJ1ZmZlci1zaG93LWhvb2sgJ3Jlc2l6ZS10ZW1w LWJ1ZmZlci13aW5kb3cpKSkNCg0KKGRlZnVuIHJlc2l6ZS10ZW1wLWJ1ZmZlci13aW5kb3cg KCZvcHRpb25hbCB3aW5kb3cpDQogICJSZXNpemUgV0lORE9XIHRvIGZpdCBpdHMgY29udGVu dHMuDQpXSU5ET1cgY2FuIGJlIGFueSBsaXZlIHdpbmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhl IHNlbGVjdGVkIG9uZS4NCg0KRG8gbm90IG1ha2UgV0lORE9XIGhpZ2hlciB0aGFuIGB0ZW1w LWJ1ZmZlci1tYXgtaGVpZ2h0JyBub3INCnNtYWxsZXIgdGhhbiBgd2luZG93LW1pbi1oZWln aHQnLiAgRG8gbm90aGluZyBpZiB0aGUgc2VsZWN0ZWQNCndpbmRvdyBpcyBub3QgdmVydGlj YWxseSBjb21iaW5lZCBvciBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUNCnNjcm9sbGVkIG91 dCBvZiB2aWV3LiINCiAgKHNldHEgd2luZG93ICh3aW5kb3ctbm9ybWFsaXplLXdpbmRvdyB3 aW5kb3cgdCkpDQogIChsZXQgKChoZWlnaHQgKGlmIChmdW5jdGlvbnAgdGVtcC1idWZmZXIt bWF4LWhlaWdodCkNCgkJICAgIChmdW5jYWxsIHRlbXAtYnVmZmVyLW1heC1oZWlnaHQgKHdp bmRvdy1idWZmZXIgd2luZG93KSkNCgkJICB0ZW1wLWJ1ZmZlci1tYXgtaGVpZ2h0KSkpDQog ICAgKGNvbmQNCiAgICAgKChhbmQgKHBvcy12aXNpYmxlLWluLXdpbmRvdy1wIChwb2ludC1t aW4pIHdpbmRvdykNCgkgICAod2luZG93LWNvbWJpbmVkLXAgd2luZG93KSkNCiAgICAgIChm aXQtd2luZG93LXRvLWJ1ZmZlciB3aW5kb3cgaGVpZ2h0KSkNCiAgICAgKChhbmQgdGVtcC1i dWZmZXItcmVzaXplLWZyYW1lcw0KCSAgIChlcSB3aW5kb3cgKGZyYW1lLXJvb3Qtd2luZG93 IHdpbmRvdykpDQoJICAgKG1lbXEgKGNhciAod2luZG93LXBhcmFtZXRlciB3aW5kb3cgJ3F1 aXQtcmVzdG9yZSkpDQoJCSA7OyBJZiAnc2FtZSBpcyB0b28gc3Ryb25nLCB3ZSBtaWdodCBh ZGRpdGlvbmFsbHkgY2hlY2sNCgkJIDs7IHdoZXRoZXIgdGhlIHNlY29uZCBlbGVtZW50IGlz ICdmcmFtZS4NCgkJICcoc2FtZSBmcmFtZSkpKQ0KICAgICAgKGxldCAoKGZyYW1lICh3aW5k b3ctZnJhbWUgd2luZG93KSkpDQoJKGZpdC1mcmFtZS10by1idWZmZXINCgkgZnJhbWUgKCsg KGZyYW1lLWhlaWdodCBmcmFtZSkNCgkJICAoLSAod2luZG93LXRvdGFsLXNpemUgd2luZG93 KSkNCgkJICBoZWlnaHQpKSkpKSkpDQoNCihkZWZ2YXIgdGVtcC1idWZmZXItd2luZG93LXNl dHVwLWhvb2sgbmlsDQogICJOb3JtYWwgaG9vayBydW4gYnkgYHdpdGgtdGVtcC1idWZmZXIt d2luZG93JyBiZWZvcmUgYnVmZmVyIGRpc3BsYXkuDQpUaGlzIGhvb2sgaXMgcnVuIGJ5IGB3 aXRoLXRlbXAtYnVmZmVyLXdpbmRvdycgd2l0aCB0aGUgYnVmZmVyIHRvIGJlDQpkaXNwbGF5 ZWQgY3VycmVudC4iKQ0KDQooZGVmdmFyIHRlbXAtYnVmZmVyLXdpbmRvdy1zaG93LWhvb2sg bmlsDQogICJOb3JtYWwgaG9vayBydW4gYnkgYHdpdGgtdGVtcC1idWZmZXItd2luZG93JyBh ZnRlciBidWZmZXIgZGlzcGxheS4NClRoaXMgaG9vayBpcyBydW4gYnkgYHdpdGgtdGVtcC1i dWZmZXItd2luZG93JyB3aXRoIHRoZSBidWZmZXINCmRpc3BsYXllZCBhbmQgY3VycmVudCBh bmQgaXRzIHdpbmRvdyBzZWxlY3RlZC4iKQ0KDQooZGVmdW4gdGVtcC1idWZmZXItd2luZG93 LXNldHVwIChidWZmZXItb3ItbmFtZSkNCiAgIlNldCB1cCB0ZW1wb3JhcnkgYnVmZmVyIHNw ZWNpZmllZCBieSBCVUZGRVItT1ItTkFNRSANClJldHVybiB0aGUgYnVmZmVyLiINCiAgKGxl dCAoKG9sZC1kaXIgZGVmYXVsdC1kaXJlY3RvcnkpDQoJKGJ1ZmZlciAoZ2V0LWJ1ZmZlci1j cmVhdGUgYnVmZmVyLW9yLW5hbWUpKSkNCiAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciBidWZm ZXINCiAgICAgIChraWxsLWFsbC1sb2NhbC12YXJpYWJsZXMpDQogICAgICAoc2V0cSBkZWZh dWx0LWRpcmVjdG9yeSBvbGQtZGlyKQ0KOzsgICAgICAgKGRlbGV0ZS1hbGwtb3ZlcmxheXMp DQogICAgICAoc2V0cSBidWZmZXItcmVhZC1vbmx5IG5pbCkNCiAgICAgIChzZXRxIGJ1ZmZl ci1maWxlLW5hbWUgbmlsKQ0KICAgICAgKHNldHEgYnVmZmVyLXVuZG8tbGlzdCB0KQ0KICAg ICAgKGxldCAoKGluaGliaXQtcmVhZC1vbmx5IHQpDQoJICAgIChpbmhpYml0LW1vZGlmaWNh dGlvbi1ob29rcyB0KSkNCgkoZXJhc2UtYnVmZmVyKQ0KCShydW4taG9va3MgJ3RlbXAtYnVm ZmVyLXdpbmRvdy1zZXR1cC1ob29rKSkNCiAgICAgIDs7IFJldHVybiB0aGUgYnVmZmVyLg0K ICAgICAgYnVmZmVyKSkpDQoNCihkZWZ1biB0ZW1wLWJ1ZmZlci13aW5kb3ctc2hvdyAoJm9w dGlvbmFsIGJ1ZmZlcikNCiAgIlNob3cgdGVtcG9yYXJ5IGJ1ZmZlciBCVUZGRVIgaW4gYSB3 aW5kb3cuDQpSZXR1cm4gdGhlIHdpbmRvdyBzaG93aW5nIEJVRkZFUi4iDQogIChsZXQgKHdp bmRvdyBmcmFtZSkNCiAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciBidWZmZXINCiAgICAgIChz ZXQtYnVmZmVyLW1vZGlmaWVkLXAgbmlsKQ0KICAgICAgKHNldHEgYnVmZmVyLXJlYWQtb25s eSB0KQ0KICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkNCiAgICAgICh3aGVuIChzZXRx IHdpbmRvdyAoZGlzcGxheS1idWZmZXIgYnVmZmVyKSkNCgkoc2V0cSBmcmFtZSAod2luZG93 LWZyYW1lIHdpbmRvdykpDQoJKHVubGVzcyAoZXEgZnJhbWUgKHNlbGVjdGVkLWZyYW1lKSkN CgkgIChyYWlzZS1mcmFtZSBmcmFtZSkpDQoJKHNldHEgbWluaWJ1ZmZlci1zY3JvbGwtd2lu ZG93IHdpbmRvdykNCgkoc2V0LXdpbmRvdy1oc2Nyb2xsIHdpbmRvdyAwKQ0KCSh3aXRoLXNl bGVjdGVkLXdpbmRvdyB3aW5kb3cNCgkgIChydW4taG9va3MgJ3RlbXAtYnVmZmVyLXdpbmRv dy1zaG93LWhvb2spDQoJICAod2hlbiB0ZW1wLWJ1ZmZlci1yZXNpemUtbW9kZQ0KCSAgICAo cmVzaXplLXRlbXAtYnVmZmVyLXdpbmRvdyB3aW5kb3cpKSkNCgk7OyBSZXR1cm4gdGhlIHdp bmRvdy4NCgl3aW5kb3cpKSkpDQoNCihkZWZtYWNybyB3aXRoLXRlbXAtYnVmZmVyLXdpbmRv dyAoYnVmZmVyLW9yLW5hbWUgcXVpdC1mdW5jdGlvbiAmcmVzdCBib2R5KQ0KICAiRXZhbHVh dGUgQk9EWSBhbmQgZGlzcGxheSBidWZmZXIgc3BlY2lmaWVkIGJ5IEJVRkZFUi1PUi1OQU1F Lg0KQlVGRkVSLU9SLU5BTUUgbXVzdCBzcGVjaWZ5IGVpdGhlciBhIGxpdmUgYnVmZmVyIG9y IHRoZSBuYW1lIG9mIGENCmJ1ZmZlci4gIElmIG5vIGJ1ZmZlciB3aXRoIHN1Y2ggYSBuYW1l IGV4aXN0cywgY3JlYXRlIG9uZS4NCg0KTWFrZSBzdXJlIHRoZSBzcGVjaWZpZWQgYnVmZmVy IGlzIGVtcHR5IGJlZm9yZSBldmFsdWF0aW5nIEJPRFkuDQpEbyBub3QgbWFrZSB0aGF0IGJ1 ZmZlciBjdXJyZW50IGZvciBCT0RZLiAgSW5zdGVhZCwgYmluZA0KYHN0YW5kYXJkLW91dHB1 dCcgdG8gdGhhdCBidWZmZXIsIHNvIHRoYXQgb3V0cHV0IGdlbmVyYXRlZCB3aXRoDQpgcHJp bjEnIGFuZCBzaW1pbGFyIGZ1bmN0aW9ucyBpbiBCT0RZIGdvZXMgaW50byB0aGF0IGJ1ZmZl ci4NCg0KQWZ0ZXIgZXZhbHVhdGluZyBCT0RZLCBtYXJrIHRoZSBzcGVjaWZpZWQgYnVmZmVy IHVubW9kaWZpZWQgYW5kDQpyZWFkLW9ubHkgYW5kIGRpc3BsYXkgaXQgaW4gYSB3aW5kb3cu ICBBdXRvLXNocmluayB0aGUgd2luZG93IGlmDQpgdGVtcC1idWZmZXItcmVzaXplLW1vZGUn IGlzIGVuYWJsZWQuDQoNClJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgQk9EWSB1bmxl c3MgUVVJVC1GVU5DVElPTiBzcGVjaWZpZXMNCmEgZnVuY3Rpb24uICBJbiB0aGF0IGNhc2Us IHJ1biB0aGUgZnVuY3Rpb24gd2l0aCB0d28gYXJndW1lbnRzIC0NCnRoZSB3aW5kb3cgc2hv d2luZyB0aGUgc3BlY2lmaWVkIGJ1ZmZlciBhbmQgdGhlIHZhbHVlIHJldHVybmVkIGJ5DQpC T0RZIC0gYW5kIHJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgdGhhdCBmdW5jdGlvbi4N Cg0KVGhpcyBjb25zdHJ1Y3QgaXMgc2ltaWxhciB0byBgd2l0aC1vdXRwdXQtdG8tdGVtcC1i dWZmZXInIGJ1dA0KZG9lcyBuZWl0aGVyIHB1dCB0aGUgYnVmZmVyIGluIGhlbHAgbW9kZSBu b3IgZG9lcyBpdCBjYWxsDQpgdGVtcC1idWZmZXItc2hvdy1mdW5jdGlvbicuICBJdCBhbHNv IHJ1bnMgZGlmZmVyZW50IGhvb2tzLA0KbmFtZWx5IGB0ZW1wLWJ1ZmZlci13aW5kb3ctc2V0 dXAtaG9vaycgKHdpdGggdGhlIHNwZWNpZmllZCBidWZmZXINCmN1cnJlbnQpIGFuZCBgdGVt cC1idWZmZXItd2luZG93LXNob3ctaG9vaycgKHdpdGggdGhlIHNwZWNpZmllZA0KYnVmZmVy IGN1cnJlbnQgYW5kIHRoZSB3aW5kb3cgc2hvd2luZyBpdCBzZWxlY3RlZCkuDQoNClNpbmNl IHRoaXMgbWFjcm8gY2FsbHMgYGRpc3BsYXktYnVmZmVyJywgdGhlIHdpbmRvdyBkaXNwbGF5 aW5nDQp0aGUgYnVmZmVyIGlzIHVzdWFsbHkgbm90IHNlbGVjdGVkIGFuZCB0aGUgc3BlY2lm aWVkIGJ1ZmZlcg0KdXN1YWxseSBub3QgbWFkZSBjdXJyZW50LiAgUVVJVC1GVU5DVElPTiBj YW4gb3ZlcnJpZGUgdGhhdC4iDQogIChkZWNsYXJlIChkZWJ1ZyB0KSkNCiAgKGxldCAoKGJ1 ZmZlciAobWFrZS1zeW1ib2wgImJ1ZmZlciIpKQ0KCShzZWxlY3RlZCAobWFrZS1zeW1ib2wg InNlbGVjdGVkIikpDQoJKHdpbmRvdyAobWFrZS1zeW1ib2wgIndpbmRvdyIpKQ0KCSh2YWx1 ZSAobWFrZS1zeW1ib2wgInZhbHVlIikpKQ0KICAgIGAobGV0KiAoKCxidWZmZXIgKHRlbXAt YnVmZmVyLXdpbmRvdy1zZXR1cCAsYnVmZmVyLW9yLW5hbWUpKQ0KCSAgICAoc3RhbmRhcmQt b3V0cHV0ICxidWZmZXIpDQoJICAgICgsc2VsZWN0ZWQgKHNlbGVjdGVkLXdpbmRvdykpDQoJ ICAgICx3aW5kb3cgLHZhbHVlKQ0KICAgICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyICxidWZm ZXINCgkgKHNldHEgLHZhbHVlIChwcm9nbiAsQGJvZHkpKQ0KCSAoc2V0cSAsd2luZG93ICh0 ZW1wLWJ1ZmZlci13aW5kb3ctc2hvdyAsYnVmZmVyKSkpDQoNCiAgICAgICAoaWYgKGZ1bmN0 aW9ucCAscXVpdC1mdW5jdGlvbikNCgkgICAod2l0aC1zZWxlY3RlZC13aW5kb3cgLHNlbGVj dGVkDQoJICAgICAoc2VsZWN0LWZyYW1lLXNldC1pbnB1dC1mb2N1cyAod2luZG93LWZyYW1l ICxzZWxlY3RlZCkpDQoJICAgICAoZnVuY2FsbCAscXVpdC1mdW5jdGlvbiAsd2luZG93ICx2 YWx1ZSkpDQoJICx2YWx1ZSkpKSkNCg0KKGRlZnVuIHdpbmRvdy0tZGlzcGxheS1idWZmZXIg KGJ1ZmZlciB3aW5kb3cgdHlwZSAmb3B0aW9uYWwgZGVkaWNhdGVkKQ0KICAiRGlzcGxheSBC VUZGRVIgaW4gV0lORE9XIGFuZCBtYWtlIGl0cyBmcmFtZSB2aXNpYmxlLg0KVFlQRSBtdXN0 IGJlIG9uZSBvZiB0aGUgc3ltYm9scyBgcmV1c2UnLCBgd2luZG93JyBvciBgZnJhbWUnIGFu ZA0KaXMgcGFzc2VkIHVuYWx0ZXJlZCB0byBgZGlzcGxheS1idWZmZXItcmVjb3JkLXdpbmRv dycuIFNldA0KYHdpbmRvdy1kZWRpY2F0ZWQtcCcgdG8gREVESUNBVEVEIGlmIG5vbi1uaWwu ICBSZXR1cm4gV0lORE9XIGlmDQpCVUZGRVIgYW5kIFdJTkRPVyBhcmUgbGl2ZS4iDQogICh3 aGVuIChhbmQgKGJ1ZmZlci1saXZlLXAgYnVmZmVyKSAod2luZG93LWxpdmUtcCB3aW5kb3cp KQ0KICAgIChsZXQqICgoZnJhbWUgKHdpbmRvdy1mcmFtZSB3aW5kb3cpKQ0KCSAgICh2aXNp YmxlIChmcmFtZS12aXNpYmxlLXAgZnJhbWUpKSkNCiAgICAgIChkaXNwbGF5LWJ1ZmZlci1y ZWNvcmQtd2luZG93IHR5cGUgd2luZG93IGJ1ZmZlcikNCiAgICAgICh1bmxlc3MgKGVxIGJ1 ZmZlciAod2luZG93LWJ1ZmZlciB3aW5kb3cpKQ0KCShzZXQtd2luZG93LWRlZGljYXRlZC1w IHdpbmRvdyBuaWwpDQoJKHNldC13aW5kb3ctYnVmZmVyIHdpbmRvdyBidWZmZXIpDQoJKHdo ZW4gZGVkaWNhdGVkDQoJICAoc2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCB3aW5kb3cgZGVkaWNh dGVkKSkpDQogICAgICAod2hlbiAobWVtcSB0eXBlICcod2luZG93IGZyYW1lKSkNCgkoc2V0 LXdpbmRvdy1wcmV2LWJ1ZmZlcnMgd2luZG93IG5pbCkpDQoNCiAgICAgICh1bmxlc3MgKG9y IChub3QgdmlzaWJsZSkNCgkJICA7OyBBc3N1bWUgdGhlIHNlbGVjdGVkIGZyYW1lIGlzIGFs cmVhZHkgdmlzaWJsZSBlbm91Z2guDQoJCSAgKGVxIGZyYW1lIChzZWxlY3RlZC1mcmFtZSkp DQoJCSAgOzsgQXNzdW1lIHRoZSBmcmFtZSBmcm9tIHdoaWNoIHdlIGludm9rZWQgdGhlIG1p bmlidWZmZXINCgkJICA7OyBpcyB2aXNpYmxlLg0KCQkgIChhbmQgKG1pbmlidWZmZXItd2lu ZG93LWFjdGl2ZS1wIChzZWxlY3RlZC13aW5kb3cpKQ0KCQkgICAgICAgKGVxIGZyYW1lICh3 aW5kb3ctZnJhbWUgKG1pbmlidWZmZXItc2VsZWN0ZWQtd2luZG93KSkpKSkNCgkocmFpc2Ut ZnJhbWUgZnJhbWUpKQ0KDQogICAgICB3aW5kb3cpKSkNCg0KKGRlZnVuIHF1aXQtcmVzdG9y ZS13aW5kb3cgKCZvcHRpb25hbCB3aW5kb3cgYnVyeS1vci1raWxsKQ0KICAiUXVpdCBXSU5E T1cgYW5kIGRlYWwgd2l0aCBpdHMgYnVmZmVyLg0KV0lORE9XIG11c3QgYmUgYSBsaXZlIHdp bmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhlIHNlbGVjdGVkIG9uZS4NCg0KQWNjb3JkaW5nIHRv IGluZm9ybWF0aW9uIHN0b3JlZCBpbiBXSU5ET1cncyBgcXVpdC1yZXN0b3JlJyB3aW5kb3cN CnBhcmFtZXRlciBlaXRoZXIgKDEpIGRlbGV0ZSBXSU5ET1cgYW5kIGl0cyBmcmFtZSwgKDIp IGRlbGV0ZQ0KV0lORE9XLCAoMykgcmVzdG9yZSB0aGUgYnVmZmVyIHByZXZpb3VzbHkgZGlz cGxheWVkIGluIFdJTkRPVywNCm9yICg0KSBtYWtlIFdJTkRPVyBkaXNwbGF5IHNvbWUgb3Ro ZXIgYnVmZmVyIHRoYW4gdGhlIHByZXNlbnQNCm9uZS4gIElmIG5vbi1uaWwsIHJlc2V0IGBx dWl0LXJlc3RvcmUnIHBhcmFtZXRlciB0byBuaWwuDQoNCk9wdGlvbmFsIHNlY29uZCBhcmd1 bWVudCBCVVJZLU9SLUtJTEwgdGVsbHMgaG93IHRvIHByb2NlZWQgd2l0aA0KdGhlIGJ1ZmZl ciBvZiBXSU5ET1cuICBUaGUgZm9sbG93aW5nIHZhbHVlcyBhcmUgaGFuZGxlZDoNCg0KYG5p bCcgbWVhbnMgdG8gbm90IGhhbmRsZSB0aGUgYnVmZmVyIGluIGEgcGFydGljdWxhciB3YXku ICBUaGlzDQogIG1lYW5zIHRoYXQgaWYgV0lORE9XIGlzIG5vdCBkZWxldGVkIGJ5IHRoaXMg ZnVuY3Rpb24sIGludm9raW5nDQogIGBzd2l0Y2gtdG8tcHJldi1idWZmZXInIHdpbGwgdXN1 YWxseSBzaG93IHRoZSBidWZmZXIgYWdhaW4uDQoNCmBhcHBlbmQnIG1lYW5zIHRoYXQgaWYg V0lORE9XIGlzIG5vdCBkZWxldGVkLCBtb3ZlIGl0cyBidWZmZXIgdG8NCiAgdGhlIGVuZCBv ZiBXSU5ET1cncyBwcmV2aW91cyBidWZmZXJzIHNvIGl0J3MgbGVzcyBsaWtlbHkgdGhhdCBh DQogIGZ1dHVyZSBpbnZvY2F0aW9uIG9mIGBzd2l0Y2gtdG8tcHJldi1idWZmZXInIHdpbGwg c3dpdGNoIHRvIGl0Lg0KICBBbHNvLCBtb3ZlIHRoZSBidWZmZXIgdG8gdGhlIGVuZCBvZiB0 aGUgZnJhbWUncyBidWZmZXIgbGlzdC4NCg0KYGJ1cnknIG1lYW5zIHRoYXQgaWYgV0lORE9X IGlzIG5vdCBkZWxldGVkLCByZW1vdmUgaXRzIGJ1ZmZlcg0KICBmcm9tIFdJTkRPVydTIGxp c3Qgb2YgcHJldmlvdXMgYnVmZmVycy4gIEFsc28sIG1vdmUgdGhlIGJ1ZmZlcg0KICB0byB0 aGUgZW5kIG9mIHRoZSBmcmFtZSdzIGJ1ZmZlciBsaXN0LiAgVGhpcyB2YWx1ZSBwcm92aWRl cyB0aGUNCiAgbW9zdCByZWxpYWJsZSByZW1lZHkgdG8gbm90IGhhdmUgYHN3aXRjaC10by1w cmV2LWJ1ZmZlcicgc3dpdGNoDQogIHRvIHRoaXMgYnVmZmVyIGFnYWluIHdpdGhvdXQga2ls bGluZyB0aGUgYnVmZmVyLg0KDQpga2lsbCcgbWVhbnMgdG8ga2lsbCBXSU5ET1cncyBidWZm ZXIuIg0KICAoc2V0cSB3aW5kb3cgKHdpbmRvdy1ub3JtYWxpemUtd2luZG93IHdpbmRvdyB0 KSkNCiAgKGxldCogKChidWZmZXIgKHdpbmRvdy1idWZmZXIgd2luZG93KSkNCgkgKHF1aXQt cmVzdG9yZSAod2luZG93LXBhcmFtZXRlciB3aW5kb3cgJ3F1aXQtcmVzdG9yZSkpDQoJIChw cmV2LWJ1ZmZlcg0KCSAgKGxldCogKChwcmV2LWJ1ZmZlcnMgKHdpbmRvdy1wcmV2LWJ1ZmZl cnMgd2luZG93KSkNCgkJIChwcmV2LWJ1ZmZlciAoY2FhciBwcmV2LWJ1ZmZlcnMpKSkNCgkg ICAgKGFuZCAob3IgKG5vdCAoZXEgcHJldi1idWZmZXIgYnVmZmVyKSkNCgkJICAgICAoYW5k IChjZHIgcHJldi1idWZmZXJzKQ0KCQkJICAobm90IChlcSAoc2V0cSBwcmV2LWJ1ZmZlciAo Y2FkciBwcmV2LWJ1ZmZlcnMpKQ0KCQkJCSAgIGJ1ZmZlcikpKSkNCgkJIHByZXYtYnVmZmVy KSkpDQoJIHF1YWQgZW50cnkpDQogICAgKGNvbmQNCiAgICAgKChhbmQgKG5vdCBwcmV2LWJ1 ZmZlcikNCgkgICAobWVtcSAobnRoIDEgcXVpdC1yZXN0b3JlKSAnKHdpbmRvdyBmcmFtZSkp DQoJICAgKGVxIChudGggMyBxdWl0LXJlc3RvcmUpIGJ1ZmZlcikNCgkgICA7OyBEZWxldGUg V0lORE9XIGlmIHBvc3NpYmxlLg0KCSAgICh3aW5kb3ctLWRlbGV0ZSB3aW5kb3cgbmlsIChl cSBidXJ5LW9yLWtpbGwgJ2tpbGwpKSkNCiAgICAgIDs7IElmIHRoZSBwcmV2aW91c2x5IHNl bGVjdGVkIHdpbmRvdyBpcyBzdGlsbCBhbGl2ZSwgc2VsZWN0IGl0Lg0KICAgICAgKHdoZW4g KHdpbmRvdy1saXZlLXAgKG50aCAyIHF1aXQtcmVzdG9yZSkpDQoJKHNlbGVjdC13aW5kb3cg KG50aCAyIHF1aXQtcmVzdG9yZSkpKSkNCiAgICAgKChhbmQgKGxpc3RwIChzZXRxIHF1YWQg KG50aCAxIHF1aXQtcmVzdG9yZSkpKQ0KCSAgIChidWZmZXItbGl2ZS1wIChjYXIgcXVhZCkp DQoJICAgKGVxIChudGggMyBxdWl0LXJlc3RvcmUpIGJ1ZmZlcikpDQogICAgICA7OyBTaG93 IGFub3RoZXIgYnVmZmVyIHN0b3JlZCBpbiBxdWl0LXJlc3RvcmUgcGFyYW1ldGVyLg0KICAg ICAgKHdoZW4gKGFuZCAoaW50ZWdlcnAgKG50aCAzIHF1YWQpKQ0KCQkgKC89IChudGggMyBx dWFkKSAod2luZG93LXRvdGFsLXNpemUgd2luZG93KSkpDQoJOzsgVHJ5IHRvIHJlc2l6ZSBX SU5ET1cgdG8gaXRzIG9sZCBoZWlnaHQgYnV0IGRvbid0IHNpZ25hbCBhbg0KCTs7IGVycm9y Lg0KCShjb25kaXRpb24tY2FzZSBuaWwNCgkgICAgKHdpbmRvdy1yZXNpemUgd2luZG93ICgt IChudGggMyBxdWFkKSAod2luZG93LXRvdGFsLXNpemUgd2luZG93KSkpDQoJICAoZXJyb3Ig bmlsKSkpDQogICAgICAoc2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCB3aW5kb3cgbmlsKQ0KICAg ICAgOzsgUmVzdG9yZSBXSU5ET1cncyBwcmV2aW91cyBidWZmZXIsIHN0YXJ0IGFuZCBwb2lu dCBwb3NpdGlvbi4NCiAgICAgIChzZXQtd2luZG93LWJ1ZmZlci1zdGFydC1hbmQtcG9pbnQN CiAgICAgICB3aW5kb3cgKG50aCAwIHF1YWQpIChudGggMSBxdWFkKSAobnRoIDIgcXVhZCkp DQogICAgICA7OyBEZWFsIHdpdGggdGhlIGJ1ZmZlciB3ZSBqdXN0IHJlbW92ZWQgZnJvbSBX SU5ET1cuDQogICAgICAoc2V0cSBlbnRyeSAoYW5kIChlcSBidXJ5LW9yLWtpbGwgJ2FwcGVu ZCkNCgkJICAgICAgIChhc3NxIGJ1ZmZlciAod2luZG93LXByZXYtYnVmZmVycyB3aW5kb3cp KSkpDQogICAgICAod2hlbiBidXJ5LW9yLWtpbGwNCgk7OyBSZW1vdmUgYnVmZmVyIGZyb20g V0lORE9XJ3MgcHJldmlvdXMgYW5kIG5leHQgYnVmZmVycy4NCgkoc2V0LXdpbmRvdy1wcmV2 LWJ1ZmZlcnMNCgkgd2luZG93IChhc3NxLWRlbGV0ZS1hbGwgYnVmZmVyICh3aW5kb3ctcHJl di1idWZmZXJzIHdpbmRvdykpKQ0KCShzZXQtd2luZG93LW5leHQtYnVmZmVycw0KCSB3aW5k b3cgKGRlbHEgYnVmZmVyICh3aW5kb3ctbmV4dC1idWZmZXJzIHdpbmRvdykpKSkNCiAgICAg ICh3aGVuIGVudHJ5DQoJOzsgQXBwZW5kIG9sZCBidWZmZXIncyBlbnRyeSB0byBsaXN0IG9m IFdJTkRPVydzIHByZXZpb3VzDQoJOzsgYnVmZmVycyBzbyBpdCdzIGxlc3MgbGlrZWx5IHRv IGdldCBzd2l0Y2hlZCB0byBzb29uIGJ1dA0KCTs7IGBkaXNwbGF5LWJ1ZmZlci1pbi1wcmV2 aW91cy13aW5kb3cnIGNhbiBuZXZlcnRoZWxlc3MgZmluZCBpdC4NCgkoc2V0LXdpbmRvdy1w cmV2LWJ1ZmZlcnMNCgkgd2luZG93IChhcHBlbmQgKHdpbmRvdy1wcmV2LWJ1ZmZlcnMgd2lu ZG93KSAobGlzdCBlbnRyeSkpKSkNCiAgICAgIDs7IFJlc2V0IHRoZSBxdWl0LXJlc3RvcmUg cGFyYW1ldGVyLg0KICAgICAgKHNldC13aW5kb3ctcGFyYW1ldGVyIHdpbmRvdyAncXVpdC1y ZXN0b3JlIG5pbCkNCiAgICAgIDs7IFNlbGVjdCBvbGQgd2luZG93Lg0KICAgICAgKHdoZW4g KHdpbmRvdy1saXZlLXAgKG50aCAyIHF1aXQtcmVzdG9yZSkpDQoJKHNlbGVjdC13aW5kb3cg KG50aCAyIHF1aXQtcmVzdG9yZSkpKSkNCiAgICAgKHQNCiAgICAgIDs7IFNob3cgc29tZSBv dGhlciBidWZmZXIgaW4gV0lORE9XIGFuZCByZXNldCB0aGUgcXVpdC1yZXN0b3JlDQogICAg ICA7OyBwYXJhbWV0ZXIuDQogICAgICAoc2V0LXdpbmRvdy1wYXJhbWV0ZXIgd2luZG93ICdx dWl0LXJlc3RvcmUgbmlsKQ0KICAgICAgOzsgTWFrZSBzdXJlIHRoYXQgV0lORE9XIGlzIG5v IG1vcmUgZGVkaWNhdGVkLg0KICAgICAgKHNldC13aW5kb3ctZGVkaWNhdGVkLXAgd2luZG93 IG5pbCkNCiAgICAgIChzd2l0Y2gtdG8tcHJldi1idWZmZXIgd2luZG93IGJ1cnktb3Ita2ls bCkpKQ0KDQogICAgOzsgRGVhbCB3aXRoIHRoZSBidWZmZXIuDQogICAgKGNvbmQNCiAgICAg KChub3QgKGJ1ZmZlci1saXZlLXAgYnVmZmVyKSkpDQogICAgICgoZXEgYnVyeS1vci1raWxs ICdraWxsKQ0KICAgICAgKGtpbGwtYnVmZmVyIGJ1ZmZlcikpDQogICAgIChidXJ5LW9yLWtp bGwNCiAgICAgIChidXJ5LWJ1ZmZlci1pbnRlcm5hbCBidWZmZXIpKSkpKQ0KDQooZGVmdW4g cXVpdC13aW5kb3cgKCZvcHRpb25hbCBraWxsIHdpbmRvdykNCiAgIlF1aXQgV0lORE9XIGFu ZCBidXJ5IGl0cyBidWZmZXIuDQpXSU5ET1cgbXVzdCBiZSBhIGxpdmUgd2luZG93IGFuZCBk ZWZhdWx0cyB0byB0aGUgc2VsZWN0ZWQgb25lLg0KV2l0aCBwcmVmaXggYXJndW1lbnQgS0lM TCBub24tbmlsLCBraWxsIHRoZSBidWZmZXIgaW5zdGVhZCBvZg0KYnVyeWluZyBpdC4NCg0K QWNjb3JkaW5nIHRvIGluZm9ybWF0aW9uIHN0b3JlZCBpbiBXSU5ET1cncyBgcXVpdC1yZXN0 b3JlJyB3aW5kb3cNCnBhcmFtZXRlciBlaXRoZXIgKDEpIGRlbGV0ZSBXSU5ET1cgYW5kIGl0 cyBmcmFtZSwgKDIpIGRlbGV0ZQ0KV0lORE9XLCAoMykgcmVzdG9yZSB0aGUgYnVmZmVyIHBy ZXZpb3VzbHkgZGlzcGxheWVkIGluIFdJTkRPVywNCm9yICg0KSBtYWtlIFdJTkRPVyBkaXNw bGF5IHNvbWUgb3RoZXIgYnVmZmVyIHRoYW4gdGhlIHByZXNlbnQNCm9uZS4gIElmIG5vbi1u aWwsIHJlc2V0IGBxdWl0LXJlc3RvcmUnIHBhcmFtZXRlciB0byBuaWwuIg0KICAoaW50ZXJh Y3RpdmUgIlAiKQ0KICAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgKGlmIGtpbGwgJ2tp bGwgJ2J1cnkpKSkNCg0KKGRlZmN1c3RvbSBmaXQtZnJhbWUtdG8tYnVmZmVyLWJvdHRvbS1t YXJnaW4gNA0KICAiQm90dG9tIG1hcmdpbiBmb3IgYGZpdC1mcmFtZS10by1idWZmZXInLg0K VGhpcyBpcyB0aGUgbnVtYmVyIG9mIGxpbmVzIGBmaXQtZnJhbWUtdG8tYnVmZmVyJyBsZWF2 ZXMgZnJlZSBhdCB0aGUNCmJvdHRvbSBvZiB0aGUgZGlzcGxheSBpbiBvcmRlciB0byBub3Qg b2JzY3VyZSB0aGUgc3lzdGVtIHRhc2sgYmFyLiINCiAgOnR5cGUgJ2ludGVnZXINCiAgOnZl cnNpb24gIjI0LjIiDQogIDpncm91cCAnd2luZG93cykNCg0KKGRlZnVuIGZpdC1mcmFtZS10 by1idWZmZXIgKCZvcHRpb25hbCBmcmFtZSBtYXgtaGVpZ2h0IG1pbi1oZWlnaHQpDQogICJB ZGp1c3QgaGVpZ2h0IG9mIEZSQU1FIHRvIGRpc3BsYXkgaXRzIGJ1ZmZlcidzIGNvbnRlbnRz IGV4YWN0bHkuDQpGUkFNRSBjYW4gYmUgYW55IGxpdmUgZnJhbWUgYW5kIGRlZmF1bHRzIHRv IHRoZSBzZWxlY3RlZCBvbmUuDQoNCk9wdGlvbmFsIGFyZ3VtZW50IE1BWC1IRUlHSFQgc3Bl Y2lmaWVzIHRoZSBtYXhpbXVtIGhlaWdodCBvZg0KRlJBTUUgYW5kIGRlZmF1bHRzIHRvIHRo ZSBoZWlnaHQgb2YgdGhlIGRpc3BsYXkgYmVsb3cgdGhlIGN1cnJlbnQNCnRvcCBsaW5lIG9m IEZSQU1FIG1pbnVzIEZJVC1GUkFNRS1UTy1CVUZGRVItQk9UVE9NLU1BUkdJTi4NCk9wdGlv bmFsIGFyZ3VtZW50IE1JTi1IRUlHSFQgc3BlY2lmaWVzIHRoZSBtaW5pbXVtIGhlaWdodCBv Zg0KRlJBTUUuIg0KICAoaW50ZXJhY3RpdmUpDQogIChzZXRxIGZyYW1lICh3aW5kb3ctbm9y bWFsaXplLWZyYW1lIGZyYW1lKSkNCiAgKGxldCogKChyb290IChmcmFtZS1yb290LXdpbmRv dyBmcmFtZSkpDQoJIChmcmFtZS1taW4taGVpZ2h0DQoJICAoKyAoLSAoZnJhbWUtaGVpZ2h0 IGZyYW1lKSAod2luZG93LXRvdGFsLXNpemUgcm9vdCkpDQoJICAgICB3aW5kb3ctbWluLWhl aWdodCkpDQoJIChmcmFtZS10b3AgKGZyYW1lLXBhcmFtZXRlciBmcmFtZSAndG9wKSkNCgkg KHRvcCAoaWYgKGNvbnNwIGZyYW1lLXRvcCkNCgkJICAoZnVuY2FsbCAoY2FyIGZyYW1lLXRv cCkgKGNhZHIgZnJhbWUtdG9wKSkNCgkJZnJhbWUtdG9wKSkNCgkgKGZyYW1lLW1heC1oZWln aHQNCgkgICgtICgvICgtICh4LWRpc3BsYXktcGl4ZWwtaGVpZ2h0IGZyYW1lKSB0b3ApDQoJ CShmcmFtZS1jaGFyLWhlaWdodCBmcmFtZSkpDQoJICAgICBmaXQtZnJhbWUtdG8tYnVmZmVy LWJvdHRvbS1tYXJnaW4pKQ0KCSBkZWx0YSkNCiAgICAod2hlbiAoYW5kICh3aW5kb3ctbGl2 ZS1wIHJvb3QpIChub3QgKHdpbmRvdy1zaXplLWZpeGVkLXAgcm9vdCkpKQ0KICAgICAgKHdp dGgtc2VsZWN0ZWQtd2luZG93IHJvb3QNCgkoY29uZA0KCSAoKG5vdCBtYXgtaGVpZ2h0KQ0K CSAgKHNldHEgbWF4LWhlaWdodCBmcmFtZS1tYXgtaGVpZ2h0KSkNCgkgKChudW1iZXJwIG1h eC1oZWlnaHQpDQoJICAoc2V0cSBtYXgtaGVpZ2h0IChtaW4gbWF4LWhlaWdodCBmcmFtZS1t YXgtaGVpZ2h0KSkpDQoJICh0DQoJICAoZXJyb3IgIiVzIGlzIGFuIGludmFsaWQgbWF4aW11 bSBoZWlnaHQiIG1heC1oZWlnaHQpKSkNCgkoY29uZA0KCSAoKG5vdCBtaW4taGVpZ2h0KQ0K CSAgKHNldHEgbWluLWhlaWdodCBmcmFtZS1taW4taGVpZ2h0KSkNCgkgKChudW1iZXJwIG1p bi1oZWlnaHQpDQoJICAoc2V0cSBtaW4taGVpZ2h0IChtaW4gbWluLWhlaWdodCBmcmFtZS1t aW4taGVpZ2h0KSkpDQoJICh0DQoJICAoZXJyb3IgIiVzIGlzIGFuIGludmFsaWQgbWluaW11 bSBoZWlnaHQiIG1pbi1oZWlnaHQpKSkNCgkoc2V0cSBkZWx0YQ0KCSAgICAgIDs7IENvdW50 IGEgZmluYWwgbmV3bGluZSAtIHRoaXMgY29tcGVuc2F0ZXMgZm9yIHRoZQ0KCSAgICAgIDs7 IG1pc3NpbmcgcG9zdC1wcm9jZXNpbmcgcGFydCBhZnRlciByZXNpemluZyB0aGUgZnJhbWUu DQoJICAgICAgKC0gKCsgKGNvdW50LXNjcmVlbi1saW5lcyBuaWwgbmlsIHQpDQoJCSAgICA7 OyBGb3Igbm9uLW1pbmlidWZmZXJzIGNvdW50IHRoZSBtb2RlIGxpbmUsIGlmIGFueS4NCgkJ ICAgIChpZiAoYW5kIChub3QgKHdpbmRvdy1taW5pYnVmZmVyLXApKQ0KCQkJICAgICBtb2Rl LWxpbmUtZm9ybWF0KQ0KCQkJMQ0KCQkgICAgICAwKQ0KCQkgICAgOzsgQ291bnQgdGhlIGhl YWRlciBsaW5lLCBpZiBhbnkuDQoJCSAgICAoaWYgaGVhZGVyLWxpbmUtZm9ybWF0IDEgMCkp DQoJCSAod2luZG93LXRvdGFsLXNpemUpKSkpDQogICAgICA7OyBNb3ZlIGF3YXkgZnJvbSBm aW5hbCBuZXdsaW5lLg0KICAgICAgKHdoZW4gKGFuZCAoZW9icCkgKGJvbHApIChub3QgKGJv YnApKSkNCgkoc2V0LXdpbmRvdy1wb2ludCByb290IChsaW5lLWJlZ2lubmluZy1wb3NpdGlv biAwKSkpDQogICAgICAoc2V0LXdpbmRvdy1zdGFydCByb290IChwb2ludC1taW4pKQ0KICAg ICAgKHNldC13aW5kb3ctdnNjcm9sbCByb290IDApDQogICAgICAoY29uZGl0aW9uLWNhc2Ug bmlsDQoJICAoc2V0LWZyYW1lLWhlaWdodA0KCSAgIGZyYW1lDQoJICAgKG1pbiAobWF4ICgr IChmcmFtZS1oZWlnaHQgZnJhbWUpIGRlbHRhKQ0KCQkgICAgIG1pbi1oZWlnaHQpDQoJCW1h eC1oZWlnaHQpKQ0KCShlcnJvciAoc2V0cSBkZWx0YSBuaWwpKSkpDQogICAgZGVsdGEpKQ0K DQo7OyBVc2FnZQ0KKGRlZnVuIHJlY292ZXItZmlsZSAoZmlsZSkNCiAgIlZpc2l0IGZpbGUg RklMRSwgYnV0IGdldCBjb250ZW50cyBmcm9tIGl0cyBsYXN0IGF1dG8tc2F2ZSBmaWxlLiIN CiAgOzsgQWN0dWFsbHkgcHV0dGluZyB0aGUgZmlsZSBuYW1lIGluIHRoZSBtaW5pYnVmZmVy IHNob3VsZCBiZSB1c2VkDQogIDs7IG9ubHkgcmFyZWx5Lg0KICA7OyBOb3QganVzdCBiZWNh dXNlIHVzZXJzIG9mdGVuIHVzZSB0aGUgZGVmYXVsdC4NCiAgKGludGVyYWN0aXZlICJGUmVj b3ZlciBmaWxlOiAiKQ0KICAoc2V0cSBmaWxlIChleHBhbmQtZmlsZS1uYW1lIGZpbGUpKQ0K ICAoaWYgKGF1dG8tc2F2ZS1maWxlLW5hbWUtcCAoZmlsZS1uYW1lLW5vbmRpcmVjdG9yeSBm aWxlKSkNCiAgICAgIChlcnJvciAiJXMgaXMgYW4gYXV0by1zYXZlIGZpbGUiIChhYmJyZXZp YXRlLWZpbGUtbmFtZSBmaWxlKSkpDQogIChsZXQgKChmaWxlLW5hbWUgKGxldCAoKGJ1ZmZl ci1maWxlLW5hbWUgZmlsZSkpDQoJCSAgICAgKG1ha2UtYXV0by1zYXZlLWZpbGUtbmFtZSkp KSkNCiAgICAoY29uZCAoKGlmIChmaWxlLWV4aXN0cy1wIGZpbGUpDQoJICAgICAgIChub3Qg KGZpbGUtbmV3ZXItdGhhbi1maWxlLXAgZmlsZS1uYW1lIGZpbGUpKQ0KCSAgICAgKG5vdCAo ZmlsZS1leGlzdHMtcCBmaWxlLW5hbWUpKSkNCgkgICAoZXJyb3IgIkF1dG8tc2F2ZSBmaWxl ICVzIG5vdCBjdXJyZW50Ig0KCQkgIChhYmJyZXZpYXRlLWZpbGUtbmFtZSBmaWxlLW5hbWUp KSkNCgkgICgod2l0aC10ZW1wLWJ1ZmZlci13aW5kb3cNCgkgICAgIipEaXJlY3RvcnkqIg0K CSAgICAjJyhsYW1iZGEgKHdpbmRvdyBfdmFsdWUpDQoJCSh1bndpbmQtcHJvdGVjdA0KCQkg ICAgKHllcy1vci1uby1wIChmb3JtYXQgIlJlY292ZXIgYXV0byBzYXZlIGZpbGUgJXM/ICIg ZmlsZS1uYW1lKSkNCgkJICAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgJ2tpbGwpKSkN CgkgICAgKHdpdGgtY3VycmVudC1idWZmZXIgc3RhbmRhcmQtb3V0cHV0DQoJICAgICAgKGxl dCAoKHN3aXRjaGVzIGRpcmVkLWxpc3Rpbmctc3dpdGNoZXMpKQ0KCQkoaWYgKGZpbGUtc3lt bGluay1wIGZpbGUpDQoJCSAgICAoc2V0cSBzd2l0Y2hlcyAoY29uY2F0IHN3aXRjaGVzICIg LUwiKSkpDQoJCTs7IFVzZSBpbnNlcnQtZGlyZWN0b3J5LXNhZmVseSwgbm90IGluc2VydC1k aXJlY3RvcnksDQoJCTs7IGJlY2F1c2UgdGhlc2UgZmlsZXMgbWlnaHQgbm90IGV4aXN0LiAg SW4gcGFydGljdWxhciwNCgkJOzsgRklMRSBtaWdodCBub3QgZXhpc3QgaWYgdGhlIGF1dG8t c2F2ZSBmaWxlIHdhcyBmb3INCgkJOzsgYSBidWZmZXIgdGhhdCBkaWRuJ3QgdmlzaXQgYSBm aWxlLCBzdWNoIGFzICIqbWFpbCoiLg0KCQk7OyBUaGUgY29kZSBpbiB2MjAueCBjYWxsZWQg YGxzJyBkaXJlY3RseSwgc28gd2UgbmVlZA0KCQk7OyB0byBlbXVsYXRlIHdoYXQgYGxzJyBk aWQgaW4gdGhhdCBjYXNlLg0KCQkoaW5zZXJ0LWRpcmVjdG9yeS1zYWZlbHkgZmlsZSBzd2l0 Y2hlcykNCgkJKGluc2VydC1kaXJlY3Rvcnktc2FmZWx5IGZpbGUtbmFtZSBzd2l0Y2hlcykp KSkNCgkgICAoc3dpdGNoLXRvLWJ1ZmZlciAoZmluZC1maWxlLW5vc2VsZWN0IGZpbGUgdCkp DQoJICAgKGxldCAoKGluaGliaXQtcmVhZC1vbmx5IHQpDQoJCSA7OyBLZWVwIHRoZSBjdXJy ZW50IGJ1ZmZlci1maWxlLWNvZGluZy1zeXN0ZW0uDQoJCSAoY29kaW5nLXN5c3RlbSBidWZm ZXItZmlsZS1jb2Rpbmctc3lzdGVtKQ0KCQkgOzsgQXV0by1zYXZlZCBmaWxlIHNob3VsZCBi ZSByZWFkIHdpdGggc3BlY2lhbCBjb2RpbmcuDQoJCSAoY29kaW5nLXN5c3RlbS1mb3ItcmVh ZCAnYXV0by1zYXZlLWNvZGluZykpDQoJICAgICAoZXJhc2UtYnVmZmVyKQ0KCSAgICAgKGlu c2VydC1maWxlLWNvbnRlbnRzIGZpbGUtbmFtZSBuaWwpDQoJICAgICAoc2V0LWJ1ZmZlci1m aWxlLWNvZGluZy1zeXN0ZW0gY29kaW5nLXN5c3RlbSkpDQoJICAgKGFmdGVyLWZpbmQtZmls ZSBuaWwgbmlsIHQpKQ0KCSAgKHQgKHVzZXItZXJyb3IgIlJlY292ZXItZmlsZSBjYW5jZWxs ZWQiKSkpKSkNCg0KKGRlZnVuIHNhdmUtYnVmZmVycy1raWxsLWVtYWNzICgmb3B0aW9uYWwg YXJnKQ0KICAiT2ZmZXIgdG8gc2F2ZSBlYWNoIGJ1ZmZlciwgdGhlbiBraWxsIHRoaXMgRW1h Y3MgcHJvY2Vzcy4NCldpdGggcHJlZml4IEFSRywgc2lsZW50bHkgc2F2ZSBhbGwgZmlsZS12 aXNpdGluZyBidWZmZXJzIHdpdGhvdXQgYXNraW5nLg0KSWYgdGhlcmUgYXJlIGFjdGl2ZSBw cm9jZXNzZXMgd2hlcmUgYHByb2Nlc3MtcXVlcnktb24tZXhpdC1mbGFnJw0KcmV0dXJucyBu b24tbmlsLCBhc2tzIHdoZXRoZXIgcHJvY2Vzc2VzIHNob3VsZCBiZSBraWxsZWQuDQpSdW5z IHRoZSBtZW1iZXJzIG9mIGBraWxsLWVtYWNzLXF1ZXJ5LWZ1bmN0aW9ucycgaW4gdHVybiBh bmQgc3RvcHMNCmlmIGFueSByZXR1cm5zIG5pbC4gIElmIGBjb25maXJtLWtpbGwtZW1hY3Mn IGlzIG5vbi1uaWwsIGNhbGxzIGl0LiINCiAgKGludGVyYWN0aXZlICJQIikNCiAgKHNhdmUt c29tZS1idWZmZXJzIGFyZyB0KQ0KICAoYW5kIChvciAobm90IChtZW1xIHQgKG1hcGNhciAo ZnVuY3Rpb24NCgkJCQkgIChsYW1iZGEgKGJ1ZikgKGFuZCAoYnVmZmVyLWZpbGUtbmFtZSBi dWYpDQoJCQkJCQkgICAgIChidWZmZXItbW9kaWZpZWQtcCBidWYpKSkpDQoJCQkJKGJ1ZmZl ci1saXN0KSkpKQ0KCSAgICh5ZXMtb3Itbm8tcCAiTW9kaWZpZWQgYnVmZmVycyBleGlzdDsg ZXhpdCBhbnl3YXk/ICIpKQ0KICAgICAgIChvciAobm90IChmYm91bmRwICdwcm9jZXNzLWxp c3QpKQ0KCSAgIDs7IHByb2Nlc3MtbGlzdCBpcyBub3QgZGVmaW5lZCBvbiBNU0RPUy4NCgkg ICAobGV0ICgocHJvY2Vzc2VzIChwcm9jZXNzLWxpc3QpKQ0KCQkgYWN0aXZlKQ0KCSAgICAg KHdoaWxlIHByb2Nlc3Nlcw0KCSAgICAgICAoYW5kIChtZW1xIChwcm9jZXNzLXN0YXR1cyAo Y2FyIHByb2Nlc3NlcykpICcocnVuIHN0b3Agb3BlbiBsaXN0ZW4pKQ0KCQkgICAgKHByb2Nl c3MtcXVlcnktb24tZXhpdC1mbGFnIChjYXIgcHJvY2Vzc2VzKSkNCgkJICAgIChzZXRxIGFj dGl2ZSB0KSkNCgkgICAgICAgKHNldHEgcHJvY2Vzc2VzIChjZHIgcHJvY2Vzc2VzKSkpDQoJ ICAgICAob3IgKG5vdCBhY3RpdmUpDQoJCSAod2l0aC10ZW1wLWJ1ZmZlci13aW5kb3cgKGdl dC1idWZmZXItY3JlYXRlICIqUHJvY2VzcyBMaXN0KiIpDQoJCSAgICMnKGxhbWJkYSAod2lu ZG93IF92YWx1ZSkNCgkJICAgICAgICh1bndpbmQtcHJvdGVjdA0KCQkJICAgKHllcy1vci1u by1wICJBY3RpdmUgcHJvY2Vzc2VzIGV4aXN0OyBraWxsIHRoZW0gYW5kIGV4aXQgYW55d2F5 PyAiKQ0KCQkJIChxdWl0LXJlc3RvcmUtd2luZG93IHdpbmRvdyAna2lsbCkpKQ0KCQkgICAo bGlzdC1wcm9jZXNzZXMgdCkpKSkpDQogICAgICAgOzsgUXVlcnkgdGhlIHVzZXIgZm9yIG90 aGVyIHRoaW5ncywgcGVyaGFwcy4NCiAgICAgICAocnVuLWhvb2std2l0aC1hcmdzLXVudGls LWZhaWx1cmUgJ2tpbGwtZW1hY3MtcXVlcnktZnVuY3Rpb25zKQ0KICAgICAgIChvciAobnVs bCBjb25maXJtLWtpbGwtZW1hY3MpDQoJICAgKGZ1bmNhbGwgY29uZmlybS1raWxsLWVtYWNz ICJSZWFsbHkgZXhpdCBFbWFjcz8gIikpDQogICAgICAgKGtpbGwtZW1hY3MpKSkNCg0KKGRl ZnVuIGRpcmVkLW1hcmstcG9wLXVwIChidWZmZXItb3ItbmFtZSBvcC1zeW1ib2wgZmlsZXMg ZnVuY3Rpb24gJnJlc3QgYXJncykNCiAgIlJldHVybiBGVU5DVElPTidzIHJlc3VsdCBvbiBB UkdTIGFmdGVyIHNob3dpbmcgd2hpY2ggZmlsZXMgYXJlIG1hcmtlZC4NCkRpc3BsYXlzIHRo ZSBmaWxlIG5hbWVzIGluIGEgd2luZG93IHNob3dpbmcgYSBidWZmZXIgbmFtZWQNCkJVRkZF Ui1PUi1OQU1FOyB0aGUgZGVmYXVsdCBuYW1lIGJlaW5nIFwiICpNYXJrZWQgRmlsZXMqXCIu ICBUaGUNCndpbmRvdyBpcyBub3Qgc2hvd24gaWYgdGhlcmUgaXMganVzdCBvbmUgZmlsZSwg YGRpcmVkLW5vLWNvbmZpcm0nDQppcyB0LCBvciBPUC1TWU1CT0wgaXMgYSBtZW1iZXIgb2Yg dGhlIGxpc3QgaW4gYGRpcmVkLW5vLWNvbmZpcm0nLg0KDQpGSUxFUyBpcyB0aGUgbGlzdCBv ZiBtYXJrZWQgZmlsZXMuICBJdCBjYW4gYWxzbyBiZSAodCBGSUxFTkFNRSkNCmluIHRoZSBj YXNlIG9mIG9uZSBtYXJrZWQgZmlsZSwgdG8gZGlzdGluZ3Vpc2ggdGhhdCBmcm9tIHVzaW5n DQpqdXN0IHRoZSBjdXJyZW50IGZpbGUuDQoNCkZVTkNUSU9OIHNob3VsZCBub3QgbWFuaXB1 bGF0ZSBmaWxlcywganVzdCByZWFkIGlucHV0IFwoYW4NCmFyZ3VtZW50IG9yIGNvbmZpcm1h dGlvbikuIg0KICAoaWYgKG9yIChlcSBkaXJlZC1uby1jb25maXJtIHQpDQoJICAobWVtcSBv cC1zeW1ib2wgZGlyZWQtbm8tY29uZmlybSkNCgkgIDs7IElmIEZJTEVTIGRlZmF1bHRlZCB0 byB0aGUgY3VycmVudCBsaW5lJ3MgZmlsZS4NCgkgICg9IChsZW5ndGggZmlsZXMpIDEpKQ0K ICAgICAgKGFwcGx5IGZ1bmN0aW9uIGFyZ3MpDQogICAgKGxldCAoKGJ1ZmZlciAoZ2V0LWJ1 ZmZlci1jcmVhdGUgKG9yIGJ1ZmZlci1vci1uYW1lICIgKk1hcmtlZCBGaWxlcyoiKSkpKQ0K ICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmZmVyDQoJKGxldCAoKHNwbGl0LWhlaWdo dC10aHJlc2hvbGQgMCkNCgkgICAgICAoZGlzcGxheS1idWZmZXItYXBwLWFjdGlvbg0KCSAg ICAgICAoY29ucyAnZGlzcGxheS1idWZmZXItYmVsb3ctc2VsZWN0ZWQgbmlsKSkpDQoJICAo d2l0aC10ZW1wLWJ1ZmZlci13aW5kb3cNCgkgICBidWZmZXINCgkgICAjJyhsYW1iZGEgKHdp bmRvdyBfdmFsdWUpDQoJICAgICAgICh1bndpbmQtcHJvdGVjdA0KCQkgICAoYXBwbHkgZnVu Y3Rpb24gYXJncykNCgkJIChxdWl0LXJlc3RvcmUtd2luZG93IHdpbmRvdyAna2lsbCkpKQ0K CSAgIDs7IEhhbmRsZSAodCBGSUxFKSBqdXN0IGxpa2UgKEZJTEUpLCBoZXJlLiAgVGhhdCB2 YWx1ZSBpcw0KCSAgIDs7IHVzZWQgKG9ubHkgaW4gc29tZSBjYXNlcyksIHRvIG1lYW4ganVz dCBvbmUgZmlsZSB0aGF0IHdhcw0KCSAgIDs7IG1hcmtlZCwgcmF0aGVyIHRoYW4gdGhlIGN1 cnJlbnQgbGluZSBmaWxlLg0KCSAgIChkaXJlZC1mb3JtYXQtY29sdW1ucy1vZi1maWxlcw0K CSAgICAoaWYgKGVxIChjYXIgZmlsZXMpIHQpIChjZHIgZmlsZXMpIGZpbGVzKSkNCgkgICAo cmVtb3ZlLXRleHQtcHJvcGVydGllcyAocG9pbnQtbWluKSAocG9pbnQtbWF4KQ0KCQkJCSAg ICcobW91c2UtZmFjZSBuaWwgaGVscC1lY2hvIG5pbCkpKSkpKSkpDQo= --------------060001040808080405070808-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 15 12:49:11 2012 Received: (at 11939) by debbugs.gnu.org; 15 Jul 2012 16:49:11 +0000 Received: from localhost ([127.0.0.1]:43004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqS0M-0000VY-S0 for submit@debbugs.gnu.org; Sun, 15 Jul 2012 12:49:11 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:48738) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqS0K-0000VR-8Q for 11939@debbugs.gnu.org; Sun, 15 Jul 2012 12:49:09 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6FGhGFY001171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jul 2012 16:43:17 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6FGhG4c012054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 16:43:16 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6FGhFj5031791; Sun, 15 Jul 2012 11:43:15 -0500 Received: from dradamslap1 (/10.159.181.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Jul 2012 09:43:15 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sun, 15 Jul 2012 09:43:04 -0700 Message-ID: <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5002EAF4.5080107@gmx.at> Thread-Index: Ac1ipAh6znQ2XuxOSeySfmwrBBxL5gAABB3w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> Sorry. Do (defalias 'yes-or-no-p 'y-or-n-p) and then try. > > > > Are you sure you mean that? AFAIK, `y-or-n-p' is not at > > all representative - it does not even use the minibuffer, > > I think: it just reads events directly. I will try to do as > > you instruct, if you confirm, but I do not understand how > > using `y-or-n-p' here can possibly help. > > Because you can do `select-frame-set-input-focus' with it. I'm afraid I still do not understand (but maybe I don't need to). I thought the problem has to do with input focus for minibuffer reading. But maybe you are saying that the minibuffer need not be involved, and that `read-event' will also depend on which frame has the focus. In any case, please give me the specific recipe that you would like me to try. I'm afraid I've lost track at this point. And is this still pertinent, given what we have discovered wrt a reproducible recipe from emacs -Q? > >> ... what command is C-] bound to? I can't type it on my > >> keyboard ... > > > > `abort-recursive-edit'. `C-]' is the (only) default > > global binding (emacs -Q) for `abort-recursive-edit'. > > My keyboard doesn't allow me to input things like C-] easily > so I don't know what these do. You could rebind that command to see what it does. And `C-h f' describes it. (It is a bit like a super C-g.) > If you get the problem with `pop-up-frames' t and not with the special > display settings we have simplified the problem. Yes, greatly. > > A second bug (I think) is that there is NO feedback/response > > to your typing the answer. With focus in the *Process List* > > frame, which has a read-only buffer, I would expect an error > > message saying that the buffer is read-only. But you get > > NO message - nada. Not only that, but I see no such > > message in buffer *Messages* if I look there. Dunno why this is. > > I suppose that as long as you don't type either yes or no in the > original frame nothing happens at all. Presumably _some_ buffer receives the input. If it is a read-only buffer then I would expect a read-only error message. If it is not then I would expect to see what I type in some buffer. I see neither effect. And presumably (it seems that way anyway) it is the *Process List* buffer, which is read-only, that has the focus. This behavior does not seem normal. > > Well, that's one problem, anyway. Really, I do not want > > the new frame popped up to have a minibuffer and pose the > > question about killing processes. I want the > > new frame to just be displayed and _not selected_ for > > input/output (user interaction). I do not want it to have > > a minibuffer. > > But we must select a frame for answering the question. The frame for posing and answering all questions should be, as usual, the minibuffer frame. Aside from `read-event' etc., reading user input should use the minibuffer, and that means it should use the minibuffer frame. Looking at the C code for `yes-or-no-p' (Emacs 23.3), it clearly calls `read-from-minibuffer' (`Fread_from_minibuffer'), so it should use the minibuffer. The frame that should have the input focus for that prompt and reading should be the standalone minibuffer frame - that is the _only_ frame that has a minibuffer. It makes no sense for any other frame to have the input focus when reading from the minibuffer, since no other frame _has_ a minibuffer. > > More precisely, I don't have much of an opinion in the > > case of a non standalone minibuffer. > > > > But in the case of a standalone minibuffer, it definitely > > should continue to have the input focus. That's the point, for me. > > Why "continue"? You could invoke C-x C-c in any frame. See above. It should have the input focus for any _reading from the minibuffer_. Obviously, other frames can have the input focus when not reading from the minibuffer. `yes-or-no-p' reads from the minibuffer. > > It would not be a solution for me to give the new frame > > its own minibuffer or something and to let it keep the input > > focus. The user should be able to always look to the same, > > standalone minibuffer - the *only* minibuffer area - for all > > prompts and user replies. > > We'll see to that. That would be a great fix. > >> > Buffer *Help* is still popped up in a new frame that has > >> > those colors, but now when I hit `q' in it the frame does not > >> > disappear and its buffer is changed. That's not what I would > >> > call "dedicated" anymore. > >> > >> That's hardly surprising: With `pop-up-frames' t you > >> shouldn't get a dedicated window, I suppose. > > > > Uh, if you are saying what I think you are saying then I'm > > afraid I disagree strongly about that. To me, that would be > > a regression. > > Don't be afraid. I meant with `pop-up-frames' t and > `special-display-buffer-names' and friends nil. OK. But the behavior I saw with that test indicated/suggested that *Help* was not entirely special-display (with `pop-up-frames' t and the *Help* frame defined as indicated with `special-display-buffer-names'. The frame was created with the correct colors etc., but buffer *Help* ended up being replaced in the frame, which is not what "special display" means. So I think there might be a second bug here. > > If I use Dired+ (which does what my patch does) then there > > is no problem, so in my daily use this is solved for the > > Dired but reported, but not in general (viz. > > this bug wrt quitting with active processes). > > But your patch doesn't address the input focus issue or am I missing > something? Correct. But the problem does not exist with my patch. I don't have an explanation. But please see the #15566 thread - in particular, the part about the use of code that is nearly identical but that does not manifest the input problem. See the message I sent that has the attachment `throw-chmod-vs-chmod-rec.el'. I do not understand why what I report happens, but it happens. This is from that thread: >> But this is the same code sequence that occurs for `M' - >> AFAICT the only difference is the existence of the two >> preliminary questions. So it's not clear to me where the >> problem comes from. This is the calling sequence: >> >> dired-do-chmod OR diredp-do-chmod-recursive >> dired-mark-read-string >> dired-mark-pop-up >> dired-pop-to-buffer >> make-frame, then read-from-minibuffer (via FUNCTION arg) >> >> The code for `dired-do-chmod' and `diredp-do-chmod-recursive' >> is nearly identical - see attachment. The only difference is the >> gathering of the list of files (which includes the preliminary >> confirmation questions). But let's not worry about that here/now. Perhaps this thread will find a solution to the problem _in general_. That's my current hope, at least. > > If you want a standalone minibuffer frame to have the > > _only_ minibuffer then you must do everything at load time, > > i.e., in .emacs. > > So this makes debugging more difficult for people who are not used to > work with minibuffer-only frames. Yes. That's not my doing; it's a fact of GNU Emacs life. Unless someone provides a fix that changes this. > I have attached another version of `with-temp-buffer-window' which now > explicitly shifts input focus to the frame selected at the time the > macro is called. I hope this will fix the `pop-up-frames' t scenario. > I'm afraid it will not fix the problem when you invoke C-x C-c in any > window but the minibuffer-only window so we probably have to fix that > issue separately. Please try it. Just what is the recipe to try (e.g. from emacs -Q)? Wrt "C-x C-c in any window but the minibuffer-only window": It's about reading from the minibuffer (e.g. `read-from-minibuffer'). It never matters (apart from this bug about new frames that get created during the minibuffer reading) which buffer/frame is selected when you call `read-from-minibuffer'. Focus is always switched to the minibuffer (and its frame). The problem here seems to be that just after focus is correctly switched to the minibuffer frame, for minibuffer interaction (reading), the new frame is popped up and MS Windows gives it the focus. At least that's the (limited) conceptual model I'm adopting so far. IOW, I don't think the problem is to give the minibuffer frame the focus. I'm assuming that that is happening correctly, as usual. The problem, I think, is that the new frame creation happens at the same time or just afterward, and that steals the focus from the minibuffer frame (thanks to MS Windows). Thx - Drew From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 05:18:01 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 09:18:02 +0000 Received: from localhost ([127.0.0.1]:43706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqhRJ-0005e7-5t for submit@debbugs.gnu.org; Mon, 16 Jul 2012 05:18:01 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52767) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SqhRG-0005dz-B9 for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 05:17:59 -0400 Received: (qmail invoked by alias); 16 Jul 2012 09:12:03 -0000 Received: from 62-47-49-174.adsl.highway.telekom.at (EHLO [62.47.49.174]) [62.47.49.174] by mail.gmx.net (mp036) with SMTP; 16 Jul 2012 11:12:03 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19TD3NOXp5Tb8B+1Omhiv9oDb3D7EmcRP1Sldtkyw sb5bdkRQBGKdZa Message-ID: <5003DAF2.2060400@gmx.at> Date: Mon, 16 Jul 2012 11:12:18 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> In-Reply-To: <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I'm afraid I still do not understand (but maybe I don't need to). I thought the > problem has to do with input focus for minibuffer reading. But maybe you are > saying that the minibuffer need not be involved, and that `read-event' will also > depend on which frame has the focus. > > In any case, please give me the specific recipe that you would like me to try. > I'm afraid I've lost track at this point. `y-or-n-p' has the following two lines (when minibuffer-auto-raise (raise-frame (window-frame (minibuffer-window)))) So when you want to give focus to the minibuffer window you might want to replace `raise-frame' by the stronger `select-frame-set-input-focus' (when minibuffer-auto-raise (select-frame-set-input-focus (window-frame (minibuffer-window)))) For this to work you have to defalias `yes-or-no-p' to `y-or-n-p'. > And is this still pertinent, given what we have discovered wrt a reproducible > recipe from emacs -Q? As long as we have not found a solution, yes. >> I suppose that as long as you don't type either yes or no in the >> original frame nothing happens at all. > > Presumably _some_ buffer receives the input. If it is a read-only buffer then I > would expect a read-only error message. If it is not then I would expect to see > what I type in some buffer. I see neither effect. And presumably (it seems > that way anyway) it is the *Process List* buffer, which is read-only, that has > the focus. > > This behavior does not seem normal. You would have to try with `y-or-n-p'. read_minibuf has only Fmake_frame_visible (mini_frame); if (minibuffer_auto_raise) Fraise_frame (mini_frame); which might not be sufficient for your case. Once `y-or-n-p' with focus selection works we can try to make it work in read_minibuf too. > The frame for posing and answering all questions should be, as usual, the > minibuffer frame. Aside from `read-event' etc., reading user input should use > the minibuffer, and that means it should use the minibuffer frame. > > Looking at the C code for `yes-or-no-p' (Emacs 23.3), it clearly calls > `read-from-minibuffer' (`Fread_from_minibuffer'), so it should use the > minibuffer. The frame that should have the input focus for that prompt and > reading should be the standalone minibuffer frame - that is the _only_ frame > that has a minibuffer. > > It makes no sense for any other frame to have the input focus when reading from > the minibuffer, since no other frame _has_ a minibuffer. Most users don't care about standalone minibuffer frames. They want to see one frame where they find all information. >> > More precisely, I don't have much of an opinion in the >> > case of a non standalone minibuffer. >> > >> > But in the case of a standalone minibuffer, it definitely >> > should continue to have the input focus. That's the point, for me. >> >> Why "continue"? You could invoke C-x C-c in any frame. > > See above. It should have the input focus for any _reading from the > minibuffer_. Obviously, other frames can have the input focus when not reading > from the minibuffer. `yes-or-no-p' reads from the minibuffer. So if another frame has input focus and emacs asks a `yes-or-no-p' question, focus _should_ switch. > But the behavior I saw with that test indicated/suggested that *Help* was not > entirely special-display (with `pop-up-frames' t and the *Help* frame defined as > indicated with `special-display-buffer-names'. > > The frame was created with the correct colors etc., but buffer *Help* ended up > being replaced in the frame, which is not what "special display" means. So I > think there might be a second bug here. If this is independent from the behavior we discuss currently, we'll have to investigate it. >> > If I use Dired+ (which does what my patch does) then there >> > is no problem, so in my daily use this is solved for the >> > Dired but reported, but not in general (viz. >> > this bug wrt quitting with active processes). >> >> But your patch doesn't address the input focus issue or am I missing >> something? > > Correct. But the problem does not exist with my patch. I don't have an > explanation. Me neither. You would have to go through it and find what it does differently. > But please see the #15566 thread - in particular, the part about the use of code > that is nearly identical but that does not manifest the input problem. See the > message I sent that has the attachment `throw-chmod-vs-chmod-rec.el'. I do not > understand why what I report happens, but it happens. >> I have attached another version of `with-temp-buffer-window' which now >> explicitly shifts input focus to the frame selected at the time the >> macro is called. I hope this will fix the `pop-up-frames' t scenario. >> I'm afraid it will not fix the problem when you invoke C-x C-c in any >> window but the minibuffer-only window so we probably have to fix that >> issue separately. Please try it. > > Just what is the recipe to try (e.g. from emacs -Q)? With your usual setting load the file and test the shell and the dired scenarios. > Wrt "C-x C-c in any window but the minibuffer-only window": It's about reading > from the minibuffer (e.g. `read-from-minibuffer'). It never matters (apart from > this bug about new frames that get created during the minibuffer reading) which > buffer/frame is selected when you call `read-from-minibuffer'. Focus is always > switched to the minibuffer (and its frame). Because it does a simple `raise-frame' of the minibuffer frame which seems to work when you don't pop up another frame before. > The problem here seems to be that just after focus is correctly switched to the > minibuffer frame, for minibuffer interaction (reading), the new frame is popped > up and MS Windows gives it the focus. At least that's the (limited) conceptual > model I'm adopting so far. > > IOW, I don't think the problem is to give the minibuffer frame the focus. I'm > assuming that that is happening correctly, as usual. The problem, I think, is > that the new frame creation happens at the same time or just afterward, and that > steals the focus from the minibuffer frame (thanks to MS Windows). It doesn't help to speculate. I know of three functions to experiment with (`select-frame' and `raise-frame' being apparently too weak): - `select-frame-set-input-focus' which is probably too strong because it can change the Z-order thus obfuscating the frame where important information (like the list of directories to delete) is displayed, - `x-focus-frame' which should redirect any input to the frame argument, and - `redirect-frame-focus' which could be used to redirect input only from the frame where, for example, the marked directories are displayed to the minibuffer-only frame. You can try to experiment with these, either in `y-or-n-p' or in `with-temp-buffer-window'. If neither of these helps to direct focus away from the new frame, I see no solution. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 10:29:19 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 14:29:19 +0000 Received: from localhost ([127.0.0.1]:44259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqmIY-0005Ap-7d for submit@debbugs.gnu.org; Mon, 16 Jul 2012 10:29:19 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:28565) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqmIW-0005Ai-4e for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 10:29:17 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GENJW4026340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 14:23:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GENISG019491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 14:23:19 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6GENIhw004340; Mon, 16 Jul 2012 09:23:18 -0500 Received: from dradamslap1 (/10.159.217.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2012 07:23:18 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 16 Jul 2012 07:23:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5003DAF2.2060400@gmx.at> Thread-Index: Ac1jMxH+6iLiRre1ROCHUVoOxzHinAAKaT6Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> I have attached another version of > >> `with-temp-buffer-window' which now explicitly shifts input > >> focus to the frame selected at the time the macro is called. > >> I hope this will fix the `pop-up-frames' t scenario. > >> I'm afraid it will not fix the problem when you invoke > >> C-x C-c in any window but the minibuffer-only window so we > >> probably have to fix that issue separately. Please try it. > > > > Just what is the recipe to try (e.g. from emacs -Q)? > > With your usual setting load the file and test the shell and the dired > scenarios. I might be misunderstanding you, but I did this: 1. Started Emacs with my normal setup (not from emacs -Q). 2. Loaded the code you sent. 3. M-x shell 4. Clicked the title bar of the standalone minibuffer frame, to select it. (Did that since you said that your code would not help with the usual case, where another frame has the focus). 5. C-x C-c The result was the same as before: typing (e.g. "yes") had no effect. The minibuffer frame apparently lost the focus as soon as the new *Process List* was created. And when I canceled, the supposed special-display buffer *Process List* was replaced in its frame by the buffer that was current when I hit C-x C-c. This part seems to be the same (separate) bug that I reported wrt *Help*. In this case, the special-display buffer *Process List* was defined via `special-display-regexps' and not (as for *Help*) via `special-display-buffer-names'. So it seems there is a general bug that a special-display buffer is no longer really special-display: its window/frame is not dedicated as it should be. Burying its buffer should not replace that buffer in its dedicated window/frame. It should remove that window/frame (I have `frame-auto-hide-function' = `delete-frame'). HTH. Let me know if I did not understand the recipe correctly. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 10:58:34 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 14:58:34 +0000 Received: from localhost ([127.0.0.1]:44299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sqmks-0005se-2C for submit@debbugs.gnu.org; Mon, 16 Jul 2012 10:58:34 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:20728) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sqmkp-0005sX-TT for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 10:58:32 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GEqYmd030349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 14:52:35 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GEqXhd015766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 14:52:34 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6GEqXVb031633; Mon, 16 Jul 2012 09:52:33 -0500 Received: from dradamslap1 (/10.159.217.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2012 07:52:33 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 16 Jul 2012 07:52:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5003DAF2.2060400@gmx.at> Thread-Index: Ac1jMxH+6iLiRre1ROCHUVoOxzHinAAK4zuQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > The frame for posing and answering all questions should > > be, as usual, the minibuffer frame. Aside from `read-event' > > etc., reading user input should use the minibuffer, and that > > means it should use the minibuffer frame.... > > > > It makes no sense for any other frame to have the input > > focus when reading from the minibuffer, since no other frame > > _has_ a minibuffer. > > Most users don't care about standalone minibuffer frames. > They want to see one frame where they find all information. This bug is about those users who _do_ use a standalone minibuffer frame, whether they are a majority or a minority of GNU Emacs users. They want reading of user input and echoing of messages to take place in the same location each time: the standalone minibuffer frame. I'm confident of that, even if it is presumptuous to speak of what other users might want. FWIW, if most GNU Emacs users do not use a standalone minibuffer today, it might have something to do with bugs like this one. I'd be willing to bet that at least half the users of Epoch did use the standalone minibuffer. But in Epoch it was standard, available out of the box, and worked perfectly. IOW, Epoch users had a real, simple choice, with no jumping through hoops. Using a standalone minibuffer is not some oddball idea, even if only a minority of users choose it today. And even if, after the bugs are fixed in GNU Emacs, such users remain a minority, that does not mean that their use case is unimportant. > >> > But in the case of a standalone minibuffer, it definitely > >> > should continue to have the input focus. > >> > >> Why "continue"? You could invoke C-x C-c in any frame. > > > > See above. It should have the input focus for any _reading > > from the minibuffer_. Obviously, other frames can have the input > > focus when not reading from the minibuffer. `yes-or-no-p' reads > > from the minibuffer. > > So if another frame has input focus and emacs asks a `yes-or-no-p' > question, focus _should_ switch. Emacs should always switch to the minibuffer when it reads from the minibuffer, yes. You cannot use the minibuffer if it does not have the focus. And that's the point of this bug. > > But the behavior I saw with that test indicated/suggested > > that *Help* was not entirely special-display... > > > > The frame was created with the correct colors etc., but > > buffer *Help* ended up being replaced in the frame, which is not > > what "special display" means. So I think there might be a > > second bug here. > > If this is independent from the behavior we discuss currently, we'll > have to investigate it. I'm comforted that you consider that behavior to be a bug. See also my earlier message today, where I reported (seemingly) the same bug wrt special-display buffer `*Process List*' when testing the code you sent. That special-display definition was made differently (via `special-display-regexps'), but the bugged effect seems to be the same. No buffer should take the place of a special-display buffer in its window/frame. That's always been part of the definition of "special display". > >> > If I use Dired+ (which does what my patch does) then there > >> > is no problem, so in my daily use this is solved for the > >> > Dired but reported, but not in general (viz. > >> > this bug wrt quitting with active processes). > >> > >> But your patch doesn't address the input focus issue or > >> am I missing something? > > > > Correct. But the problem does not exist with my patch. I > > don't have an explanation. > > Me neither. You would have to go through it and find what it does > differently. > > > But please see the #15566 thread Sorry, I meant #11566. Note: I am testing using 24.1. Dunno whether the bug reported in #11566 was deemed to have been fixed after 24.1 or before it. IOW, perhaps it has been fixed since 24.1, but I cannot test with a recent build until I can get a post 24.1 Windows build that works. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 12:26:14 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 16:26:14 +0000 Received: from localhost ([127.0.0.1]:44415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sqo7i-0007wk-3M for submit@debbugs.gnu.org; Mon, 16 Jul 2012 12:26:14 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:56724) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sqo7f-0007wc-NJ for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 12:26:12 -0400 Received: (qmail invoked by alias); 16 Jul 2012 16:06:32 -0000 Received: from 62-47-32-250.adsl.highway.telekom.at (EHLO [62.47.32.250]) [62.47.32.250] by mail.gmx.net (mp027) with SMTP; 16 Jul 2012 18:06:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18AFoskh3kApiscOo0YY79W0v2WVaza92k0mhQXj6 EPCbHo3Ac5yxeY Message-ID: <50043C3D.7090201@gmx.at> Date: Mon, 16 Jul 2012 18:07:25 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I might be misunderstanding you, but I did this: > > 1. Started Emacs with my normal setup (not from emacs -Q). > 2. Loaded the code you sent. > 3. M-x shell > > 4. Clicked the title bar of the standalone minibuffer frame, to select it. (Did > that since you said that your code would not help with the usual case, where > another frame has the focus). > > 5. C-x C-c > > The result was the same as before: typing (e.g. "yes") had no effect. The > minibuffer frame apparently lost the focus as soon as the new *Process List* was > created. OK. Then let's try again with `pop-up-frames' t. With emacs -Q evaluate (progn (setq pop-up-frames t) (load "~/with-temp-buffer-window.el") (shell)) type C-x C-c, and tell me what happens. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 12:42:50 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 16:42:50 +0000 Received: from localhost ([127.0.0.1]:44423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqoNm-0008JZ-IA for submit@debbugs.gnu.org; Mon, 16 Jul 2012 12:42:50 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:20728) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqoNk-0008JR-5c for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 12:42:48 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GGaoou026777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 16:36:51 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GGaoxb006053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 16:36:50 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6GGaoPJ022055; Mon, 16 Jul 2012 11:36:50 -0500 Received: from dradamslap1 (/10.159.217.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2012 09:36:50 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 16 Jul 2012 09:36:35 -0700 Message-ID: <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50043C3D.7090201@gmx.at> Thread-Index: Ac1jbuHVbVHd0FX5QUSINPxenMjVlgAAPLuw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > With emacs -Q evaluate > (progn > (setq pop-up-frames t) > (load "~/with-temp-buffer-window.el") > (shell)) > type C-x C-c, and tell me what happens. Same behavior as the other emacs -Q recipe that manifested the problem: The question about killing processes is shown in the minibuffer of the frame with buffer *shell*. Buffer *Process List* is popped up in a new frame, which is apparently selected for focus (by MS Windows). Typing yes/no has no effect and there is no feedback, presumably because the wrong frame receives the input. (I cannot tell the order between the behavior described in the first and second sentences. They seem to happen about the same time) And if you click mouse-1 in the echo area of the *Process List* frame then *Messages* is popped up in a new frame, confirming that there is no active minibuffer there. So now we have two recipes from emacs -Q, one with the code you sent. BTW, if, after the kill-processes question is posed, I hit C-x C-c again (no reason to do that, but I did, just to see) then I get this message: "window-normalize-window: # is not a live window" and the frame with *Process List* disappears. Dunno whether this extra info helps at all, but I found it curious behavior. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 13:35:26 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 17:35:26 +0000 Received: from localhost ([127.0.0.1]:44452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqpCg-00014m-FX for submit@debbugs.gnu.org; Mon, 16 Jul 2012 13:35:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:35879) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SqpCe-00014e-36 for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 13:35:25 -0400 Received: (qmail invoked by alias); 16 Jul 2012 17:03:57 -0000 Received: from 62-47-32-250.adsl.highway.telekom.at (EHLO [62.47.32.250]) [62.47.32.250] by mail.gmx.net (mp028) with SMTP; 16 Jul 2012 19:03:57 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18MtlM+QOkMwsNtecoPQSDpzHTjZXbcoJuuiAB8vH vDpX4jzeFJBPek Message-ID: <500449B7.6070309@gmx.at> Date: Mon, 16 Jul 2012 19:04:55 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> In-Reply-To: <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> With emacs -Q evaluate >> (progn >> (setq pop-up-frames t) >> (load "~/with-temp-buffer-window.el") >> (shell)) >> type C-x C-c, and tell me what happens. > > Same behavior as the other emacs -Q recipe that manifested the problem: > > The question about killing processes is shown in the minibuffer of the frame > with buffer *shell*. Buffer *Process List* is popped up in a new frame, which > is apparently selected for focus (by MS Windows). Typing yes/no has no effect > and there is no feedback, presumably because the wrong frame receives the input. > > (I cannot tell the order between the behavior described in the first and second > sentences. They seem to happen about the same time) > > And if you click mouse-1 in the echo area of the *Process List* frame then > *Messages* is popped up in a new frame, confirming that there is no active > minibuffer there. > > So now we have two recipes from emacs -Q, one with the code you sent. This means that we have two different systems. Here (Windows XP SP2) the scenario above makes the *shell* buffer partially hide the *Process List* buffer and typing yes/no has the desired effect. Now we can only wait till someone confirms either your or my behavior. BTW, is it possible that Cygwin interferes here? With Cygwin (rootless) you apparently can't pop up an existing frame, see http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00364.html > BTW, if, after the kill-processes question is posed, I hit C-x C-c again (no > reason to do that, but I did, just to see) then I get this message: > > "window-normalize-window: # is not a live window" > > and the frame with *Process List* disappears. > > Dunno whether this extra info helps at all, but I found it curious behavior. It's a leftover from `quit-window'. Thanks for noticing. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 14:28:35 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 18:28:35 +0000 Received: from localhost ([127.0.0.1]:44549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sqq27-0002JB-2W for submit@debbugs.gnu.org; Mon, 16 Jul 2012 14:28:35 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:20155) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sqq25-0002J2-1V for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 14:28:33 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GIMZYi019766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 18:22:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GIMYKd023031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 18:22:35 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6GIMYdP006465; Mon, 16 Jul 2012 13:22:34 -0500 Received: from dradamslap1 (/10.159.217.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2012 11:22:34 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 16 Jul 2012 11:22:19 -0700 Message-ID: <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500449B7.6070309@gmx.at> Thread-Index: Ac1jeI3P4mvT1RpzTS21iwsV3gF2bQAAz75A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > This means that we have two different systems. Here (Windows XP SP2) > the scenario above makes the *shell* buffer partially hide > the *Process List* buffer and typing yes/no has the desired effect. > Now we can only wait till someone confirms either your or my behavior. Martin, I'm really sorry, but I was mistakenly not testing with the latest code you sent. I think I did not realize that you sent two versions of your with-temp-buffer-window.el. When I try your recipe from emacs -Q, this time loading the second version of the code you sent, the problem for that emacs -Q recipe is solved. Progress. However, trying with my setup and then loading your code does not solve either the shell frame problem or the Dired problem. I then tried again from emacs -Q with your code, but loading only hexrgb.el, oneonone.el, and the Cygwin setup libraries, to test whether the problem was a standalone minibuffer. I saw no problem when I used C-x C-c to quit with active processes. Likewise, no problem with the Dired scenario. That's more good news. I then tried as for the last test, but also setting `special-display-regexps' to ("[ ]?[*][^*]+[*]") so that *Process List* is special-display. Again, I saw no problem (bug). (But the *Process List* frame that was popped up was completely hidden behind the frame that was selected when I hit C-x C-c. That's not good.) So I do not yet know what else in my setup causes the problem. I will have to dig to try to find out - can't do that today. If we do find a solution for the problem in the end, it would be good if it were also a solution for older Emacs versions, and not just Emacs 24+. The same problem exists in all Emacs versions I am aware of. (But we're not there yet, anyway.) > > BTW, if, after the kill-processes question is posed, I hit > > C-x C-c again (no reason to do that, but I did, just to see) > > then I get this message: > > > > "window-normalize-window: # is not a live window" > > > > and the frame with *Process List* disappears. > > > > Dunno whether this extra info helps at all, but I found it > > curious behavior. > > It's a leftover from `quit-window'. Thanks for noticing. Glad my feedback serves some purpose occasionally. ;-) From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 16 19:32:46 2012 Received: (at 11939) by debbugs.gnu.org; 16 Jul 2012 23:32:46 +0000 Received: from localhost ([127.0.0.1]:44825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqumU-0000l7-08 for submit@debbugs.gnu.org; Mon, 16 Jul 2012 19:32:46 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:22762) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqumR-0000kz-7u for 11939@debbugs.gnu.org; Mon, 16 Jul 2012 19:32:44 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GNQi5E020799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 23:26:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GNQhjM007814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 23:26:44 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6GNQhrr008612; Mon, 16 Jul 2012 18:26:43 -0500 Received: from dradamslap1 (/10.159.217.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jul 2012 16:26:43 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Mon, 16 Jul 2012 16:26:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> Thread-Index: Ac1jeI3P4mvT1RpzTS21iwsV3gF2bQAAz75AAAbmiuA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Importance: High X-Message-Flag: Follow up X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > So I do not yet know what else in my setup causes the > problem. I will have to dig to try to find out - can't do that today. I found the problem in my code and fixed it. It was kind of interesting, so I'll describe it a bit in case you are interested. In my code I put command `1on1-fit-minibuffer-frame' on `post-command-hook'. That function fits the standalone minibuffer frame to its "buffer contents" (taking Icomplete overlays into account etc.). The function assumes that it is called from the minibuffer, i.e., that the selected frame is the standalone frame. Which it is... But something apparently changed the focus in this case - I'm guessing, as I said before, that it was the popping up of the new frame. And some second command is involved at that point - apparently `handle-switch-frame'. So because of `post-command-hook', `1on1-fit-minibuffer-frame' got called a second time, and this time with the previously selected frame being selected (i.e., the frame that was selected prior to entering the minibuffer). The minibuffer was still active, but the selected frame was another one (e.g. *Process List*). I came up with three alternative fixes that work - I chose the second one: 1. The first fix is to call `select-frame-set-input-focus' at the end of `1on1-fit-minibuffer-frame'. I can tell by debugging using `message' that the frame switch happens outside `1on1-fit-minibuffer-frame': the selected frame is the minibuffer frame the first time `1on1-fit-minibuffer-frame' is called, right up till the end. But it is another frame the next time `1on1-fit-minibuffer-frame' is called, which appears to be immediately afterward. So why does this fix work? Dunno. Even though without adding the call to `select-frame-set-input-focus' the frame is correct when the first call to `1on1-fit-minibuffer-frame' ends, if I do not add that call then it is incorrect for the second `1on1-fit-minibuffer-frame' call. Well that's understandable from a `switch-frame' event. But what's not clear to me is why calling `select-frame-set-input-focus' at the end of the first call to `1on1-fit-minibuffer-frame' fixes things. As I said, the frame switch seems to happen between the two calls, yet selecting the minibuffer frame before the end of the first call solves the problem. Maybe this has something to do with the redisplay code? No idea. 2. The second fix is to have `1on1-fit-minibuffer-frame' do nothing unless: (eq last-event-frame (save-selected-window (select-window (minibuffer-window)) (selected-frame))) 3. The third fix is to have `1on1-fit-minibuffer-frame' do nothing unless: `this-command' is not eq to `handle-switch-frame. In sum, this is my guess: The creation of the new frame provoked a `switch-frame' event, which, because of `post-command-hook' caused `1on1-fit-minibuffer-frame' to be called a second time, this time with the new frame selected because the last command was `handle-frame-switch'. The bug was in my code. I've wanted to clear this up for a long time, and I think that's done now (including for older Emacs versions, obviously) - thanks to your help. Thank you very much! ---- BTW, in Icicle minor mode I have long used this (which Richard came up with, IIRC), but it clearly did not help with this particular problem: (define-key global-map [handle-switch-frame] 'icicle-skip-this-command) (define-key global-map [switch-frame] 'icicle-handle-switch-frame) where: (defun icicle-skip-this-command () "Prevent `handle-switch-frame' from being added to `this-command'." (interactive) (setq this-command last-command)) (defun icicle-handle-switch-frame (event) "Call `handle-switch-frame', but don't add it to `this-command'." (interactive "e") (handle-switch-frame event) (setq this-command last-command)) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 17 06:00:02 2012 Received: (at 11939) by debbugs.gnu.org; 17 Jul 2012 10:00:02 +0000 Received: from localhost ([127.0.0.1]:45341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr4ZV-0000ZA-45 for submit@debbugs.gnu.org; Tue, 17 Jul 2012 06:00:02 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:33937) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sr4ZS-0000Z3-T1 for 11939@debbugs.gnu.org; Tue, 17 Jul 2012 06:00:00 -0400 Received: (qmail invoked by alias); 17 Jul 2012 09:49:19 -0000 Received: from 62-47-34-58.adsl.highway.telekom.at (EHLO [62.47.34.58]) [62.47.34.58] by mail.gmx.net (mp030) with SMTP; 17 Jul 2012 11:49:19 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/YRR5WynrYfTXBKD2rVZxRBrkCZVQlZVVpDHNQs7 RDjJu2ma1+L5YG Message-ID: <50053558.4040808@gmx.at> Date: Tue, 17 Jul 2012 11:50:16 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > In my code I put command `1on1-fit-minibuffer-frame' on `post-command-hook'. > That function fits the standalone minibuffer frame to its "buffer contents" > (taking Icomplete overlays into account etc.). > > The function assumes that it is called from the minibuffer, i.e., that the > selected frame is the standalone frame. Which it is... Why does that function _assume_ that? It should check it. > But something apparently changed the focus in this case - I'm guessing, as I > said before, that it was the popping up of the new frame. And some second > command is involved at that point - apparently `handle-switch-frame'. So `1on1-fit-minibuffer-frame' assumes that the selected frame is the standalone minibuffer frame and that that frame has focus. Why don't you verify all that in the function's body? > So because of `post-command-hook', `1on1-fit-minibuffer-frame' got called a > second time, and this time with the previously selected frame being selected > (i.e., the frame that was selected prior to entering the minibuffer). The > minibuffer was still active, ... you mean `active-minibuffer-window' returned the window of the minibuffer-only frame ... > but the selected frame was another one (e.g. > *Process List*). > > I came up with three alternative fixes that work - I chose the second one: > > 1. The first fix is to call `select-frame-set-input-focus' at the end of > `1on1-fit-minibuffer-frame'. > > I can tell by debugging using `message' that the frame switch happens outside > `1on1-fit-minibuffer-frame': the selected frame is the minibuffer frame the > first time `1on1-fit-minibuffer-frame' is called, right up till the end. But it > is another frame the next time `1on1-fit-minibuffer-frame' is called, which > appears to be immediately afterward. > > So why does this fix work? Dunno. Even though without adding the call to > `select-frame-set-input-focus' the frame is correct when the first call to > `1on1-fit-minibuffer-frame' ends, if I do not add that call then it is incorrect > for the second `1on1-fit-minibuffer-frame' call. Well that's understandable > from a `switch-frame' event. > > But what's not clear to me is why calling `select-frame-set-input-focus' at the > end of the first call to `1on1-fit-minibuffer-frame' fixes things. As I said, > the frame switch seems to happen between the two calls, yet selecting the > minibuffer frame before the end of the first call solves the problem. Maybe > this has something to do with the redisplay code? No idea. You have two calls from `post-command-hook': The first seems due to `save-buffers-kill-emacs' preliminary terminating with a `yes-or-no-p' question which does not affect frame or focus. The second should come from `handle-switch-frame' as a consequence of emacs being called back by the window manager. IIUC `handle-switch-frame' calls do_switch_frame with TRACK equal 0, so focus is not affected by `handle-switch-frame'. But focus has been redirected to the new frame by the window manager and emacs should probably adapt to that situation because that is the frame that gets the keystrokes. Now if whatever you want to do after `handle-switch-frame' has terminated happens in the new frame, there's no problem. We have a problem if we want to make things happen in another frame and for that purpose we have to redirect focus to that other frame. That's what you apparently do via the `select-frame-set-input-focus' call at the end of the first `post-command-hook' execution since `handle-switch-frame' won't change focus afterwards. Looks like a very fragile hack. > 2. The second fix is to have `1on1-fit-minibuffer-frame' do nothing unless: > > (eq last-event-frame > (save-selected-window > (select-window (minibuffer-window)) (selected-frame))) Is that (eq last-event-frame (window-frame (minibuffer-window)))? This means that you don't do anything in this case so apparently some side-effect gets suppressed. Which side-effect? > 3. The third fix is to have `1on1-fit-minibuffer-frame' do nothing unless: > `this-command' is not eq to `handle-switch-frame. Same as before. What is the side-effect of `1on1-fit-minibuffer-frame'? > In sum, this is my guess: The creation of the new frame provoked a > `switch-frame' event, which, because of `post-command-hook' caused > `1on1-fit-minibuffer-frame' to be called a second time, this time with the new > frame selected because the last command was `handle-frame-switch'. I think you should make sure two things: (1) `1on1-fit-minibuffer-frame' should do something iff the frame in question is a minibuffer frame. (2) `1on1-fit-minibuffer-frame' should avoid having any side-effects wrt window selection or focus unless you explictly want that. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 17 06:15:42 2012 Received: (at 11939) by debbugs.gnu.org; 17 Jul 2012 10:15:42 +0000 Received: from localhost ([127.0.0.1]:45388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr4og-0001mA-Jn for submit@debbugs.gnu.org; Tue, 17 Jul 2012 06:15:42 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52975) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sr4oe-0001m2-Fp for 11939@debbugs.gnu.org; Tue, 17 Jul 2012 06:15:41 -0400 Received: (qmail invoked by alias); 17 Jul 2012 09:49:09 -0000 Received: from 62-47-34-58.adsl.highway.telekom.at (EHLO [62.47.34.58]) [62.47.34.58] by mail.gmx.net (mp020) with SMTP; 17 Jul 2012 11:49:09 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/v3CQ6uBvveDp6Bxj6xLl4oKRTgOlSLIuepRVJZ1 YqgWBRay2/M3so Message-ID: <5005354E.6040306@gmx.at> Date: Tue, 17 Jul 2012 11:50:06 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> In-Reply-To: <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> Content-Type: multipart/mixed; boundary="------------090707010601010507010909" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------090707010601010507010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > (But the *Process List* frame that was popped up was completely > hidden behind the frame that was selected when I hit C-x C-c. That's not good.) Because that code was for experimental purposes only. It's not the task of `with-temp-buffer-window' or its callers to handle that. The problem is elsewhere. I attach the first version of `with-temp-buffer-window', however, with a redefined `y-or-n-p'. Try it with your code but with `yes-or-no-p' aliased to `y-or-n-p'. Here, with emacs -Q (progn (defalias 'yes-or-no-p 'y-or-n-p) (load "~/with-temp-buffer-window.el") (shell) (setq minibuffer-auto-raise t) (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil))))) (setq pop-up-frames t)) C-x C-c creates a minibuffer-less frame for *Process List* and redirects the prompt to the initial *shell* frame. Not 100% perfect because the *shell* frame partly obscures the *Process List* frame but this could be tweaked with a better `pop-up-frame-function'. With the more conventional (progn (defalias 'yes-or-no-p 'y-or-n-p) (load "~/with-temp-buffer-window.el") (shell) (setq pop-up-frames t)) the prompt appears in the *Process List* window. So I suppose that we should (at least optionally) have all functions accessing the minibuffer redirect frame focus to it first. martin --------------090707010601010507010909 Content-Type: application/emacs-lisp; name="with-temp-buffer-window.el" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="with-temp-buffer-window.el" KGRlZnVuIHktb3Itbi1wIChwcm9tcHQpDQogICJBc2sgdXNlciBhIFwieSBvciBuXCIgcXVl c3Rpb24uICBSZXR1cm4gdCBpZiBhbnN3ZXIgaXMgXCJ5XCIuDQpQUk9NUFQgaXMgdGhlIHN0 cmluZyB0byBkaXNwbGF5IHRvIGFzayB0aGUgcXVlc3Rpb24uICBJdCBzaG91bGQNCmVuZCBp biBhIHNwYWNlOyBgeS1vci1uLXAnIGFkZHMgXCIoeSBvciBuKSBcIiB0byBpdC4NCg0KTm8g Y29uZmlybWF0aW9uIG9mIHRoZSBhbnN3ZXIgaXMgcmVxdWVzdGVkOyBhIHNpbmdsZSBjaGFy YWN0ZXIgaXMgZW5vdWdoLg0KQWxzbyBhY2NlcHRzIFNwYWNlIHRvIG1lYW4geWVzLCBvciBE ZWxldGUgdG8gbWVhbiBuby4gIFwoQWN0dWFsbHksIGl0IHVzZXMNCnRoZSBiaW5kaW5ncyBp biBgcXVlcnktcmVwbGFjZS1tYXAnOyBzZWUgdGhlIGRvY3VtZW50YXRpb24gb2YgdGhhdCB2 YXJpYWJsZQ0KZm9yIG1vcmUgaW5mb3JtYXRpb24uICBJbiB0aGlzIGNhc2UsIHRoZSB1c2Vm dWwgYmluZGluZ3MgYXJlIGBhY3QnLCBgc2tpcCcsDQpgcmVjZW50ZXInLCBhbmQgYHF1aXQn LlwpDQoNClVuZGVyIGEgd2luZG93aW5nIHN5c3RlbSBhIGRpYWxvZyBib3ggd2lsbCBiZSB1 c2VkIGlmIGBsYXN0LW5vbm1lbnUtZXZlbnQnDQppcyBuaWwgYW5kIGB1c2UtZGlhbG9nLWJv eCcgaXMgbm9uLW5pbC4iDQogIDs7IMKhQmV3YXJlISB3aGVuIEkgdHJpZWQgdG8gZWRlYnVn IHRoaXMgY29kZSwgRW1hY3MgZ290IGludG8gYSB3ZWlyZCBzdGF0ZQ0KICA7OyB3aGVyZSBh bGwgdGhlIGtleXMgd2VyZSB1bmJvdW5kIChpLmUuIGl0IHNvbWVob3cgZ290IHRyaWdnZXJl ZA0KICA7OyB3aXRoaW4gcmVhZC1rZXksIGFwcGFyZW50bHkpLiAgSSBoYWQgdG8ga2lsbCBp dC4NCiAgKGxldCAoKGFuc3dlciAncmVjZW50ZXIpKQ0KICAgIChjb25kDQogICAgIChub25p bnRlcmFjdGl2ZQ0KICAgICAgKHNldHEgcHJvbXB0IChjb25jYXQgcHJvbXB0DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAoaWYgKGVxID9ccyAoYXJlZiBwcm9tcHQgKDEtIChsZW5n dGggcHJvbXB0KSkpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIiICIgIikN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICIoeSBvciBuKSAiKSkNCiAgICAgIChsZXQg KCh0ZW1wLXByb21wdCBwcm9tcHQpKQ0KCSh3aGlsZSAobm90IChtZW1xIGFuc3dlciAnKGFj dCBza2lwKSkpDQoJICAobGV0ICgoc3RyIChyZWFkLXN0cmluZyB0ZW1wLXByb21wdCkpKQ0K CSAgICAoY29uZCAoKG1lbWJlciBzdHIgJygieSIgIlkiKSkgKHNldHEgYW5zd2VyICdhY3Qp KQ0KCQkgICgobWVtYmVyIHN0ciAnKCJuIiAiTiIpKSAoc2V0cSBhbnN3ZXIgJ3NraXApKQ0K CQkgICh0IChzZXRxIHRlbXAtcHJvbXB0IChjb25jYXQgIlBsZWFzZSBhbnN3ZXIgeSBvciBu LiAgIg0KCQkJCQkgICAgICAgcHJvbXB0KSkpKSkpKSkNCiAgICAgKChhbmQgKGRpc3BsYXkt cG9wdXAtbWVudXMtcCkNCgkgICAobGlzdHAgbGFzdC1ub25tZW51LWV2ZW50KQ0KCSAgIHVz ZS1kaWFsb2ctYm94KQ0KICAgICAgKHNldHEgYW5zd2VyDQoJICAgICh4LXBvcHVwLWRpYWxv ZyB0IGAoLHByb21wdCAoIlllcyIgLiBhY3QpICgiTm8iIC4gc2tpcCkpKSkpDQogICAgICh0 DQogICAgICAoc2V0cSBwcm9tcHQgKGNvbmNhdCBwcm9tcHQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgIChpZiAoZXEgP1xzIChhcmVmIHByb21wdCAoMS0gKGxlbmd0aCBwcm9tcHQp KSkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIiIgIiAiKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIih5IG9yIG4pICIpKQ0KICAgICAgKHdoaWxlDQogICAgICAg ICAgKGxldCogKChrZXkNCiAgICAgICAgICAgICAgICAgIChsZXQgKChjdXJzb3ItaW4tZWNo by1hcmVhIHQpKQ0KICAgICAgICAgICAgICAgICAgICAod2hlbiBtaW5pYnVmZmVyLWF1dG8t cmFpc2UNCiAgICAgICAgICAgICAgICAgICAgICAocmVkaXJlY3QtZnJhbWUtZm9jdXMgKHdp bmRvdy1mcmFtZSAobWluaWJ1ZmZlci13aW5kb3cpKSkpDQogICAgICAgICAgICAgICAgICAg IChyZWFkLWtleSAocHJvcGVydGl6ZSAoaWYgKGVxIGFuc3dlciAncmVjZW50ZXIpDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvbXB0DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjb25jYXQgIlBsZWFz ZSBhbnN3ZXIgeSBvciBuLiAgIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHByb21wdCkpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAnZmFjZSAnbWluaWJ1ZmZlci1wcm9tcHQpKSkpKQ0KICAgICAg ICAgICAgKHNldHEgYW5zd2VyIChsb29rdXAta2V5IHF1ZXJ5LXJlcGxhY2UtbWFwICh2ZWN0 b3Iga2V5KSB0KSkNCiAgICAgICAgICAgIChjb25kDQogICAgICAgICAgICAgKChtZW1xIGFu c3dlciAnKHNraXAgYWN0KSkgbmlsKQ0KICAgICAgICAgICAgICgoZXEgYW5zd2VyICdyZWNl bnRlcikgKHJlY2VudGVyKSB0KQ0KICAgICAgICAgICAgICgobWVtcSBhbnN3ZXIgJyhleGl0 LXByZWZpeCBxdWl0KSkgKHNpZ25hbCAncXVpdCBuaWwpIHQpDQogICAgICAgICAgICAgKHQg dCkpKQ0KICAgICAgICAoZGluZykNCiAgICAgICAgKGRpc2NhcmQtaW5wdXQpKSkpDQogICAg KGxldCAoKHJldCAoZXEgYW5zd2VyICdhY3QpKSkNCiAgICAgICh1bmxlc3Mgbm9uaW50ZXJh Y3RpdmUNCiAgICAgICAgOzsgRklYTUUgdGhpcyBwcmludHMgb25lIHRvbyBtYW55IHNwYWNl cywgc2luY2UgcHJvbXB0DQogICAgICAgIDs7IGFscmVhZHkgZW5kcyBpbiBhIHNwYWNlLiAg RWcgIi4uLiAoeSBvciBuKSAgeSIuDQogICAgICAgIChtZXNzYWdlICIlcyAlcyIgcHJvbXB0 IChpZiByZXQgInkiICJuIikpKQ0KICAgICAgcmV0KSkpDQoNCjs7OyBBdXRvbWF0aWMgcmVz aXppbmcgb2YgdGVtcG9yYXJ5IGJ1ZmZlcnMuDQooZGVmY3VzdG9tIHRlbXAtYnVmZmVyLW1h eC1oZWlnaHQNCiAgKGxhbWJkYSAoYnVmZmVyKQ0KICAgIChpZiAoZXEgKHNlbGVjdGVkLXdp bmRvdykgKGZyYW1lLXJvb3Qtd2luZG93KSkNCgkoLyAoeC1kaXNwbGF5LXBpeGVsLWhlaWdo dCkgKGZyYW1lLWNoYXItaGVpZ2h0KSAyKQ0KICAgICAgKC8gKC0gKGZyYW1lLWhlaWdodCkg MikgMikpKQ0KICAiTWF4aW11bSBoZWlnaHQgb2YgYSB3aW5kb3cgZGlzcGxheWluZyBhIHRl bXBvcmFyeSBidWZmZXIuDQpUaGlzIGlzIGVmZmVjdGl2ZSBvbmx5IHdoZW4gVGVtcCBCdWZm ZXIgUmVzaXplIG1vZGUgaXMgZW5hYmxlZC4NClRoZSB2YWx1ZSBpcyB0aGUgbWF4aW11bSBo ZWlnaHQgKGluIGxpbmVzKSB3aGljaA0KYHJlc2l6ZS10ZW1wLWJ1ZmZlci13aW5kb3cnIHdp bGwgZ2l2ZSB0byBhIHdpbmRvdyBkaXNwbGF5aW5nIGENCnRlbXBvcmFyeSBidWZmZXIuICBJ dCBjYW4gYWxzbyBiZSBhIGZ1bmN0aW9uIHRvIGJlIGNhbGxlZCB0bw0KY2hvb3NlIHRoZSBo ZWlnaHQgZm9yIHN1Y2ggYSBidWZmZXIuICBJdCBnZXRzIG9uZSBhcmd1bWVudCwgdGhlDQpi dWZmZXIsIGFuZCBzaG91bGQgcmV0dXJuIGEgcG9zaXRpdmUgaW50ZWdlci4gIEF0IHRoZSB0 aW1lIHRoZQ0KZnVuY3Rpb24gaXMgY2FsbGVkLCB0aGUgd2luZG93IHRvIGJlIHJlc2l6ZWQg aXMgc2VsZWN0ZWQuIg0KICA6dHlwZSAnKGNob2ljZSBpbnRlZ2VyIGZ1bmN0aW9uKQ0KICA6 Z3JvdXAgJ2hlbHANCiAgOnZlcnNpb24gIjI0LjIiKQ0KDQooZGVmY3VzdG9tIHRlbXAtYnVm ZmVyLXJlc2l6ZS1mcmFtZXMgbmlsDQogICJOb24tbmlsIG1lYW5zIGB0ZW1wLWJ1ZmZlci1y ZXNpemUtbW9kZScgY2FuIHJlc2l6ZSBmcmFtZXMuDQpBIGZyYW1lIGNhbiBiZSByZXNpemVk IGlmIGFuZCBvbmx5IGlmIGl0cyByb290IHdpbmRvdyBpcyBhIGxpdmUNCndpbmRvdy4gIFRo ZSBoZWlnaHQgb2YgdGhlIHJvb3Qgd2luZG93IGlzIHN1YmplY3QgdG8gdGhlIHZhbHVlcyBv Zg0KYHRlbXAtYnVmZmVyLW1heC1oZWlnaHQnIGFuZCBgd2luZG93LW1pbi1oZWlnaHQnLiIN CiAgOnR5cGUgJ2Jvb2xlYW4NCiAgOnZlcnNpb24gIjI0LjIiDQogIDpncm91cCAnaGVscCkN Cg0KKGRlZmluZS1taW5vci1tb2RlIHRlbXAtYnVmZmVyLXJlc2l6ZS1tb2RlDQogICJUb2dn bGUgYXV0by1zaHJpbmtpbmcgdGVtcCBidWZmZXIgd2luZG93cyAoVGVtcCBCdWZmZXIgUmVz aXplIG1vZGUpLg0KV2l0aCBhIHByZWZpeCBhcmd1bWVudCBBUkcsIGVuYWJsZSBUZW1wIEJ1 ZmZlciBSZXNpemUgbW9kZSBpZiBBUkcNCmlzIHBvc2l0aXZlLCBhbmQgZGlzYWJsZSBpdCBv dGhlcndpc2UuICBJZiBjYWxsZWQgZnJvbSBMaXNwLA0KZW5hYmxlIHRoZSBtb2RlIGlmIEFS RyBpcyBvbWl0dGVkIG9yIG5pbC4NCg0KV2hlbiBUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSBp cyBlbmFibGVkLCB0aGUgd2luZG93cyBpbiB3aGljaCB3ZQ0Kc2hvdyBhIHRlbXBvcmFyeSBi dWZmZXIgYXJlIGF1dG9tYXRpY2FsbHkgcmVkdWNlZCBpbiBoZWlnaHQgdG8NCmZpdCB0aGUg YnVmZmVyJ3MgY29udGVudHMsIGJ1dCBuZXZlciBtb3JlIHRoYW4NCmB0ZW1wLWJ1ZmZlci1t YXgtaGVpZ2h0JyBub3IgbGVzcyB0aGFuIGB3aW5kb3ctbWluLWhlaWdodCcuDQoNClRoaXMg bW9kZSBpcyB1c2VkIGJ5IGBoZWxwJywgYGFwcm9wb3MnIGFuZCBgY29tcGxldGlvbicgYnVm ZmVycywNCmFuZCBzb21lIG90aGVycy4iDQogIDpnbG9iYWwgdCA6Z3JvdXAgJ2hlbHANCiAg KGlmIHRlbXAtYnVmZmVyLXJlc2l6ZS1tb2RlDQogICAgICA7OyBgaGVscC1tYWtlLXhyZWZz JyBtYXkgYWRkIGEgYGJhY2snIGJ1dHRvbiBhbmQgdGh1cyBpbmNyZWFzZSB0aGUNCiAgICAg IDs7IHRleHQgc2l6ZSwgc28gYHJlc2l6ZS10ZW1wLWJ1ZmZlci13aW5kb3cnIG11c3QgYmUg cnVuICphZnRlciogaXQuDQogICAgICAoYWRkLWhvb2sgJ3RlbXAtYnVmZmVyLXNob3ctaG9v ayAncmVzaXplLXRlbXAtYnVmZmVyLXdpbmRvdyAnYXBwZW5kKQ0KICAgIChyZW1vdmUtaG9v ayAndGVtcC1idWZmZXItc2hvdy1ob29rICdyZXNpemUtdGVtcC1idWZmZXItd2luZG93KSkp DQoNCihkZWZ1biByZXNpemUtdGVtcC1idWZmZXItd2luZG93ICgmb3B0aW9uYWwgd2luZG93 KQ0KICAiUmVzaXplIFdJTkRPVyB0byBmaXQgaXRzIGNvbnRlbnRzLg0KV0lORE9XIGNhbiBi ZSBhbnkgbGl2ZSB3aW5kb3cgYW5kIGRlZmF1bHRzIHRvIHRoZSBzZWxlY3RlZCBvbmUuDQoN CkRvIG5vdCBtYWtlIFdJTkRPVyBoaWdoZXIgdGhhbiBgdGVtcC1idWZmZXItbWF4LWhlaWdo dCcgbm9yDQpzbWFsbGVyIHRoYW4gYHdpbmRvdy1taW4taGVpZ2h0Jy4gIERvIG5vdGhpbmcg aWYgdGhlIHNlbGVjdGVkDQp3aW5kb3cgaXMgbm90IHZlcnRpY2FsbHkgY29tYmluZWQgb3Ig c29tZSBvZiBpdHMgY29udGVudHMgYXJlDQpzY3JvbGxlZCBvdXQgb2Ygdmlldy4iDQogIChz ZXRxIHdpbmRvdyAod2luZG93LW5vcm1hbGl6ZS13aW5kb3cgd2luZG93IHQpKQ0KICAobGV0 ICgoaGVpZ2h0IChpZiAoZnVuY3Rpb25wIHRlbXAtYnVmZmVyLW1heC1oZWlnaHQpDQoJCSAg ICAoZnVuY2FsbCB0ZW1wLWJ1ZmZlci1tYXgtaGVpZ2h0ICh3aW5kb3ctYnVmZmVyIHdpbmRv dykpDQoJCSAgdGVtcC1idWZmZXItbWF4LWhlaWdodCkpKQ0KICAgIChjb25kDQogICAgICgo YW5kIChwb3MtdmlzaWJsZS1pbi13aW5kb3ctcCAocG9pbnQtbWluKSB3aW5kb3cpDQoJICAg KHdpbmRvdy1jb21iaW5lZC1wIHdpbmRvdykpDQogICAgICAoZml0LXdpbmRvdy10by1idWZm ZXIgd2luZG93IGhlaWdodCkpDQogICAgICgoYW5kIHRlbXAtYnVmZmVyLXJlc2l6ZS1mcmFt ZXMNCgkgICAoZXEgd2luZG93IChmcmFtZS1yb290LXdpbmRvdyB3aW5kb3cpKQ0KCSAgICht ZW1xIChjYXIgKHdpbmRvdy1wYXJhbWV0ZXIgd2luZG93ICdxdWl0LXJlc3RvcmUpKQ0KCQkg OzsgSWYgJ3NhbWUgaXMgdG9vIHN0cm9uZywgd2UgbWlnaHQgYWRkaXRpb25hbGx5IGNoZWNr DQoJCSA7OyB3aGV0aGVyIHRoZSBzZWNvbmQgZWxlbWVudCBpcyAnZnJhbWUuDQoJCSAnKHNh bWUgZnJhbWUpKSkNCiAgICAgIChsZXQgKChmcmFtZSAod2luZG93LWZyYW1lIHdpbmRvdykp KQ0KCShmaXQtZnJhbWUtdG8tYnVmZmVyDQoJIGZyYW1lICgrIChmcmFtZS1oZWlnaHQgZnJh bWUpDQoJCSAgKC0gKHdpbmRvdy10b3RhbC1zaXplIHdpbmRvdykpDQoJCSAgaGVpZ2h0KSkp KSkpKQ0KDQooZGVmdmFyIHRlbXAtYnVmZmVyLXdpbmRvdy1zZXR1cC1ob29rIG5pbA0KICAi Tm9ybWFsIGhvb2sgcnVuIGJ5IGB3aXRoLXRlbXAtYnVmZmVyLXdpbmRvdycgYmVmb3JlIGJ1 ZmZlciBkaXNwbGF5Lg0KVGhpcyBob29rIGlzIHJ1biBieSBgd2l0aC10ZW1wLWJ1ZmZlci13 aW5kb3cnIHdpdGggdGhlIGJ1ZmZlciB0byBiZQ0KZGlzcGxheWVkIGN1cnJlbnQuIikNCg0K KGRlZnZhciB0ZW1wLWJ1ZmZlci13aW5kb3ctc2hvdy1ob29rIG5pbA0KICAiTm9ybWFsIGhv b2sgcnVuIGJ5IGB3aXRoLXRlbXAtYnVmZmVyLXdpbmRvdycgYWZ0ZXIgYnVmZmVyIGRpc3Bs YXkuDQpUaGlzIGhvb2sgaXMgcnVuIGJ5IGB3aXRoLXRlbXAtYnVmZmVyLXdpbmRvdycgd2l0 aCB0aGUgYnVmZmVyDQpkaXNwbGF5ZWQgYW5kIGN1cnJlbnQgYW5kIGl0cyB3aW5kb3cgc2Vs ZWN0ZWQuIikNCg0KKGRlZnVuIHRlbXAtYnVmZmVyLXdpbmRvdy1zZXR1cCAoYnVmZmVyLW9y LW5hbWUpDQogICJTZXQgdXAgdGVtcG9yYXJ5IGJ1ZmZlciBzcGVjaWZpZWQgYnkgQlVGRkVS LU9SLU5BTUUgDQpSZXR1cm4gdGhlIGJ1ZmZlci4iDQogIChsZXQgKChvbGQtZGlyIGRlZmF1 bHQtZGlyZWN0b3J5KQ0KCShidWZmZXIgKGdldC1idWZmZXItY3JlYXRlIGJ1ZmZlci1vci1u YW1lKSkpDQogICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmZmVyDQogICAgICAoa2lsbC1h bGwtbG9jYWwtdmFyaWFibGVzKQ0KICAgICAgKHNldHEgZGVmYXVsdC1kaXJlY3Rvcnkgb2xk LWRpcikNCjs7ICAgICAgIChkZWxldGUtYWxsLW92ZXJsYXlzKQ0KICAgICAgKHNldHEgYnVm ZmVyLXJlYWQtb25seSBuaWwpDQogICAgICAoc2V0cSBidWZmZXItZmlsZS1uYW1lIG5pbCkN CiAgICAgIChzZXRxIGJ1ZmZlci11bmRvLWxpc3QgdCkNCiAgICAgIChsZXQgKChpbmhpYml0 LXJlYWQtb25seSB0KQ0KCSAgICAoaW5oaWJpdC1tb2RpZmljYXRpb24taG9va3MgdCkpDQoJ KGVyYXNlLWJ1ZmZlcikNCgkocnVuLWhvb2tzICd0ZW1wLWJ1ZmZlci13aW5kb3ctc2V0dXAt aG9vaykpDQogICAgICA7OyBSZXR1cm4gdGhlIGJ1ZmZlci4NCiAgICAgIGJ1ZmZlcikpKQ0K DQooZGVmdW4gdGVtcC1idWZmZXItd2luZG93LXNob3cgKCZvcHRpb25hbCBidWZmZXIpDQog ICJTaG93IHRlbXBvcmFyeSBidWZmZXIgQlVGRkVSIGluIGEgd2luZG93Lg0KUmV0dXJuIHRo ZSB3aW5kb3cgc2hvd2luZyBCVUZGRVIuIg0KICAobGV0ICh3aW5kb3cgZnJhbWUpDQogICAg KHdpdGgtY3VycmVudC1idWZmZXIgYnVmZmVyDQogICAgICAoc2V0LWJ1ZmZlci1tb2RpZmll ZC1wIG5pbCkNCiAgICAgIChzZXRxIGJ1ZmZlci1yZWFkLW9ubHkgdCkNCiAgICAgIChnb3Rv LWNoYXIgKHBvaW50LW1pbikpDQogICAgICAod2hlbiAoc2V0cSB3aW5kb3cgKGRpc3BsYXkt YnVmZmVyIGJ1ZmZlcikpDQoJKHNldHEgZnJhbWUgKHdpbmRvdy1mcmFtZSB3aW5kb3cpKQ0K CSh1bmxlc3MgKGVxIGZyYW1lIChzZWxlY3RlZC1mcmFtZSkpDQoJICAocmFpc2UtZnJhbWUg ZnJhbWUpKQ0KCShzZXRxIG1pbmlidWZmZXItc2Nyb2xsLXdpbmRvdyB3aW5kb3cpDQoJKHNl dC13aW5kb3ctaHNjcm9sbCB3aW5kb3cgMCkNCgkod2l0aC1zZWxlY3RlZC13aW5kb3cgd2lu ZG93DQoJICAocnVuLWhvb2tzICd0ZW1wLWJ1ZmZlci13aW5kb3ctc2hvdy1ob29rKQ0KCSAg KHdoZW4gdGVtcC1idWZmZXItcmVzaXplLW1vZGUNCgkgICAgKHJlc2l6ZS10ZW1wLWJ1ZmZl ci13aW5kb3cgd2luZG93KSkpDQoJOzsgUmV0dXJuIHRoZSB3aW5kb3cuDQoJd2luZG93KSkp KQ0KDQooZGVmbWFjcm8gd2l0aC10ZW1wLWJ1ZmZlci13aW5kb3cgKGJ1ZmZlci1vci1uYW1l IHF1aXQtZnVuY3Rpb24gJnJlc3QgYm9keSkNCiAgIkV2YWx1YXRlIEJPRFkgYW5kIGRpc3Bs YXkgYnVmZmVyIHNwZWNpZmllZCBieSBCVUZGRVItT1ItTkFNRS4NCkJVRkZFUi1PUi1OQU1F IG11c3Qgc3BlY2lmeSBlaXRoZXIgYSBsaXZlIGJ1ZmZlciBvciB0aGUgbmFtZSBvZiBhDQpi dWZmZXIuICBJZiBubyBidWZmZXIgd2l0aCBzdWNoIGEgbmFtZSBleGlzdHMsIGNyZWF0ZSBv bmUuDQoNCk1ha2Ugc3VyZSB0aGUgc3BlY2lmaWVkIGJ1ZmZlciBpcyBlbXB0eSBiZWZvcmUg ZXZhbHVhdGluZyBCT0RZLg0KRG8gbm90IG1ha2UgdGhhdCBidWZmZXIgY3VycmVudCBmb3Ig Qk9EWS4gIEluc3RlYWQsIGJpbmQNCmBzdGFuZGFyZC1vdXRwdXQnIHRvIHRoYXQgYnVmZmVy LCBzbyB0aGF0IG91dHB1dCBnZW5lcmF0ZWQgd2l0aA0KYHByaW4xJyBhbmQgc2ltaWxhciBm dW5jdGlvbnMgaW4gQk9EWSBnb2VzIGludG8gdGhhdCBidWZmZXIuDQoNCkFmdGVyIGV2YWx1 YXRpbmcgQk9EWSwgbWFyayB0aGUgc3BlY2lmaWVkIGJ1ZmZlciB1bm1vZGlmaWVkIGFuZA0K cmVhZC1vbmx5IGFuZCBkaXNwbGF5IGl0IGluIGEgd2luZG93LiAgQXV0by1zaHJpbmsgdGhl IHdpbmRvdyBpZg0KYHRlbXAtYnVmZmVyLXJlc2l6ZS1tb2RlJyBpcyBlbmFibGVkLg0KDQpS ZXR1cm4gdGhlIHZhbHVlIHJldHVybmVkIGJ5IEJPRFkgdW5sZXNzIFFVSVQtRlVOQ1RJT04g c3BlY2lmaWVzDQphIGZ1bmN0aW9uLiAgSW4gdGhhdCBjYXNlLCBydW4gdGhlIGZ1bmN0aW9u IHdpdGggdHdvIGFyZ3VtZW50cyAtDQp0aGUgd2luZG93IHNob3dpbmcgdGhlIHNwZWNpZmll ZCBidWZmZXIgYW5kIHRoZSB2YWx1ZSByZXR1cm5lZCBieQ0KQk9EWSAtIGFuZCByZXR1cm4g dGhlIHZhbHVlIHJldHVybmVkIGJ5IHRoYXQgZnVuY3Rpb24uDQoNClRoaXMgY29uc3RydWN0 IGlzIHNpbWlsYXIgdG8gYHdpdGgtb3V0cHV0LXRvLXRlbXAtYnVmZmVyJyBidXQNCmRvZXMg bmVpdGhlciBwdXQgdGhlIGJ1ZmZlciBpbiBoZWxwIG1vZGUgbm9yIGRvZXMgaXQgY2FsbA0K YHRlbXAtYnVmZmVyLXNob3ctZnVuY3Rpb24nLiAgSXQgYWxzbyBydW5zIGRpZmZlcmVudCBo b29rcywNCm5hbWVseSBgdGVtcC1idWZmZXItd2luZG93LXNldHVwLWhvb2snICh3aXRoIHRo ZSBzcGVjaWZpZWQgYnVmZmVyDQpjdXJyZW50KSBhbmQgYHRlbXAtYnVmZmVyLXdpbmRvdy1z aG93LWhvb2snICh3aXRoIHRoZSBzcGVjaWZpZWQNCmJ1ZmZlciBjdXJyZW50IGFuZCB0aGUg d2luZG93IHNob3dpbmcgaXQgc2VsZWN0ZWQpLg0KDQpTaW5jZSB0aGlzIG1hY3JvIGNhbGxz IGBkaXNwbGF5LWJ1ZmZlcicsIHRoZSB3aW5kb3cgZGlzcGxheWluZw0KdGhlIGJ1ZmZlciBp cyB1c3VhbGx5IG5vdCBzZWxlY3RlZCBhbmQgdGhlIHNwZWNpZmllZCBidWZmZXINCnVzdWFs bHkgbm90IG1hZGUgY3VycmVudC4gIFFVSVQtRlVOQ1RJT04gY2FuIG92ZXJyaWRlIHRoYXQu Ig0KICAoZGVjbGFyZSAoZGVidWcgdCkpDQogIChsZXQgKChidWZmZXIgKG1ha2Utc3ltYm9s ICJidWZmZXIiKSkNCgkod2luZG93IChtYWtlLXN5bWJvbCAid2luZG93IikpDQoJKHZhbHVl IChtYWtlLXN5bWJvbCAidmFsdWUiKSkpDQogICAgYChsZXQqICgoLGJ1ZmZlciAodGVtcC1i dWZmZXItd2luZG93LXNldHVwICxidWZmZXItb3ItbmFtZSkpDQoJICAgIChzdGFuZGFyZC1v dXRwdXQgLGJ1ZmZlcikNCgkgICAgLHdpbmRvdyAsdmFsdWUpDQogICAgICAgKHdpdGgtY3Vy cmVudC1idWZmZXIgLGJ1ZmZlcg0KCSAoc2V0cSAsdmFsdWUgKHByb2duICxAYm9keSkpDQoJ IChzZXRxICx3aW5kb3cgKHRlbXAtYnVmZmVyLXdpbmRvdy1zaG93ICxidWZmZXIpKSkNCg0K ICAgICAgIChpZiAoZnVuY3Rpb25wICxxdWl0LWZ1bmN0aW9uKQ0KCSAgIChmdW5jYWxsICxx dWl0LWZ1bmN0aW9uICx3aW5kb3cgLHZhbHVlKQ0KCSAsdmFsdWUpKSkpDQoNCihkZWZ1biB3 aW5kb3ctLWRpc3BsYXktYnVmZmVyIChidWZmZXIgd2luZG93IHR5cGUgJm9wdGlvbmFsIGRl ZGljYXRlZCkNCiAgIkRpc3BsYXkgQlVGRkVSIGluIFdJTkRPVyBhbmQgbWFrZSBpdHMgZnJh bWUgdmlzaWJsZS4NClRZUEUgbXVzdCBiZSBvbmUgb2YgdGhlIHN5bWJvbHMgYHJldXNlJywg YHdpbmRvdycgb3IgYGZyYW1lJyBhbmQNCmlzIHBhc3NlZCB1bmFsdGVyZWQgdG8gYGRpc3Bs YXktYnVmZmVyLXJlY29yZC13aW5kb3cnLiBTZXQNCmB3aW5kb3ctZGVkaWNhdGVkLXAnIHRv IERFRElDQVRFRCBpZiBub24tbmlsLiAgUmV0dXJuIFdJTkRPVyBpZg0KQlVGRkVSIGFuZCBX SU5ET1cgYXJlIGxpdmUuIg0KICAod2hlbiAoYW5kIChidWZmZXItbGl2ZS1wIGJ1ZmZlcikg KHdpbmRvdy1saXZlLXAgd2luZG93KSkNCiAgICAobGV0KiAoKGZyYW1lICh3aW5kb3ctZnJh bWUgd2luZG93KSkNCgkgICAodmlzaWJsZSAoZnJhbWUtdmlzaWJsZS1wIGZyYW1lKSkpDQog ICAgICAoZGlzcGxheS1idWZmZXItcmVjb3JkLXdpbmRvdyB0eXBlIHdpbmRvdyBidWZmZXIp DQogICAgICAodW5sZXNzIChlcSBidWZmZXIgKHdpbmRvdy1idWZmZXIgd2luZG93KSkNCgko c2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCB3aW5kb3cgbmlsKQ0KCShzZXQtd2luZG93LWJ1ZmZl ciB3aW5kb3cgYnVmZmVyKQ0KCSh3aGVuIGRlZGljYXRlZA0KCSAgKHNldC13aW5kb3ctZGVk aWNhdGVkLXAgd2luZG93IGRlZGljYXRlZCkpKQ0KICAgICAgKHdoZW4gKG1lbXEgdHlwZSAn KHdpbmRvdyBmcmFtZSkpDQoJKHNldC13aW5kb3ctcHJldi1idWZmZXJzIHdpbmRvdyBuaWwp KQ0KDQogICAgICAodW5sZXNzIChvciAobm90IHZpc2libGUpDQoJCSAgOzsgQXNzdW1lIHRo ZSBzZWxlY3RlZCBmcmFtZSBpcyBhbHJlYWR5IHZpc2libGUgZW5vdWdoLg0KCQkgIChlcSBm cmFtZSAoc2VsZWN0ZWQtZnJhbWUpKQ0KCQkgIDs7IEFzc3VtZSB0aGUgZnJhbWUgZnJvbSB3 aGljaCB3ZSBpbnZva2VkIHRoZSBtaW5pYnVmZmVyDQoJCSAgOzsgaXMgdmlzaWJsZS4NCgkJ ICAoYW5kIChtaW5pYnVmZmVyLXdpbmRvdy1hY3RpdmUtcCAoc2VsZWN0ZWQtd2luZG93KSkN CgkJICAgICAgIChlcSBmcmFtZSAod2luZG93LWZyYW1lIChtaW5pYnVmZmVyLXNlbGVjdGVk LXdpbmRvdykpKSkpDQoJKHJhaXNlLWZyYW1lIGZyYW1lKSkNCg0KICAgICAgd2luZG93KSkp DQoNCihkZWZ1biBxdWl0LXJlc3RvcmUtd2luZG93ICgmb3B0aW9uYWwgd2luZG93IGJ1cnkt b3Ita2lsbCkNCiAgIlF1aXQgV0lORE9XIGFuZCBkZWFsIHdpdGggaXRzIGJ1ZmZlci4NCldJ TkRPVyBtdXN0IGJlIGEgbGl2ZSB3aW5kb3cgYW5kIGRlZmF1bHRzIHRvIHRoZSBzZWxlY3Rl ZCBvbmUuDQoNCkFjY29yZGluZyB0byBpbmZvcm1hdGlvbiBzdG9yZWQgaW4gV0lORE9XJ3Mg YHF1aXQtcmVzdG9yZScgd2luZG93DQpwYXJhbWV0ZXIgZWl0aGVyICgxKSBkZWxldGUgV0lO RE9XIGFuZCBpdHMgZnJhbWUsICgyKSBkZWxldGUNCldJTkRPVywgKDMpIHJlc3RvcmUgdGhl IGJ1ZmZlciBwcmV2aW91c2x5IGRpc3BsYXllZCBpbiBXSU5ET1csDQpvciAoNCkgbWFrZSBX SU5ET1cgZGlzcGxheSBzb21lIG90aGVyIGJ1ZmZlciB0aGFuIHRoZSBwcmVzZW50DQpvbmUu ICBJZiBub24tbmlsLCByZXNldCBgcXVpdC1yZXN0b3JlJyBwYXJhbWV0ZXIgdG8gbmlsLg0K DQpPcHRpb25hbCBzZWNvbmQgYXJndW1lbnQgQlVSWS1PUi1LSUxMIHRlbGxzIGhvdyB0byBw cm9jZWVkIHdpdGgNCnRoZSBidWZmZXIgb2YgV0lORE9XLiAgVGhlIGZvbGxvd2luZyB2YWx1 ZXMgYXJlIGhhbmRsZWQ6DQoNCmBuaWwnIG1lYW5zIHRvIG5vdCBoYW5kbGUgdGhlIGJ1ZmZl ciBpbiBhIHBhcnRpY3VsYXIgd2F5LiAgVGhpcw0KICBtZWFucyB0aGF0IGlmIFdJTkRPVyBp cyBub3QgZGVsZXRlZCBieSB0aGlzIGZ1bmN0aW9uLCBpbnZva2luZw0KICBgc3dpdGNoLXRv LXByZXYtYnVmZmVyJyB3aWxsIHVzdWFsbHkgc2hvdyB0aGUgYnVmZmVyIGFnYWluLg0KDQpg YXBwZW5kJyBtZWFucyB0aGF0IGlmIFdJTkRPVyBpcyBub3QgZGVsZXRlZCwgbW92ZSBpdHMg YnVmZmVyIHRvDQogIHRoZSBlbmQgb2YgV0lORE9XJ3MgcHJldmlvdXMgYnVmZmVycyBzbyBp dCdzIGxlc3MgbGlrZWx5IHRoYXQgYQ0KICBmdXR1cmUgaW52b2NhdGlvbiBvZiBgc3dpdGNo LXRvLXByZXYtYnVmZmVyJyB3aWxsIHN3aXRjaCB0byBpdC4NCiAgQWxzbywgbW92ZSB0aGUg YnVmZmVyIHRvIHRoZSBlbmQgb2YgdGhlIGZyYW1lJ3MgYnVmZmVyIGxpc3QuDQoNCmBidXJ5 JyBtZWFucyB0aGF0IGlmIFdJTkRPVyBpcyBub3QgZGVsZXRlZCwgcmVtb3ZlIGl0cyBidWZm ZXINCiAgZnJvbSBXSU5ET1cnUyBsaXN0IG9mIHByZXZpb3VzIGJ1ZmZlcnMuICBBbHNvLCBt b3ZlIHRoZSBidWZmZXINCiAgdG8gdGhlIGVuZCBvZiB0aGUgZnJhbWUncyBidWZmZXIgbGlz dC4gIFRoaXMgdmFsdWUgcHJvdmlkZXMgdGhlDQogIG1vc3QgcmVsaWFibGUgcmVtZWR5IHRv IG5vdCBoYXZlIGBzd2l0Y2gtdG8tcHJldi1idWZmZXInIHN3aXRjaA0KICB0byB0aGlzIGJ1 ZmZlciBhZ2FpbiB3aXRob3V0IGtpbGxpbmcgdGhlIGJ1ZmZlci4NCg0KYGtpbGwnIG1lYW5z IHRvIGtpbGwgV0lORE9XJ3MgYnVmZmVyLiINCiAgKHNldHEgd2luZG93ICh3aW5kb3ctbm9y bWFsaXplLXdpbmRvdyB3aW5kb3cgdCkpDQogIChsZXQqICgoYnVmZmVyICh3aW5kb3ctYnVm ZmVyIHdpbmRvdykpDQoJIChxdWl0LXJlc3RvcmUgKHdpbmRvdy1wYXJhbWV0ZXIgd2luZG93 ICdxdWl0LXJlc3RvcmUpKQ0KCSAocHJldi1idWZmZXINCgkgIChsZXQqICgocHJldi1idWZm ZXJzICh3aW5kb3ctcHJldi1idWZmZXJzIHdpbmRvdykpDQoJCSAocHJldi1idWZmZXIgKGNh YXIgcHJldi1idWZmZXJzKSkpDQoJICAgIChhbmQgKG9yIChub3QgKGVxIHByZXYtYnVmZmVy IGJ1ZmZlcikpDQoJCSAgICAgKGFuZCAoY2RyIHByZXYtYnVmZmVycykNCgkJCSAgKG5vdCAo ZXEgKHNldHEgcHJldi1idWZmZXIgKGNhZHIgcHJldi1idWZmZXJzKSkNCgkJCQkgICBidWZm ZXIpKSkpDQoJCSBwcmV2LWJ1ZmZlcikpKQ0KCSBxdWFkIGVudHJ5KQ0KICAgIChjb25kDQog ICAgICgoYW5kIChub3QgcHJldi1idWZmZXIpDQoJICAgKG1lbXEgKG50aCAxIHF1aXQtcmVz dG9yZSkgJyh3aW5kb3cgZnJhbWUpKQ0KCSAgIChlcSAobnRoIDMgcXVpdC1yZXN0b3JlKSBi dWZmZXIpDQoJICAgOzsgRGVsZXRlIFdJTkRPVyBpZiBwb3NzaWJsZS4NCgkgICAod2luZG93 LS1kZWxldGUgd2luZG93IG5pbCAoZXEgYnVyeS1vci1raWxsICdraWxsKSkpDQogICAgICA7 OyBJZiB0aGUgcHJldmlvdXNseSBzZWxlY3RlZCB3aW5kb3cgaXMgc3RpbGwgYWxpdmUsIHNl bGVjdCBpdC4NCiAgICAgICh3aGVuICh3aW5kb3ctbGl2ZS1wIChudGggMiBxdWl0LXJlc3Rv cmUpKQ0KCShzZWxlY3Qtd2luZG93IChudGggMiBxdWl0LXJlc3RvcmUpKSkpDQogICAgICgo YW5kIChsaXN0cCAoc2V0cSBxdWFkIChudGggMSBxdWl0LXJlc3RvcmUpKSkNCgkgICAoYnVm ZmVyLWxpdmUtcCAoY2FyIHF1YWQpKQ0KCSAgIChlcSAobnRoIDMgcXVpdC1yZXN0b3JlKSBi dWZmZXIpKQ0KICAgICAgOzsgU2hvdyBhbm90aGVyIGJ1ZmZlciBzdG9yZWQgaW4gcXVpdC1y ZXN0b3JlIHBhcmFtZXRlci4NCiAgICAgICh3aGVuIChhbmQgKGludGVnZXJwIChudGggMyBx dWFkKSkNCgkJICgvPSAobnRoIDMgcXVhZCkgKHdpbmRvdy10b3RhbC1zaXplIHdpbmRvdykp KQ0KCTs7IFRyeSB0byByZXNpemUgV0lORE9XIHRvIGl0cyBvbGQgaGVpZ2h0IGJ1dCBkb24n dCBzaWduYWwgYW4NCgk7OyBlcnJvci4NCgkoY29uZGl0aW9uLWNhc2UgbmlsDQoJICAgICh3 aW5kb3ctcmVzaXplIHdpbmRvdyAoLSAobnRoIDMgcXVhZCkgKHdpbmRvdy10b3RhbC1zaXpl IHdpbmRvdykpKQ0KCSAgKGVycm9yIG5pbCkpKQ0KICAgICAgKHNldC13aW5kb3ctZGVkaWNh dGVkLXAgd2luZG93IG5pbCkNCiAgICAgIDs7IFJlc3RvcmUgV0lORE9XJ3MgcHJldmlvdXMg YnVmZmVyLCBzdGFydCBhbmQgcG9pbnQgcG9zaXRpb24uDQogICAgICAoc2V0LXdpbmRvdy1i dWZmZXItc3RhcnQtYW5kLXBvaW50DQogICAgICAgd2luZG93IChudGggMCBxdWFkKSAobnRo IDEgcXVhZCkgKG50aCAyIHF1YWQpKQ0KICAgICAgOzsgRGVhbCB3aXRoIHRoZSBidWZmZXIg d2UganVzdCByZW1vdmVkIGZyb20gV0lORE9XLg0KICAgICAgKHNldHEgZW50cnkgKGFuZCAo ZXEgYnVyeS1vci1raWxsICdhcHBlbmQpDQoJCSAgICAgICAoYXNzcSBidWZmZXIgKHdpbmRv dy1wcmV2LWJ1ZmZlcnMgd2luZG93KSkpKQ0KICAgICAgKHdoZW4gYnVyeS1vci1raWxsDQoJ OzsgUmVtb3ZlIGJ1ZmZlciBmcm9tIFdJTkRPVydzIHByZXZpb3VzIGFuZCBuZXh0IGJ1ZmZl cnMuDQoJKHNldC13aW5kb3ctcHJldi1idWZmZXJzDQoJIHdpbmRvdyAoYXNzcS1kZWxldGUt YWxsIGJ1ZmZlciAod2luZG93LXByZXYtYnVmZmVycyB3aW5kb3cpKSkNCgkoc2V0LXdpbmRv dy1uZXh0LWJ1ZmZlcnMNCgkgd2luZG93IChkZWxxIGJ1ZmZlciAod2luZG93LW5leHQtYnVm ZmVycyB3aW5kb3cpKSkpDQogICAgICAod2hlbiBlbnRyeQ0KCTs7IEFwcGVuZCBvbGQgYnVm ZmVyJ3MgZW50cnkgdG8gbGlzdCBvZiBXSU5ET1cncyBwcmV2aW91cw0KCTs7IGJ1ZmZlcnMg c28gaXQncyBsZXNzIGxpa2VseSB0byBnZXQgc3dpdGNoZWQgdG8gc29vbiBidXQNCgk7OyBg ZGlzcGxheS1idWZmZXItaW4tcHJldmlvdXMtd2luZG93JyBjYW4gbmV2ZXJ0aGVsZXNzIGZp bmQgaXQuDQoJKHNldC13aW5kb3ctcHJldi1idWZmZXJzDQoJIHdpbmRvdyAoYXBwZW5kICh3 aW5kb3ctcHJldi1idWZmZXJzIHdpbmRvdykgKGxpc3QgZW50cnkpKSkpDQogICAgICA7OyBS ZXNldCB0aGUgcXVpdC1yZXN0b3JlIHBhcmFtZXRlci4NCiAgICAgIChzZXQtd2luZG93LXBh cmFtZXRlciB3aW5kb3cgJ3F1aXQtcmVzdG9yZSBuaWwpDQogICAgICA7OyBTZWxlY3Qgb2xk IHdpbmRvdy4NCiAgICAgICh3aGVuICh3aW5kb3ctbGl2ZS1wIChudGggMiBxdWl0LXJlc3Rv cmUpKQ0KCShzZWxlY3Qtd2luZG93IChudGggMiBxdWl0LXJlc3RvcmUpKSkpDQogICAgICh0 DQogICAgICA7OyBTaG93IHNvbWUgb3RoZXIgYnVmZmVyIGluIFdJTkRPVyBhbmQgcmVzZXQg dGhlIHF1aXQtcmVzdG9yZQ0KICAgICAgOzsgcGFyYW1ldGVyLg0KICAgICAgKHNldC13aW5k b3ctcGFyYW1ldGVyIHdpbmRvdyAncXVpdC1yZXN0b3JlIG5pbCkNCiAgICAgIDs7IE1ha2Ug c3VyZSB0aGF0IFdJTkRPVyBpcyBubyBtb3JlIGRlZGljYXRlZC4NCiAgICAgIChzZXQtd2lu ZG93LWRlZGljYXRlZC1wIHdpbmRvdyBuaWwpDQogICAgICAoc3dpdGNoLXRvLXByZXYtYnVm ZmVyIHdpbmRvdyBidXJ5LW9yLWtpbGwpKSkNCg0KICAgIDs7IERlYWwgd2l0aCB0aGUgYnVm ZmVyLg0KICAgIChjb25kDQogICAgICgobm90IChidWZmZXItbGl2ZS1wIGJ1ZmZlcikpKQ0K ICAgICAoKGVxIGJ1cnktb3Ita2lsbCAna2lsbCkNCiAgICAgIChraWxsLWJ1ZmZlciBidWZm ZXIpKQ0KICAgICAoYnVyeS1vci1raWxsDQogICAgICAoYnVyeS1idWZmZXItaW50ZXJuYWwg YnVmZmVyKSkpKSkNCg0KKGRlZnVuIHF1aXQtd2luZG93ICgmb3B0aW9uYWwga2lsbCB3aW5k b3cpDQogICJRdWl0IFdJTkRPVyBhbmQgYnVyeSBpdHMgYnVmZmVyLg0KV0lORE9XIG11c3Qg YmUgYSBsaXZlIHdpbmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhlIHNlbGVjdGVkIG9uZS4NCldp dGggcHJlZml4IGFyZ3VtZW50IEtJTEwgbm9uLW5pbCwga2lsbCB0aGUgYnVmZmVyIGluc3Rl YWQgb2YNCmJ1cnlpbmcgaXQuDQoNCkFjY29yZGluZyB0byBpbmZvcm1hdGlvbiBzdG9yZWQg aW4gV0lORE9XJ3MgYHF1aXQtcmVzdG9yZScgd2luZG93DQpwYXJhbWV0ZXIgZWl0aGVyICgx KSBkZWxldGUgV0lORE9XIGFuZCBpdHMgZnJhbWUsICgyKSBkZWxldGUNCldJTkRPVywgKDMp IHJlc3RvcmUgdGhlIGJ1ZmZlciBwcmV2aW91c2x5IGRpc3BsYXllZCBpbiBXSU5ET1csDQpv ciAoNCkgbWFrZSBXSU5ET1cgZGlzcGxheSBzb21lIG90aGVyIGJ1ZmZlciB0aGFuIHRoZSBw cmVzZW50DQpvbmUuICBJZiBub24tbmlsLCByZXNldCBgcXVpdC1yZXN0b3JlJyBwYXJhbWV0 ZXIgdG8gbmlsLiINCiAgKGludGVyYWN0aXZlICJQIikNCiAgKHF1aXQtcmVzdG9yZS13aW5k b3cgd2luZG93IChpZiBraWxsICdraWxsICdidXJ5KSkpDQoNCihkZWZjdXN0b20gZml0LWZy YW1lLXRvLWJ1ZmZlci1ib3R0b20tbWFyZ2luIDQNCiAgIkJvdHRvbSBtYXJnaW4gZm9yIGBm aXQtZnJhbWUtdG8tYnVmZmVyJy4NClRoaXMgaXMgdGhlIG51bWJlciBvZiBsaW5lcyBgZml0 LWZyYW1lLXRvLWJ1ZmZlcicgbGVhdmVzIGZyZWUgYXQgdGhlDQpib3R0b20gb2YgdGhlIGRp c3BsYXkgaW4gb3JkZXIgdG8gbm90IG9ic2N1cmUgdGhlIHN5c3RlbSB0YXNrIGJhci4iDQog IDp0eXBlICdpbnRlZ2VyDQogIDp2ZXJzaW9uICIyNC4yIg0KICA6Z3JvdXAgJ3dpbmRvd3Mp DQoNCihkZWZ1biBmaXQtZnJhbWUtdG8tYnVmZmVyICgmb3B0aW9uYWwgZnJhbWUgbWF4LWhl aWdodCBtaW4taGVpZ2h0KQ0KICAiQWRqdXN0IGhlaWdodCBvZiBGUkFNRSB0byBkaXNwbGF5 IGl0cyBidWZmZXIncyBjb250ZW50cyBleGFjdGx5Lg0KRlJBTUUgY2FuIGJlIGFueSBsaXZl IGZyYW1lIGFuZCBkZWZhdWx0cyB0byB0aGUgc2VsZWN0ZWQgb25lLg0KDQpPcHRpb25hbCBh cmd1bWVudCBNQVgtSEVJR0hUIHNwZWNpZmllcyB0aGUgbWF4aW11bSBoZWlnaHQgb2YNCkZS QU1FIGFuZCBkZWZhdWx0cyB0byB0aGUgaGVpZ2h0IG9mIHRoZSBkaXNwbGF5IGJlbG93IHRo ZSBjdXJyZW50DQp0b3AgbGluZSBvZiBGUkFNRSBtaW51cyBGSVQtRlJBTUUtVE8tQlVGRkVS LUJPVFRPTS1NQVJHSU4uDQpPcHRpb25hbCBhcmd1bWVudCBNSU4tSEVJR0hUIHNwZWNpZmll cyB0aGUgbWluaW11bSBoZWlnaHQgb2YNCkZSQU1FLiINCiAgKGludGVyYWN0aXZlKQ0KICAo c2V0cSBmcmFtZSAod2luZG93LW5vcm1hbGl6ZS1mcmFtZSBmcmFtZSkpDQogIChsZXQqICgo cm9vdCAoZnJhbWUtcm9vdC13aW5kb3cgZnJhbWUpKQ0KCSAoZnJhbWUtbWluLWhlaWdodA0K CSAgKCsgKC0gKGZyYW1lLWhlaWdodCBmcmFtZSkgKHdpbmRvdy10b3RhbC1zaXplIHJvb3Qp KQ0KCSAgICAgd2luZG93LW1pbi1oZWlnaHQpKQ0KCSAoZnJhbWUtdG9wIChmcmFtZS1wYXJh bWV0ZXIgZnJhbWUgJ3RvcCkpDQoJICh0b3AgKGlmIChjb25zcCBmcmFtZS10b3ApDQoJCSAg KGZ1bmNhbGwgKGNhciBmcmFtZS10b3ApIChjYWRyIGZyYW1lLXRvcCkpDQoJCWZyYW1lLXRv cCkpDQoJIChmcmFtZS1tYXgtaGVpZ2h0DQoJICAoLSAoLyAoLSAoeC1kaXNwbGF5LXBpeGVs LWhlaWdodCBmcmFtZSkgdG9wKQ0KCQkoZnJhbWUtY2hhci1oZWlnaHQgZnJhbWUpKQ0KCSAg ICAgZml0LWZyYW1lLXRvLWJ1ZmZlci1ib3R0b20tbWFyZ2luKSkNCgkgZGVsdGEpDQogICAg KHdoZW4gKGFuZCAod2luZG93LWxpdmUtcCByb290KSAobm90ICh3aW5kb3ctc2l6ZS1maXhl ZC1wIHJvb3QpKSkNCiAgICAgICh3aXRoLXNlbGVjdGVkLXdpbmRvdyByb290DQoJKGNvbmQN CgkgKChub3QgbWF4LWhlaWdodCkNCgkgIChzZXRxIG1heC1oZWlnaHQgZnJhbWUtbWF4LWhl aWdodCkpDQoJICgobnVtYmVycCBtYXgtaGVpZ2h0KQ0KCSAgKHNldHEgbWF4LWhlaWdodCAo bWluIG1heC1oZWlnaHQgZnJhbWUtbWF4LWhlaWdodCkpKQ0KCSAodA0KCSAgKGVycm9yICIl cyBpcyBhbiBpbnZhbGlkIG1heGltdW0gaGVpZ2h0IiBtYXgtaGVpZ2h0KSkpDQoJKGNvbmQN CgkgKChub3QgbWluLWhlaWdodCkNCgkgIChzZXRxIG1pbi1oZWlnaHQgZnJhbWUtbWluLWhl aWdodCkpDQoJICgobnVtYmVycCBtaW4taGVpZ2h0KQ0KCSAgKHNldHEgbWluLWhlaWdodCAo bWluIG1pbi1oZWlnaHQgZnJhbWUtbWluLWhlaWdodCkpKQ0KCSAodA0KCSAgKGVycm9yICIl cyBpcyBhbiBpbnZhbGlkIG1pbmltdW0gaGVpZ2h0IiBtaW4taGVpZ2h0KSkpDQoJKHNldHEg ZGVsdGENCgkgICAgICA7OyBDb3VudCBhIGZpbmFsIG5ld2xpbmUgLSB0aGlzIGNvbXBlbnNh dGVzIGZvciB0aGUNCgkgICAgICA7OyBtaXNzaW5nIHBvc3QtcHJvY2VzaW5nIHBhcnQgYWZ0 ZXIgcmVzaXppbmcgdGhlIGZyYW1lLg0KCSAgICAgICgtICgrIChjb3VudC1zY3JlZW4tbGlu ZXMgbmlsIG5pbCB0KQ0KCQkgICAgOzsgRm9yIG5vbi1taW5pYnVmZmVycyBjb3VudCB0aGUg bW9kZSBsaW5lLCBpZiBhbnkuDQoJCSAgICAoaWYgKGFuZCAobm90ICh3aW5kb3ctbWluaWJ1 ZmZlci1wKSkNCgkJCSAgICAgbW9kZS1saW5lLWZvcm1hdCkNCgkJCTENCgkJICAgICAgMCkN CgkJICAgIDs7IENvdW50IHRoZSBoZWFkZXIgbGluZSwgaWYgYW55Lg0KCQkgICAgKGlmIGhl YWRlci1saW5lLWZvcm1hdCAxIDApKQ0KCQkgKHdpbmRvdy10b3RhbC1zaXplKSkpKQ0KICAg ICAgOzsgTW92ZSBhd2F5IGZyb20gZmluYWwgbmV3bGluZS4NCiAgICAgICh3aGVuIChhbmQg KGVvYnApIChib2xwKSAobm90IChib2JwKSkpDQoJKHNldC13aW5kb3ctcG9pbnQgcm9vdCAo bGluZS1iZWdpbm5pbmctcG9zaXRpb24gMCkpKQ0KICAgICAgKHNldC13aW5kb3ctc3RhcnQg cm9vdCAocG9pbnQtbWluKSkNCiAgICAgIChzZXQtd2luZG93LXZzY3JvbGwgcm9vdCAwKQ0K ICAgICAgKGNvbmRpdGlvbi1jYXNlIG5pbA0KCSAgKHNldC1mcmFtZS1oZWlnaHQNCgkgICBm cmFtZQ0KCSAgIChtaW4gKG1heCAoKyAoZnJhbWUtaGVpZ2h0IGZyYW1lKSBkZWx0YSkNCgkJ ICAgICBtaW4taGVpZ2h0KQ0KCQltYXgtaGVpZ2h0KSkNCgkoZXJyb3IgKHNldHEgZGVsdGEg bmlsKSkpKQ0KICAgIGRlbHRhKSkNCg0KOzsgVXNhZ2UNCihkZWZ1biByZWNvdmVyLWZpbGUg KGZpbGUpDQogICJWaXNpdCBmaWxlIEZJTEUsIGJ1dCBnZXQgY29udGVudHMgZnJvbSBpdHMg bGFzdCBhdXRvLXNhdmUgZmlsZS4iDQogIDs7IEFjdHVhbGx5IHB1dHRpbmcgdGhlIGZpbGUg bmFtZSBpbiB0aGUgbWluaWJ1ZmZlciBzaG91bGQgYmUgdXNlZA0KICA7OyBvbmx5IHJhcmVs eS4NCiAgOzsgTm90IGp1c3QgYmVjYXVzZSB1c2VycyBvZnRlbiB1c2UgdGhlIGRlZmF1bHQu DQogIChpbnRlcmFjdGl2ZSAiRlJlY292ZXIgZmlsZTogIikNCiAgKHNldHEgZmlsZSAoZXhw YW5kLWZpbGUtbmFtZSBmaWxlKSkNCiAgKGlmIChhdXRvLXNhdmUtZmlsZS1uYW1lLXAgKGZp bGUtbmFtZS1ub25kaXJlY3RvcnkgZmlsZSkpDQogICAgICAoZXJyb3IgIiVzIGlzIGFuIGF1 dG8tc2F2ZSBmaWxlIiAoYWJicmV2aWF0ZS1maWxlLW5hbWUgZmlsZSkpKQ0KICAobGV0ICgo ZmlsZS1uYW1lIChsZXQgKChidWZmZXItZmlsZS1uYW1lIGZpbGUpKQ0KCQkgICAgIChtYWtl LWF1dG8tc2F2ZS1maWxlLW5hbWUpKSkpDQogICAgKGNvbmQgKChpZiAoZmlsZS1leGlzdHMt cCBmaWxlKQ0KCSAgICAgICAobm90IChmaWxlLW5ld2VyLXRoYW4tZmlsZS1wIGZpbGUtbmFt ZSBmaWxlKSkNCgkgICAgIChub3QgKGZpbGUtZXhpc3RzLXAgZmlsZS1uYW1lKSkpDQoJICAg KGVycm9yICJBdXRvLXNhdmUgZmlsZSAlcyBub3QgY3VycmVudCINCgkJICAoYWJicmV2aWF0 ZS1maWxlLW5hbWUgZmlsZS1uYW1lKSkpDQoJICAoKHdpdGgtdGVtcC1idWZmZXItd2luZG93 DQoJICAgICIqRGlyZWN0b3J5KiINCgkgICAgIycobGFtYmRhICh3aW5kb3cgX3ZhbHVlKQ0K CQkodW53aW5kLXByb3RlY3QNCgkJICAgICh5ZXMtb3Itbm8tcCAoZm9ybWF0ICJSZWNvdmVy IGF1dG8gc2F2ZSBmaWxlICVzPyAiIGZpbGUtbmFtZSkpDQoJCSAgKHF1aXQtcmVzdG9yZS13 aW5kb3cgd2luZG93ICdraWxsKSkpDQoJICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyIHN0YW5k YXJkLW91dHB1dA0KCSAgICAgIChsZXQgKChzd2l0Y2hlcyBkaXJlZC1saXN0aW5nLXN3aXRj aGVzKSkNCgkJKGlmIChmaWxlLXN5bWxpbmstcCBmaWxlKQ0KCQkgICAgKHNldHEgc3dpdGNo ZXMgKGNvbmNhdCBzd2l0Y2hlcyAiIC1MIikpKQ0KCQk7OyBVc2UgaW5zZXJ0LWRpcmVjdG9y eS1zYWZlbHksIG5vdCBpbnNlcnQtZGlyZWN0b3J5LA0KCQk7OyBiZWNhdXNlIHRoZXNlIGZp bGVzIG1pZ2h0IG5vdCBleGlzdC4gIEluIHBhcnRpY3VsYXIsDQoJCTs7IEZJTEUgbWlnaHQg bm90IGV4aXN0IGlmIHRoZSBhdXRvLXNhdmUgZmlsZSB3YXMgZm9yDQoJCTs7IGEgYnVmZmVy IHRoYXQgZGlkbid0IHZpc2l0IGEgZmlsZSwgc3VjaCBhcyAiKm1haWwqIi4NCgkJOzsgVGhl IGNvZGUgaW4gdjIwLnggY2FsbGVkIGBscycgZGlyZWN0bHksIHNvIHdlIG5lZWQNCgkJOzsg dG8gZW11bGF0ZSB3aGF0IGBscycgZGlkIGluIHRoYXQgY2FzZS4NCgkJKGluc2VydC1kaXJl Y3Rvcnktc2FmZWx5IGZpbGUgc3dpdGNoZXMpDQoJCShpbnNlcnQtZGlyZWN0b3J5LXNhZmVs eSBmaWxlLW5hbWUgc3dpdGNoZXMpKSkpDQoJICAgKHN3aXRjaC10by1idWZmZXIgKGZpbmQt ZmlsZS1ub3NlbGVjdCBmaWxlIHQpKQ0KCSAgIChsZXQgKChpbmhpYml0LXJlYWQtb25seSB0 KQ0KCQkgOzsgS2VlcCB0aGUgY3VycmVudCBidWZmZXItZmlsZS1jb2Rpbmctc3lzdGVtLg0K CQkgKGNvZGluZy1zeXN0ZW0gYnVmZmVyLWZpbGUtY29kaW5nLXN5c3RlbSkNCgkJIDs7IEF1 dG8tc2F2ZWQgZmlsZSBzaG91bGQgYmUgcmVhZCB3aXRoIHNwZWNpYWwgY29kaW5nLg0KCQkg KGNvZGluZy1zeXN0ZW0tZm9yLXJlYWQgJ2F1dG8tc2F2ZS1jb2RpbmcpKQ0KCSAgICAgKGVy YXNlLWJ1ZmZlcikNCgkgICAgIChpbnNlcnQtZmlsZS1jb250ZW50cyBmaWxlLW5hbWUgbmls KQ0KCSAgICAgKHNldC1idWZmZXItZmlsZS1jb2Rpbmctc3lzdGVtIGNvZGluZy1zeXN0ZW0p KQ0KCSAgIChhZnRlci1maW5kLWZpbGUgbmlsIG5pbCB0KSkNCgkgICh0ICh1c2VyLWVycm9y ICJSZWNvdmVyLWZpbGUgY2FuY2VsbGVkIikpKSkpDQoNCihkZWZ1biBzYXZlLWJ1ZmZlcnMt a2lsbC1lbWFjcyAoJm9wdGlvbmFsIGFyZykNCiAgIk9mZmVyIHRvIHNhdmUgZWFjaCBidWZm ZXIsIHRoZW4ga2lsbCB0aGlzIEVtYWNzIHByb2Nlc3MuDQpXaXRoIHByZWZpeCBBUkcsIHNp bGVudGx5IHNhdmUgYWxsIGZpbGUtdmlzaXRpbmcgYnVmZmVycyB3aXRob3V0IGFza2luZy4N CklmIHRoZXJlIGFyZSBhY3RpdmUgcHJvY2Vzc2VzIHdoZXJlIGBwcm9jZXNzLXF1ZXJ5LW9u LWV4aXQtZmxhZycNCnJldHVybnMgbm9uLW5pbCwgYXNrcyB3aGV0aGVyIHByb2Nlc3NlcyBz aG91bGQgYmUga2lsbGVkLg0KUnVucyB0aGUgbWVtYmVycyBvZiBga2lsbC1lbWFjcy1xdWVy eS1mdW5jdGlvbnMnIGluIHR1cm4gYW5kIHN0b3BzDQppZiBhbnkgcmV0dXJucyBuaWwuICBJ ZiBgY29uZmlybS1raWxsLWVtYWNzJyBpcyBub24tbmlsLCBjYWxscyBpdC4iDQogIChpbnRl cmFjdGl2ZSAiUCIpDQogIChzYXZlLXNvbWUtYnVmZmVycyBhcmcgdCkNCiAgKGFuZCAob3Ig KG5vdCAobWVtcSB0IChtYXBjYXIgKGZ1bmN0aW9uDQoJCQkJICAobGFtYmRhIChidWYpIChh bmQgKGJ1ZmZlci1maWxlLW5hbWUgYnVmKQ0KCQkJCQkJICAgICAoYnVmZmVyLW1vZGlmaWVk LXAgYnVmKSkpKQ0KCQkJCShidWZmZXItbGlzdCkpKSkNCgkgICAoeWVzLW9yLW5vLXAgIk1v ZGlmaWVkIGJ1ZmZlcnMgZXhpc3Q7IGV4aXQgYW55d2F5PyAiKSkNCiAgICAgICAob3IgKG5v dCAoZmJvdW5kcCAncHJvY2Vzcy1saXN0KSkNCgkgICA7OyBwcm9jZXNzLWxpc3QgaXMgbm90 IGRlZmluZWQgb24gTVNET1MuDQoJICAgKGxldCAoKHByb2Nlc3NlcyAocHJvY2Vzcy1saXN0 KSkNCgkJIGFjdGl2ZSkNCgkgICAgICh3aGlsZSBwcm9jZXNzZXMNCgkgICAgICAgKGFuZCAo bWVtcSAocHJvY2Vzcy1zdGF0dXMgKGNhciBwcm9jZXNzZXMpKSAnKHJ1biBzdG9wIG9wZW4g bGlzdGVuKSkNCgkJICAgIChwcm9jZXNzLXF1ZXJ5LW9uLWV4aXQtZmxhZyAoY2FyIHByb2Nl c3NlcykpDQoJCSAgICAoc2V0cSBhY3RpdmUgdCkpDQoJICAgICAgIChzZXRxIHByb2Nlc3Nl cyAoY2RyIHByb2Nlc3NlcykpKQ0KCSAgICAgKG9yIChub3QgYWN0aXZlKQ0KCQkgKHdpdGgt dGVtcC1idWZmZXItd2luZG93IChnZXQtYnVmZmVyLWNyZWF0ZSAiKlByb2Nlc3MgTGlzdCoi KQ0KCQkgICAjJyhsYW1iZGEgKHdpbmRvdyBfdmFsdWUpDQoJCSAgICAgICAodW53aW5kLXBy b3RlY3QNCgkJCSAgICh3aXRoLXNlbGVjdGVkLXdpbmRvdyB3aW5kb3cNCgkJCSAgICAgKHll cy1vci1uby1wICJBY3RpdmUgcHJvY2Vzc2VzIGV4aXN0OyBraWxsIHRoZW0gYW5kIGV4aXQg YW55d2F5PyAiKSkNCgkJCSAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgJ2tpbGwpKSkN CgkJICAgKGxpc3QtcHJvY2Vzc2VzIHQpKSkpKQ0KICAgICAgIDs7IFF1ZXJ5IHRoZSB1c2Vy IGZvciBvdGhlciB0aGluZ3MsIHBlcmhhcHMuDQogICAgICAgKHJ1bi1ob29rLXdpdGgtYXJn cy11bnRpbC1mYWlsdXJlICdraWxsLWVtYWNzLXF1ZXJ5LWZ1bmN0aW9ucykNCiAgICAgICAo b3IgKG51bGwgY29uZmlybS1raWxsLWVtYWNzKQ0KCSAgIChmdW5jYWxsIGNvbmZpcm0ta2ls bC1lbWFjcyAiUmVhbGx5IGV4aXQgRW1hY3M/ICIpKQ0KICAgICAgIChraWxsLWVtYWNzKSkp DQoNCihkZWZ1biBkaXJlZC1tYXJrLXBvcC11cCAoYnVmZmVyLW9yLW5hbWUgb3Atc3ltYm9s IGZpbGVzIGZ1bmN0aW9uICZyZXN0IGFyZ3MpDQogICJSZXR1cm4gRlVOQ1RJT04ncyByZXN1 bHQgb24gQVJHUyBhZnRlciBzaG93aW5nIHdoaWNoIGZpbGVzIGFyZSBtYXJrZWQuDQpEaXNw bGF5cyB0aGUgZmlsZSBuYW1lcyBpbiBhIHdpbmRvdyBzaG93aW5nIGEgYnVmZmVyIG5hbWVk DQpCVUZGRVItT1ItTkFNRTsgdGhlIGRlZmF1bHQgbmFtZSBiZWluZyBcIiAqTWFya2VkIEZp bGVzKlwiLiAgVGhlDQp3aW5kb3cgaXMgbm90IHNob3duIGlmIHRoZXJlIGlzIGp1c3Qgb25l IGZpbGUsIGBkaXJlZC1uby1jb25maXJtJw0KaXMgdCwgb3IgT1AtU1lNQk9MIGlzIGEgbWVt YmVyIG9mIHRoZSBsaXN0IGluIGBkaXJlZC1uby1jb25maXJtJy4NCg0KRklMRVMgaXMgdGhl IGxpc3Qgb2YgbWFya2VkIGZpbGVzLiAgSXQgY2FuIGFsc28gYmUgKHQgRklMRU5BTUUpDQpp biB0aGUgY2FzZSBvZiBvbmUgbWFya2VkIGZpbGUsIHRvIGRpc3Rpbmd1aXNoIHRoYXQgZnJv bSB1c2luZw0KanVzdCB0aGUgY3VycmVudCBmaWxlLg0KDQpGVU5DVElPTiBzaG91bGQgbm90 IG1hbmlwdWxhdGUgZmlsZXMsIGp1c3QgcmVhZCBpbnB1dCBcKGFuDQphcmd1bWVudCBvciBj b25maXJtYXRpb24pLiINCiAgKGlmIChvciAoZXEgZGlyZWQtbm8tY29uZmlybSB0KQ0KCSAg KG1lbXEgb3Atc3ltYm9sIGRpcmVkLW5vLWNvbmZpcm0pDQoJICA7OyBJZiBGSUxFUyBkZWZh dWx0ZWQgdG8gdGhlIGN1cnJlbnQgbGluZSdzIGZpbGUuDQoJICAoPSAobGVuZ3RoIGZpbGVz KSAxKSkNCiAgICAgIChhcHBseSBmdW5jdGlvbiBhcmdzKQ0KICAgIChsZXQgKChidWZmZXIg KGdldC1idWZmZXItY3JlYXRlIChvciBidWZmZXItb3ItbmFtZSAiICpNYXJrZWQgRmlsZXMq IikpKSkNCiAgICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyIGJ1ZmZlcg0KCShsZXQgKChzcGxp dC1oZWlnaHQtdGhyZXNob2xkIDApDQoJICAgICAgKGRpc3BsYXktYnVmZmVyLWFwcC1hY3Rp b24NCgkgICAgICAgKGNvbnMgJ2Rpc3BsYXktYnVmZmVyLWJlbG93LXNlbGVjdGVkIG5pbCkp KQ0KCSAgKHdpdGgtdGVtcC1idWZmZXItd2luZG93DQoJICAgYnVmZmVyDQoJICAgIycobGFt YmRhICh3aW5kb3cgX3ZhbHVlKQ0KCSAgICAgICAodW53aW5kLXByb3RlY3QNCgkJICAgKGFw cGx5IGZ1bmN0aW9uIGFyZ3MpDQoJCSAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgJ2tp bGwpKSkNCgkgICA7OyBIYW5kbGUgKHQgRklMRSkganVzdCBsaWtlIChGSUxFKSwgaGVyZS4g IFRoYXQgdmFsdWUgaXMNCgkgICA7OyB1c2VkIChvbmx5IGluIHNvbWUgY2FzZXMpLCB0byBt ZWFuIGp1c3Qgb25lIGZpbGUgdGhhdCB3YXMNCgkgICA7OyBtYXJrZWQsIHJhdGhlciB0aGFu IHRoZSBjdXJyZW50IGxpbmUgZmlsZS4NCgkgICAoZGlyZWQtZm9ybWF0LWNvbHVtbnMtb2Yt ZmlsZXMNCgkgICAgKGlmIChlcSAoY2FyIGZpbGVzKSB0KSAoY2RyIGZpbGVzKSBmaWxlcykp DQoJICAgKHJlbW92ZS10ZXh0LXByb3BlcnRpZXMgKHBvaW50LW1pbikgKHBvaW50LW1heCkN CgkJCQkgICAnKG1vdXNlLWZhY2UgbmlsIGhlbHAtZWNobyBuaWwpKSkpKSkpKQ0K --------------090707010601010507010909-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 17 10:28:58 2012 Received: (at 11939) by debbugs.gnu.org; 17 Jul 2012 14:28:58 +0000 Received: from localhost ([127.0.0.1]:46263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr8ll-0001lS-SM for submit@debbugs.gnu.org; Tue, 17 Jul 2012 10:28:58 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:42340) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr8lk-0001lL-Co for 11939@debbugs.gnu.org; Tue, 17 Jul 2012 10:28:57 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6HEMshn030539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 14:22:55 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6HEMrAB003318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 14:22:54 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6HEMrVg017214; Tue, 17 Jul 2012 09:22:53 -0500 Received: from dradamslap1 (/10.159.216.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Jul 2012 07:22:53 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Tue, 17 Jul 2012 07:22:36 -0700 Message-ID: <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5005354E.6040306@gmx.at> Thread-Index: Ac1kBEhYiPqw4fWUTW2nlHZdLBmkjAAIl0Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > I attach the first version of `with-temp-buffer-window', > however, with a redefined `y-or-n-p'. Try it with your code but with > `yes-or-no-p' aliased to `y-or-n-p'. > > Here, with emacs -Q > (progn > (defalias 'yes-or-no-p 'y-or-n-p) > (load "~/with-temp-buffer-window.el") > (shell) > (setq minibuffer-auto-raise t) > (setq pop-up-frame-function > (lambda () (make-frame '((minibuffer . nil))))) > (setq pop-up-frames t)) I did this: 1. Used my setup. Then did the defalias. Then loaded your file. Then `M-x shell'. Then `C-x C-c'. Then `y'. No problem. 2. emacs -Q, then used your code above, but first loaded cygwin-mount.el and setup-cygwin.el. C-x C-c. No problem. HTH. BTW, you did not answer my question of how you get shell etc. to work on Windows with emacs -Q and without Cygwin. I'm still interested to learn what you are doing in that regard. > I suppose that we should (at least optionally) have all functions > accessing the minibuffer redirect frame focus to it first. I thought that was already the case - it seems to be. In the problem reported for this bug the minibuffer frame had the focus, but it then lost it because of a frame switch (I mean, because a new frame creation by Windows switched the focus). From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 17 11:27:45 2012 Received: (at 11939) by debbugs.gnu.org; 17 Jul 2012 15:27:45 +0000 Received: from localhost ([127.0.0.1]:46290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr9ge-0004lf-Hp for submit@debbugs.gnu.org; Tue, 17 Jul 2012 11:27:45 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:38928) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr9ga-0004lW-JF for 11939@debbugs.gnu.org; Tue, 17 Jul 2012 11:27:42 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6HFLcDB006352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 15:21:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6HFLbEu028494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2012 15:21:38 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6HFLb7X002155; Tue, 17 Jul 2012 10:21:37 -0500 Received: from dradamslap1 (/10.159.216.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Jul 2012 08:21:37 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Tue, 17 Jul 2012 08:21:19 -0700 Message-ID: <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50053558.4040808@gmx.at> Thread-Index: Ac1kAhd3AdXT8xxMQsGcihuYKqmLjgAJY6cg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > The function assumes that it is called from the > > minibuffer, i.e., that the selected frame is the standalone frame. > > Which it is... > > Why does that function _assume_ that? It should check it. It does now. I did not realize that creation of a new frame by MS Windows with the minibuffer frame selected (& having the focus) would change the focus. And I did not realize that such a change in focus would provoke another invocation of that function (via command `handle-switch-frame', apparently), with the minibuffer frame unfocused. > So `1on1-fit-minibuffer-frame' assumes that the selected frame is the > standalone minibuffer frame and that that frame has focus. Why don't > you verify all that in the function's body? See above - you already asked that. It _is_ the minibuffer frame for the call that I expected. I did not expect the second call provoked by the frame switch command (via post-command-hook), with the wrong frame focused. > > The minibuffer was still active, > > ... you mean `active-minibuffer-window' returned the window of the > minibuffer-only frame ... No, I meant only that the minibuffer was still active: accepting typed input. My next sentence made it clear that the minibuffer-only frame was NOT selected: > > but the selected frame was another one (e.g. *Process List*). Now maybe there is no real notion of a minibuffer being active, and it is more correct to speak of an minibuffer _window_ being active. I was describing things from a (possibly naive) user perspective: a `read-from-minibuffer' was still in progress; the minibuffer was in principle available for entering text (but its window was not selected). IOW, if it were selected it would accept input. > > I came up with three alternative fixes that work - I chose > > the second one: > > > > 1. The first fix is to call `select-frame-set-input-focus' > > at the end of `1on1-fit-minibuffer-frame'. > > > > But what's not clear to me is why calling > >`select-frame-set-input-focus' at the > > end of the first call to `1on1-fit-minibuffer-frame' fixes > > things. As I said, the frame switch seems to happen between > > the two calls, yet selecting the minibuffer frame before the > > end of the first call solves the problem. Maybe > > this has something to do with the redisplay code? No idea. > > You have two calls from `post-command-hook': The first seems due to > `save-buffers-kill-emacs' preliminary terminating with a `yes-or-no-p' > question which does not affect frame or focus. Yes. The focus is in the minibuffer frame. AFAICT, each time `read-from-minibuffer' is called the focus (correctly) moves to that frame. I have not noticed any case where that did not happen. Do you think there are such cases? > The second should come from `handle-switch-frame' as a consequence > of emacs being called back by the window manager. That's what I surmised also. > IIUC `handle-switch-frame' calls do_switch_frame with TRACK equal 0, > so focus is not affected by `handle-switch-frame'. OK. I'm not familiar with the code, but it's good to know that `h-s-f' (and presumably also `switch-frame') do not affect focus. I have not noticed that. In fact, I thought that switching frames always did seem to change the focus. But perhaps it is something else and not just `h-s-f' that actually causes the focus change (e.g. when you click another frame with the mouse). Perhaps it is (always?) the window mgr that changes the focus? > But focus has been redirected to the new frame by the window > manager and emacs should probably adapt to that situation because > that is the frame that gets the keystrokes. Sounds like a plan. > Now if whatever you want to do after `handle-switch-frame' has > terminated happens in the new frame, there's no problem. We have a > problem if we want to make things happen in another frame and for that > purpose we have to redirect focus to that other frame. > > That's what you apparently do via the `select-frame-set-input-focus' > call at the end of the first `post-command-hook' execution since > `handle-switch-frame' won't change focus afterwards. Yes, but it's still not clear to me just what is going on here. The window mgr changes the focus when it creates the new frame. But `1on1-fit-minibuffer-frame' is invoked via `post-command-hook', which means that there is a command that initiates it. I was thinking that that command must be `h-s-f', and my testing seemed to confirm that (see fix #3, below), but if it is not I would like to know what it really is. If the focus change happens via the window mgr after `1on1-fit-minibuffer-frame', and if `h-s-f' then provokes the second call to `1on1-fit-minibuffer-frame', how can resetting the focus to the minibuffer frame before the end of the first `1on1-fit-minibuffer-frame' solve the problem? That resetting would need to take place after the window mgr changed the focus, no? It seems therefor like the window mgr changes the focus _before_ the end of the first `1on1-fit-minibuffer-frame'. But if I add a `message' call at the end, it shows that the focus is still in the minibuffer frame. That is what I do not understand: On the one hand, the focus seems to remain in the minibuffer frame throughout the first call to `1-f-m-f'. On the other hand, explicitly setting the focus to the minibuffer frame at the end of `1-f-m-f' solves the problem. Can you explain that? > Looks like a very fragile hack. Which is why I picked the second fix. And I still am not clear why the first fix works - see previous. > > 2. The second fix is to have `1on1-fit-minibuffer-frame' > > do nothing unless: > > (eq last-event-frame > > (save-selected-window > > (select-window (minibuffer-window)) (selected-frame))) > > Is that (eq last-event-frame (window-frame (minibuffer-window)))? Duh. Thanks. > This means that you don't do anything in this case so apparently some > side-effect gets suppressed. Which side-effect? What the function does: fit the minibuffer frame to its displayed content. As I said, the function should be a no-op if the minibuffer is not active or the minibuffer frame is not in focus. FYI, this is the full condition under which it will not be a no-op: ;; We could assume the minibuffer frame is `1on1-minibuffer-frame', but we do not. (and 1on1-fit-minibuffer-frame-flag (active-minibuffer-window) ;; Do this because this command is on `post-command-hook', ;; and an event such as `handle-switch-frame' might have ;; changed the selected frame. (eq last-event-frame (window-frame (minibuffer-window))) (save-selected-window (select-window (minibuffer-window)) ;; We should be able to use just (one-window-p), ;; but an Emacs bug means we need this: (one-window-p nil 'selected-frame))) Perhaps you see some improvement/simplification possible there. (I don't recall what Emacs bug was involved wrt the last clause or what release that bug is in, FWIW.) And yes, I know that you feel that `one-window-p' is not the right way to check for one-windowness. But I need this to work for multiple Emacs versions, and so far I've found that `one-window-p' DTRT. Still, I'm open to suggestions if you see an improvement here. > > 3. The third fix is to have `1on1-fit-minibuffer-frame' do > > nothing unless: `this-command' is not eq to `handle-switch-frame. > > Same as before. What is the side-effect of `1on1-fit-minibuffer-frame'? Same as before. This is just a different way to make the function a no-op. Testing seemed to show that `this-command' is `handle-switch-frame' in the problematic case. But perhaps this is fragile also (perhaps there are additional commands where it should be a no-op). Which is why I picked fix #2. > > In sum, this is my guess: The creation of the new frame provoked a > > `switch-frame' event, which, because of `post-command-hook' caused > > `1on1-fit-minibuffer-frame' to be called a second time, > > this time with the new frame selected because the last command > > was `handle-frame-switch'. > > I think you should make sure two things: (1) > `1on1-fit-minibuffer-frame' should do something iff the frame in > question is a minibuffer frame. What do you mean by "a minibuffer frame"? It just has a non-nil `minibuffer' parameter? Or that parameter has a value of `only'? Or something else? Is the following test not sufficient to ensure that it is "a minibuffer frame"? (eq last-event-frame (window-frame (minibuffer-window))) Let me know if you think I should add an additional test or replace that test with another. > (2) `1on1-fit-minibuffer-frame' should avoid having any > side-effects wrt window selection or focus unless you explictly want that. That is the case - it has no side effects wrt window selection or focus. The selection window and the focus are at the end what they were at the beginning. All it does, when it is not a no-op, is (maybe) resize and reposition the minibuffer frame. Thx. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 18 12:21:26 2012 Received: (at 11939) by debbugs.gnu.org; 18 Jul 2012 16:21:26 +0000 Received: from localhost ([127.0.0.1]:48744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrX0A-0000Q5-3J for submit@debbugs.gnu.org; Wed, 18 Jul 2012 12:21:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:42209) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SrX07-0000Pw-7L for 11939@debbugs.gnu.org; Wed, 18 Jul 2012 12:21:24 -0400 Received: (qmail invoked by alias); 18 Jul 2012 16:15:14 -0000 Received: from 62-47-60-60.adsl.highway.telekom.at (EHLO [62.47.60.60]) [62.47.60.60] by mail.gmx.net (mp017) with SMTP; 18 Jul 2012 18:15:14 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/03t0WmYH0LlciiXVs73dRe1sCUmJ9htb1upSoQo s17lGSHK5vcXOZ Message-ID: <5006E14B.3000407@gmx.at> Date: Wed, 18 Jul 2012 18:16:11 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> In-Reply-To: <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> Content-Type: multipart/mixed; boundary="------------070709030607050701050304" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------070709030607050701050304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > 1. Used my setup. Then did the defalias. Then loaded your file. Then `M-x > shell'. Then `C-x C-c'. Then `y'. No problem. See below. > BTW, you did not answer my question of how you get shell etc. to work on Windows > with emacs -Q and without Cygwin. I'm still interested to learn what you are > doing in that regard. I'm using cmd.exe. >> I suppose that we should (at least optionally) have all functions >> accessing the minibuffer redirect frame focus to it first. > > I thought that was already the case - it seems to be. In the problem reported > for this bug the minibuffer frame had the focus, but it then lost it because of > a frame switch (I mean, because a new frame creation by Windows switched the > focus). As a matter of fact `yes-or-no-p' indirectly calls read_minibuf which does if (!EQ (mini_frame, selected_frame)) Fredirect_frame_focus (selected_frame, mini_frame); So focus is redirected but somehow this doesn't always work when popping up a new frame. In any case, it's not necessary to do the defaliasing, `yes-or-no-p' should do the same, in principle. Moreover, my `redirect-frame-focus' call in `y-or-n-p' was silly because I mixed up the arguments. So let's forget about this. I still don't understand the consequences described in the doc-string of `redirect-frame-focus' as A frame's focus redirection can be changed by `select-frame'. If frame FOO is selected, and then a different frame BAR is selected, any frames redirecting their focus to FOO are shifted to redirect their focus to BAR. This allows focus redirection to work properly when the user switches from one frame to another using `select-window'. This means that a frame whose focus is redirected to itself is treated differently from a frame whose focus is redirected to nil; the former is affected by `select-frame', while the latter is not. so there might be still some surprises around the corner. IMHO the thing that's crucial is that if you want to peruse a separate minibuffer frame after popping up a new frame, you have to do it from the freshly popped up frame. For example, if you pop up a new frame and then want to ask a `yes-or-no-p' question, you have to select the new frame, issue the `yes-or-no-p' there, and hope that read_minibuf correctly redirects the prompt to the minibuffer frame. If `minibuffer-auto-raise' is non-nil, this will raise the minibuffer frame, otherwise it will only redirect input to that frame. I suppose that was already your understanding of this issue but I was surprised that issuing the `yes-or-no-p' from an old frame won't work. So I attach yet another version of `with-temp-buffer-window'. Please test it with (progn (load "~/with-temp-buffer-window.el") (shell) (setq minibuffer-auto-raise t) ; Optional (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil))))) (setq pop-up-frames t)) (progn (setq pop-up-frames t) (load "~/with-temp-buffer-window.el") (shell)) and with your usual settings and tell me what you see. Also test it with `minibuffer-auto-raise' either nil or t. Finally, try to exit it in various ways, for example by deleting some frame during the dialogue. I found a not yet 100% reproducible way to crash Emacs doing that. If the above work, test also the delete files in dired scenario. The first dialogue will probably fail in the usual way, then you have to load `with-temp-buffer-window.el' once more and try another time. Thanks, martin --------------070709030607050701050304 Content-Type: application/emacs-lisp; name="with-temp-buffer-window.el" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="with-temp-buffer-window.el" Ozs7IEF1dG9tYXRpYyByZXNpemluZyBvZiB0ZW1wb3JhcnkgYnVmZmVycy4NCihkZWZjdXN0 b20gdGVtcC1idWZmZXItbWF4LWhlaWdodA0KICAobGFtYmRhIChidWZmZXIpDQogICAgKGlm IChlcSAoc2VsZWN0ZWQtd2luZG93KSAoZnJhbWUtcm9vdC13aW5kb3cpKQ0KCSgvICh4LWRp c3BsYXktcGl4ZWwtaGVpZ2h0KSAoZnJhbWUtY2hhci1oZWlnaHQpIDIpDQogICAgICAoLyAo LSAoZnJhbWUtaGVpZ2h0KSAyKSAyKSkpDQogICJNYXhpbXVtIGhlaWdodCBvZiBhIHdpbmRv dyBkaXNwbGF5aW5nIGEgdGVtcG9yYXJ5IGJ1ZmZlci4NClRoaXMgaXMgZWZmZWN0aXZlIG9u bHkgd2hlbiBUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSBpcyBlbmFibGVkLg0KVGhlIHZhbHVl IGlzIHRoZSBtYXhpbXVtIGhlaWdodCAoaW4gbGluZXMpIHdoaWNoDQpgcmVzaXplLXRlbXAt YnVmZmVyLXdpbmRvdycgd2lsbCBnaXZlIHRvIGEgd2luZG93IGRpc3BsYXlpbmcgYQ0KdGVt cG9yYXJ5IGJ1ZmZlci4gIEl0IGNhbiBhbHNvIGJlIGEgZnVuY3Rpb24gdG8gYmUgY2FsbGVk IHRvDQpjaG9vc2UgdGhlIGhlaWdodCBmb3Igc3VjaCBhIGJ1ZmZlci4gIEl0IGdldHMgb25l IGFyZ3VtZW50LCB0aGUNCmJ1ZmZlciwgYW5kIHNob3VsZCByZXR1cm4gYSBwb3NpdGl2ZSBp bnRlZ2VyLiAgQXQgdGhlIHRpbWUgdGhlDQpmdW5jdGlvbiBpcyBjYWxsZWQsIHRoZSB3aW5k b3cgdG8gYmUgcmVzaXplZCBpcyBzZWxlY3RlZC4iDQogIDp0eXBlICcoY2hvaWNlIGludGVn ZXIgZnVuY3Rpb24pDQogIDpncm91cCAnaGVscA0KICA6dmVyc2lvbiAiMjQuMiIpDQoNCihk ZWZjdXN0b20gdGVtcC1idWZmZXItcmVzaXplLWZyYW1lcyBuaWwNCiAgIk5vbi1uaWwgbWVh bnMgYHRlbXAtYnVmZmVyLXJlc2l6ZS1tb2RlJyBjYW4gcmVzaXplIGZyYW1lcy4NCkEgZnJh bWUgY2FuIGJlIHJlc2l6ZWQgaWYgYW5kIG9ubHkgaWYgaXRzIHJvb3Qgd2luZG93IGlzIGEg bGl2ZQ0Kd2luZG93LiAgVGhlIGhlaWdodCBvZiB0aGUgcm9vdCB3aW5kb3cgaXMgc3ViamVj dCB0byB0aGUgdmFsdWVzIG9mDQpgdGVtcC1idWZmZXItbWF4LWhlaWdodCcgYW5kIGB3aW5k b3ctbWluLWhlaWdodCcuIg0KICA6dHlwZSAnYm9vbGVhbg0KICA6dmVyc2lvbiAiMjQuMiIN CiAgOmdyb3VwICdoZWxwKQ0KDQooZGVmaW5lLW1pbm9yLW1vZGUgdGVtcC1idWZmZXItcmVz aXplLW1vZGUNCiAgIlRvZ2dsZSBhdXRvLXNocmlua2luZyB0ZW1wIGJ1ZmZlciB3aW5kb3dz IChUZW1wIEJ1ZmZlciBSZXNpemUgbW9kZSkuDQpXaXRoIGEgcHJlZml4IGFyZ3VtZW50IEFS RywgZW5hYmxlIFRlbXAgQnVmZmVyIFJlc2l6ZSBtb2RlIGlmIEFSRw0KaXMgcG9zaXRpdmUs IGFuZCBkaXNhYmxlIGl0IG90aGVyd2lzZS4gIElmIGNhbGxlZCBmcm9tIExpc3AsDQplbmFi bGUgdGhlIG1vZGUgaWYgQVJHIGlzIG9taXR0ZWQgb3IgbmlsLg0KDQpXaGVuIFRlbXAgQnVm ZmVyIFJlc2l6ZSBtb2RlIGlzIGVuYWJsZWQsIHRoZSB3aW5kb3dzIGluIHdoaWNoIHdlDQpz aG93IGEgdGVtcG9yYXJ5IGJ1ZmZlciBhcmUgYXV0b21hdGljYWxseSByZWR1Y2VkIGluIGhl aWdodCB0bw0KZml0IHRoZSBidWZmZXIncyBjb250ZW50cywgYnV0IG5ldmVyIG1vcmUgdGhh bg0KYHRlbXAtYnVmZmVyLW1heC1oZWlnaHQnIG5vciBsZXNzIHRoYW4gYHdpbmRvdy1taW4t aGVpZ2h0Jy4NCg0KVGhpcyBtb2RlIGlzIHVzZWQgYnkgYGhlbHAnLCBgYXByb3BvcycgYW5k IGBjb21wbGV0aW9uJyBidWZmZXJzLA0KYW5kIHNvbWUgb3RoZXJzLiINCiAgOmdsb2JhbCB0 IDpncm91cCAnaGVscA0KICAoaWYgdGVtcC1idWZmZXItcmVzaXplLW1vZGUNCiAgICAgIDs7 IGBoZWxwLW1ha2UteHJlZnMnIG1heSBhZGQgYSBgYmFjaycgYnV0dG9uIGFuZCB0aHVzIGlu Y3JlYXNlIHRoZQ0KICAgICAgOzsgdGV4dCBzaXplLCBzbyBgcmVzaXplLXRlbXAtYnVmZmVy LXdpbmRvdycgbXVzdCBiZSBydW4gKmFmdGVyKiBpdC4NCiAgICAgIChhZGQtaG9vayAndGVt cC1idWZmZXItc2hvdy1ob29rICdyZXNpemUtdGVtcC1idWZmZXItd2luZG93ICdhcHBlbmQp DQogICAgKHJlbW92ZS1ob29rICd0ZW1wLWJ1ZmZlci1zaG93LWhvb2sgJ3Jlc2l6ZS10ZW1w LWJ1ZmZlci13aW5kb3cpKSkNCg0KKGRlZnVuIHJlc2l6ZS10ZW1wLWJ1ZmZlci13aW5kb3cg KCZvcHRpb25hbCB3aW5kb3cpDQogICJSZXNpemUgV0lORE9XIHRvIGZpdCBpdHMgY29udGVu dHMuDQpXSU5ET1cgY2FuIGJlIGFueSBsaXZlIHdpbmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhl IHNlbGVjdGVkIG9uZS4NCg0KRG8gbm90IG1ha2UgV0lORE9XIGhpZ2hlciB0aGFuIGB0ZW1w LWJ1ZmZlci1tYXgtaGVpZ2h0JyBub3INCnNtYWxsZXIgdGhhbiBgd2luZG93LW1pbi1oZWln aHQnLiAgRG8gbm90aGluZyBpZiB0aGUgc2VsZWN0ZWQNCndpbmRvdyBpcyBub3QgdmVydGlj YWxseSBjb21iaW5lZCBvciBzb21lIG9mIGl0cyBjb250ZW50cyBhcmUNCnNjcm9sbGVkIG91 dCBvZiB2aWV3LiINCiAgKHNldHEgd2luZG93ICh3aW5kb3ctbm9ybWFsaXplLXdpbmRvdyB3 aW5kb3cgdCkpDQogIChsZXQgKChoZWlnaHQgKGlmIChmdW5jdGlvbnAgdGVtcC1idWZmZXIt bWF4LWhlaWdodCkNCgkJICAgIChmdW5jYWxsIHRlbXAtYnVmZmVyLW1heC1oZWlnaHQgKHdp bmRvdy1idWZmZXIgd2luZG93KSkNCgkJICB0ZW1wLWJ1ZmZlci1tYXgtaGVpZ2h0KSkpDQog ICAgKGNvbmQNCiAgICAgKChhbmQgKHBvcy12aXNpYmxlLWluLXdpbmRvdy1wIChwb2ludC1t aW4pIHdpbmRvdykNCgkgICAod2luZG93LWNvbWJpbmVkLXAgd2luZG93KSkNCiAgICAgIChm aXQtd2luZG93LXRvLWJ1ZmZlciB3aW5kb3cgaGVpZ2h0KSkNCiAgICAgKChhbmQgdGVtcC1i dWZmZXItcmVzaXplLWZyYW1lcw0KCSAgIChlcSB3aW5kb3cgKGZyYW1lLXJvb3Qtd2luZG93 IHdpbmRvdykpDQoJICAgKG1lbXEgKGNhciAod2luZG93LXBhcmFtZXRlciB3aW5kb3cgJ3F1 aXQtcmVzdG9yZSkpDQoJCSA7OyBJZiAnc2FtZSBpcyB0b28gc3Ryb25nLCB3ZSBtaWdodCBh ZGRpdGlvbmFsbHkgY2hlY2sNCgkJIDs7IHdoZXRoZXIgdGhlIHNlY29uZCBlbGVtZW50IGlz ICdmcmFtZS4NCgkJICcoc2FtZSBmcmFtZSkpKQ0KICAgICAgKGxldCAoKGZyYW1lICh3aW5k b3ctZnJhbWUgd2luZG93KSkpDQoJKGZpdC1mcmFtZS10by1idWZmZXINCgkgZnJhbWUgKCsg KGZyYW1lLWhlaWdodCBmcmFtZSkNCgkJICAoLSAod2luZG93LXRvdGFsLXNpemUgd2luZG93 KSkNCgkJICBoZWlnaHQpKSkpKSkpDQoNCihkZWZ2YXIgdGVtcC1idWZmZXItd2luZG93LXNl dHVwLWhvb2sgbmlsDQogICJOb3JtYWwgaG9vayBydW4gYnkgYHdpdGgtdGVtcC1idWZmZXIt d2luZG93JyBiZWZvcmUgYnVmZmVyIGRpc3BsYXkuDQpUaGlzIGhvb2sgaXMgcnVuIGJ5IGB3 aXRoLXRlbXAtYnVmZmVyLXdpbmRvdycgd2l0aCB0aGUgYnVmZmVyIHRvIGJlDQpkaXNwbGF5 ZWQgY3VycmVudC4iKQ0KDQooZGVmdmFyIHRlbXAtYnVmZmVyLXdpbmRvdy1zaG93LWhvb2sg bmlsDQogICJOb3JtYWwgaG9vayBydW4gYnkgYHdpdGgtdGVtcC1idWZmZXItd2luZG93JyBh ZnRlciBidWZmZXIgZGlzcGxheS4NClRoaXMgaG9vayBpcyBydW4gYnkgYHdpdGgtdGVtcC1i dWZmZXItd2luZG93JyB3aXRoIHRoZSBidWZmZXINCmRpc3BsYXllZCBhbmQgY3VycmVudCBh bmQgaXRzIHdpbmRvdyBzZWxlY3RlZC4iKQ0KDQooZGVmdW4gdGVtcC1idWZmZXItd2luZG93 LXNldHVwIChidWZmZXItb3ItbmFtZSkNCiAgIlNldCB1cCB0ZW1wb3JhcnkgYnVmZmVyIHNw ZWNpZmllZCBieSBCVUZGRVItT1ItTkFNRSANClJldHVybiB0aGUgYnVmZmVyLiINCiAgKGxl dCAoKG9sZC1kaXIgZGVmYXVsdC1kaXJlY3RvcnkpDQoJKGJ1ZmZlciAoZ2V0LWJ1ZmZlci1j cmVhdGUgYnVmZmVyLW9yLW5hbWUpKSkNCiAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciBidWZm ZXINCiAgICAgIChraWxsLWFsbC1sb2NhbC12YXJpYWJsZXMpDQogICAgICAoc2V0cSBkZWZh dWx0LWRpcmVjdG9yeSBvbGQtZGlyKQ0KOzsgICAgICAgKGRlbGV0ZS1hbGwtb3ZlcmxheXMp DQogICAgICAoc2V0cSBidWZmZXItcmVhZC1vbmx5IG5pbCkNCiAgICAgIChzZXRxIGJ1ZmZl ci1maWxlLW5hbWUgbmlsKQ0KICAgICAgKHNldHEgYnVmZmVyLXVuZG8tbGlzdCB0KQ0KICAg ICAgKGxldCAoKGluaGliaXQtcmVhZC1vbmx5IHQpDQoJICAgIChpbmhpYml0LW1vZGlmaWNh dGlvbi1ob29rcyB0KSkNCgkoZXJhc2UtYnVmZmVyKQ0KCShydW4taG9va3MgJ3RlbXAtYnVm ZmVyLXdpbmRvdy1zZXR1cC1ob29rKSkNCiAgICAgIDs7IFJldHVybiB0aGUgYnVmZmVyLg0K ICAgICAgYnVmZmVyKSkpDQoNCihkZWZ1biB0ZW1wLWJ1ZmZlci13aW5kb3ctc2hvdyAoJm9w dGlvbmFsIGJ1ZmZlcikNCiAgIlNob3cgdGVtcG9yYXJ5IGJ1ZmZlciBCVUZGRVIgaW4gYSB3 aW5kb3cuDQpSZXR1cm4gdGhlIHdpbmRvdyBzaG93aW5nIEJVRkZFUi4iDQogIChsZXQgKHdp bmRvdyBmcmFtZSkNCiAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciBidWZmZXINCiAgICAgIChz ZXQtYnVmZmVyLW1vZGlmaWVkLXAgbmlsKQ0KICAgICAgKHNldHEgYnVmZmVyLXJlYWQtb25s eSB0KQ0KICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkNCiAgICAgICh3aGVuIChzZXRx IHdpbmRvdyAoZGlzcGxheS1idWZmZXIgYnVmZmVyKSkNCgkoc2V0cSBmcmFtZSAod2luZG93 LWZyYW1lIHdpbmRvdykpDQoJKHVubGVzcyAoZXEgZnJhbWUgKHNlbGVjdGVkLWZyYW1lKSkN CgkgIChyYWlzZS1mcmFtZSBmcmFtZSkpDQoJKHNldHEgbWluaWJ1ZmZlci1zY3JvbGwtd2lu ZG93IHdpbmRvdykNCgkoc2V0LXdpbmRvdy1oc2Nyb2xsIHdpbmRvdyAwKQ0KCSh3aXRoLXNl bGVjdGVkLXdpbmRvdyB3aW5kb3cNCgkgIChydW4taG9va3MgJ3RlbXAtYnVmZmVyLXdpbmRv dy1zaG93LWhvb2spDQoJICAod2hlbiB0ZW1wLWJ1ZmZlci1yZXNpemUtbW9kZQ0KCSAgICAo cmVzaXplLXRlbXAtYnVmZmVyLXdpbmRvdyB3aW5kb3cpKSkNCgk7OyBSZXR1cm4gdGhlIHdp bmRvdy4NCgl3aW5kb3cpKSkpDQoNCihkZWZtYWNybyB3aXRoLXRlbXAtYnVmZmVyLXdpbmRv dyAoYnVmZmVyLW9yLW5hbWUgcXVpdC1mdW5jdGlvbiAmcmVzdCBib2R5KQ0KICAiRXZhbHVh dGUgQk9EWSBhbmQgZGlzcGxheSBidWZmZXIgc3BlY2lmaWVkIGJ5IEJVRkZFUi1PUi1OQU1F Lg0KQlVGRkVSLU9SLU5BTUUgbXVzdCBzcGVjaWZ5IGVpdGhlciBhIGxpdmUgYnVmZmVyIG9y IHRoZSBuYW1lIG9mIGENCmJ1ZmZlci4gIElmIG5vIGJ1ZmZlciB3aXRoIHN1Y2ggYSBuYW1l IGV4aXN0cywgY3JlYXRlIG9uZS4NCg0KTWFrZSBzdXJlIHRoZSBzcGVjaWZpZWQgYnVmZmVy IGlzIGVtcHR5IGJlZm9yZSBldmFsdWF0aW5nIEJPRFkuDQpEbyBub3QgbWFrZSB0aGF0IGJ1 ZmZlciBjdXJyZW50IGZvciBCT0RZLiAgSW5zdGVhZCwgYmluZA0KYHN0YW5kYXJkLW91dHB1 dCcgdG8gdGhhdCBidWZmZXIsIHNvIHRoYXQgb3V0cHV0IGdlbmVyYXRlZCB3aXRoDQpgcHJp bjEnIGFuZCBzaW1pbGFyIGZ1bmN0aW9ucyBpbiBCT0RZIGdvZXMgaW50byB0aGF0IGJ1ZmZl ci4NCg0KQWZ0ZXIgZXZhbHVhdGluZyBCT0RZLCBtYXJrIHRoZSBzcGVjaWZpZWQgYnVmZmVy IHVubW9kaWZpZWQgYW5kDQpyZWFkLW9ubHkgYW5kIGRpc3BsYXkgaXQgaW4gYSB3aW5kb3cu ICBBdXRvLXNocmluayB0aGUgd2luZG93IGlmDQpgdGVtcC1idWZmZXItcmVzaXplLW1vZGUn IGlzIGVuYWJsZWQuDQoNClJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgQk9EWSB1bmxl c3MgUVVJVC1GVU5DVElPTiBzcGVjaWZpZXMNCmEgZnVuY3Rpb24uICBJbiB0aGF0IGNhc2Us IHJ1biB0aGUgZnVuY3Rpb24gd2l0aCB0d28gYXJndW1lbnRzIC0NCnRoZSB3aW5kb3cgc2hv d2luZyB0aGUgc3BlY2lmaWVkIGJ1ZmZlciBhbmQgdGhlIHZhbHVlIHJldHVybmVkIGJ5DQpC T0RZIC0gYW5kIHJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgdGhhdCBmdW5jdGlvbi4N Cg0KSWYgdGhlIGJ1ZmZlciBpcyBkaXNwbGF5ZWQgb24gYSBuZXcgZnJhbWUsIHRoZSB3aW5k b3cgbWFuYWdlciBtYXkNCmRlY2lkZSB0byBzZWxlY3QgdGhhdCBmcmFtZS4gIEluIHRoYXQg Y2FzZSwgaXQncyB1c3VhbGx5IGEgZ29vZA0Kc3RyYXRlZ3kgaWYgdGhlIGZ1bmN0aW9uIHNw ZWNpZmllZCBieSBRVUlULUZVTkNUSU9OIHNlbGVjdHMgdGhlDQp3aW5kb3cgc2hvd2luZyB0 aGUgYnVmZmVyIGJlZm9yZSByZWFkaW5nIGEgdmFsdWUgZnJvbSB0aGUNCm1pbmlidWZmZXIs IGZvciBleGFtcGxlLCB3aGVuIGFza2luZyBhIGB5ZXMtb3Itbm8tcCcgcXVlc3Rpb24uDQoN ClRoaXMgY29uc3RydWN0IGlzIHNpbWlsYXIgdG8gYHdpdGgtb3V0cHV0LXRvLXRlbXAtYnVm ZmVyJyBidXQNCmRvZXMgbmVpdGhlciBwdXQgdGhlIGJ1ZmZlciBpbiBoZWxwIG1vZGUgbm9y IGRvZXMgaXQgY2FsbA0KYHRlbXAtYnVmZmVyLXNob3ctZnVuY3Rpb24nLiAgSXQgYWxzbyBy dW5zIGRpZmZlcmVudCBob29rcywNCm5hbWVseSBgdGVtcC1idWZmZXItd2luZG93LXNldHVw LWhvb2snICh3aXRoIHRoZSBzcGVjaWZpZWQgYnVmZmVyDQpjdXJyZW50KSBhbmQgYHRlbXAt YnVmZmVyLXdpbmRvdy1zaG93LWhvb2snICh3aXRoIHRoZSBzcGVjaWZpZWQNCmJ1ZmZlciBj dXJyZW50IGFuZCB0aGUgd2luZG93IHNob3dpbmcgaXQgc2VsZWN0ZWQpLg0KDQpTaW5jZSB0 aGlzIG1hY3JvIGNhbGxzIGBkaXNwbGF5LWJ1ZmZlcicsIHRoZSB3aW5kb3cgZGlzcGxheWlu Zw0KdGhlIGJ1ZmZlciBpcyB1c3VhbGx5IG5vdCBzZWxlY3RlZCBhbmQgdGhlIHNwZWNpZmll ZCBidWZmZXINCnVzdWFsbHkgbm90IG1hZGUgY3VycmVudC4gIFFVSVQtRlVOQ1RJT04gY2Fu IG92ZXJyaWRlIHRoYXQuIg0KICAoZGVjbGFyZSAoZGVidWcgdCkpDQogIChsZXQgKChidWZm ZXIgKG1ha2Utc3ltYm9sICJidWZmZXIiKSkNCgkod2luZG93IChtYWtlLXN5bWJvbCAid2lu ZG93IikpDQoJKHZhbHVlIChtYWtlLXN5bWJvbCAidmFsdWUiKSkpDQogICAgYChsZXQqICgo LGJ1ZmZlciAodGVtcC1idWZmZXItd2luZG93LXNldHVwICxidWZmZXItb3ItbmFtZSkpDQoJ ICAgIChzdGFuZGFyZC1vdXRwdXQgLGJ1ZmZlcikNCgkgICAgLHdpbmRvdyAsdmFsdWUpDQog ICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgLGJ1ZmZlcg0KCSAoc2V0cSAsdmFsdWUgKHBy b2duICxAYm9keSkpDQoJIChzZXRxICx3aW5kb3cgKHRlbXAtYnVmZmVyLXdpbmRvdy1zaG93 ICxidWZmZXIpKSkNCg0KICAgICAgIChpZiAoZnVuY3Rpb25wICxxdWl0LWZ1bmN0aW9uKQ0K CSAgIChmdW5jYWxsICxxdWl0LWZ1bmN0aW9uICx3aW5kb3cgLHZhbHVlKQ0KCSAsdmFsdWUp KSkpDQoNCihkZWZ1biB3aW5kb3ctLWRpc3BsYXktYnVmZmVyIChidWZmZXIgd2luZG93IHR5 cGUgJm9wdGlvbmFsIGRlZGljYXRlZCkNCiAgIkRpc3BsYXkgQlVGRkVSIGluIFdJTkRPVyBh bmQgbWFrZSBpdHMgZnJhbWUgdmlzaWJsZS4NClRZUEUgbXVzdCBiZSBvbmUgb2YgdGhlIHN5 bWJvbHMgYHJldXNlJywgYHdpbmRvdycgb3IgYGZyYW1lJyBhbmQNCmlzIHBhc3NlZCB1bmFs dGVyZWQgdG8gYGRpc3BsYXktYnVmZmVyLXJlY29yZC13aW5kb3cnLiBTZXQNCmB3aW5kb3ct ZGVkaWNhdGVkLXAnIHRvIERFRElDQVRFRCBpZiBub24tbmlsLiAgUmV0dXJuIFdJTkRPVyBp Zg0KQlVGRkVSIGFuZCBXSU5ET1cgYXJlIGxpdmUuIg0KICAod2hlbiAoYW5kIChidWZmZXIt bGl2ZS1wIGJ1ZmZlcikgKHdpbmRvdy1saXZlLXAgd2luZG93KSkNCiAgICAobGV0KiAoKGZy YW1lICh3aW5kb3ctZnJhbWUgd2luZG93KSkNCgkgICAodmlzaWJsZSAoZnJhbWUtdmlzaWJs ZS1wIGZyYW1lKSkpDQogICAgICAoZGlzcGxheS1idWZmZXItcmVjb3JkLXdpbmRvdyB0eXBl IHdpbmRvdyBidWZmZXIpDQogICAgICAodW5sZXNzIChlcSBidWZmZXIgKHdpbmRvdy1idWZm ZXIgd2luZG93KSkNCgkoc2V0LXdpbmRvdy1kZWRpY2F0ZWQtcCB3aW5kb3cgbmlsKQ0KCShz ZXQtd2luZG93LWJ1ZmZlciB3aW5kb3cgYnVmZmVyKQ0KCSh3aGVuIGRlZGljYXRlZA0KCSAg KHNldC13aW5kb3ctZGVkaWNhdGVkLXAgd2luZG93IGRlZGljYXRlZCkpKQ0KICAgICAgKHdo ZW4gKG1lbXEgdHlwZSAnKHdpbmRvdyBmcmFtZSkpDQoJKHNldC13aW5kb3ctcHJldi1idWZm ZXJzIHdpbmRvdyBuaWwpKQ0KDQogICAgICAodW5sZXNzIChvciAobm90IHZpc2libGUpDQoJ CSAgOzsgQXNzdW1lIHRoZSBzZWxlY3RlZCBmcmFtZSBpcyBhbHJlYWR5IHZpc2libGUgZW5v dWdoLg0KCQkgIChlcSBmcmFtZSAoc2VsZWN0ZWQtZnJhbWUpKQ0KCQkgIDs7IEFzc3VtZSB0 aGUgZnJhbWUgZnJvbSB3aGljaCB3ZSBpbnZva2VkIHRoZSBtaW5pYnVmZmVyDQoJCSAgOzsg aXMgdmlzaWJsZS4NCgkJICAoYW5kIChtaW5pYnVmZmVyLXdpbmRvdy1hY3RpdmUtcCAoc2Vs ZWN0ZWQtd2luZG93KSkNCgkJICAgICAgIChlcSBmcmFtZSAod2luZG93LWZyYW1lIChtaW5p YnVmZmVyLXNlbGVjdGVkLXdpbmRvdykpKSkpDQoJKHJhaXNlLWZyYW1lIGZyYW1lKSkNCg0K ICAgICAgd2luZG93KSkpDQoNCihkZWZ1biBxdWl0LXJlc3RvcmUtd2luZG93ICgmb3B0aW9u YWwgd2luZG93IGJ1cnktb3Ita2lsbCkNCiAgIlF1aXQgV0lORE9XIGFuZCBkZWFsIHdpdGgg aXRzIGJ1ZmZlci4NCldJTkRPVyBtdXN0IGJlIGEgbGl2ZSB3aW5kb3cgYW5kIGRlZmF1bHRz IHRvIHRoZSBzZWxlY3RlZCBvbmUuDQoNCkFjY29yZGluZyB0byBpbmZvcm1hdGlvbiBzdG9y ZWQgaW4gV0lORE9XJ3MgYHF1aXQtcmVzdG9yZScgd2luZG93DQpwYXJhbWV0ZXIgZWl0aGVy ICgxKSBkZWxldGUgV0lORE9XIGFuZCBpdHMgZnJhbWUsICgyKSBkZWxldGUNCldJTkRPVywg KDMpIHJlc3RvcmUgdGhlIGJ1ZmZlciBwcmV2aW91c2x5IGRpc3BsYXllZCBpbiBXSU5ET1cs DQpvciAoNCkgbWFrZSBXSU5ET1cgZGlzcGxheSBzb21lIG90aGVyIGJ1ZmZlciB0aGFuIHRo ZSBwcmVzZW50DQpvbmUuICBJZiBub24tbmlsLCByZXNldCBgcXVpdC1yZXN0b3JlJyBwYXJh bWV0ZXIgdG8gbmlsLg0KDQpPcHRpb25hbCBzZWNvbmQgYXJndW1lbnQgQlVSWS1PUi1LSUxM IHRlbGxzIGhvdyB0byBwcm9jZWVkIHdpdGgNCnRoZSBidWZmZXIgb2YgV0lORE9XLiAgVGhl IGZvbGxvd2luZyB2YWx1ZXMgYXJlIGhhbmRsZWQ6DQoNCmBuaWwnIG1lYW5zIHRvIG5vdCBo YW5kbGUgdGhlIGJ1ZmZlciBpbiBhIHBhcnRpY3VsYXIgd2F5LiAgVGhpcw0KICBtZWFucyB0 aGF0IGlmIFdJTkRPVyBpcyBub3QgZGVsZXRlZCBieSB0aGlzIGZ1bmN0aW9uLCBpbnZva2lu Zw0KICBgc3dpdGNoLXRvLXByZXYtYnVmZmVyJyB3aWxsIHVzdWFsbHkgc2hvdyB0aGUgYnVm ZmVyIGFnYWluLg0KDQpgYXBwZW5kJyBtZWFucyB0aGF0IGlmIFdJTkRPVyBpcyBub3QgZGVs ZXRlZCwgbW92ZSBpdHMgYnVmZmVyIHRvDQogIHRoZSBlbmQgb2YgV0lORE9XJ3MgcHJldmlv dXMgYnVmZmVycyBzbyBpdCdzIGxlc3MgbGlrZWx5IHRoYXQgYQ0KICBmdXR1cmUgaW52b2Nh dGlvbiBvZiBgc3dpdGNoLXRvLXByZXYtYnVmZmVyJyB3aWxsIHN3aXRjaCB0byBpdC4NCiAg QWxzbywgbW92ZSB0aGUgYnVmZmVyIHRvIHRoZSBlbmQgb2YgdGhlIGZyYW1lJ3MgYnVmZmVy IGxpc3QuDQoNCmBidXJ5JyBtZWFucyB0aGF0IGlmIFdJTkRPVyBpcyBub3QgZGVsZXRlZCwg cmVtb3ZlIGl0cyBidWZmZXINCiAgZnJvbSBXSU5ET1cnUyBsaXN0IG9mIHByZXZpb3VzIGJ1 ZmZlcnMuICBBbHNvLCBtb3ZlIHRoZSBidWZmZXINCiAgdG8gdGhlIGVuZCBvZiB0aGUgZnJh bWUncyBidWZmZXIgbGlzdC4gIFRoaXMgdmFsdWUgcHJvdmlkZXMgdGhlDQogIG1vc3QgcmVs aWFibGUgcmVtZWR5IHRvIG5vdCBoYXZlIGBzd2l0Y2gtdG8tcHJldi1idWZmZXInIHN3aXRj aA0KICB0byB0aGlzIGJ1ZmZlciBhZ2FpbiB3aXRob3V0IGtpbGxpbmcgdGhlIGJ1ZmZlci4N Cg0KYGtpbGwnIG1lYW5zIHRvIGtpbGwgV0lORE9XJ3MgYnVmZmVyLiINCiAgKHNldHEgd2lu ZG93ICh3aW5kb3ctbm9ybWFsaXplLXdpbmRvdyB3aW5kb3cgdCkpDQogIChsZXQqICgoYnVm ZmVyICh3aW5kb3ctYnVmZmVyIHdpbmRvdykpDQoJIChxdWl0LXJlc3RvcmUgKHdpbmRvdy1w YXJhbWV0ZXIgd2luZG93ICdxdWl0LXJlc3RvcmUpKQ0KCSAocHJldi1idWZmZXINCgkgIChs ZXQqICgocHJldi1idWZmZXJzICh3aW5kb3ctcHJldi1idWZmZXJzIHdpbmRvdykpDQoJCSAo cHJldi1idWZmZXIgKGNhYXIgcHJldi1idWZmZXJzKSkpDQoJICAgIChhbmQgKG9yIChub3Qg KGVxIHByZXYtYnVmZmVyIGJ1ZmZlcikpDQoJCSAgICAgKGFuZCAoY2RyIHByZXYtYnVmZmVy cykNCgkJCSAgKG5vdCAoZXEgKHNldHEgcHJldi1idWZmZXIgKGNhZHIgcHJldi1idWZmZXJz KSkNCgkJCQkgICBidWZmZXIpKSkpDQoJCSBwcmV2LWJ1ZmZlcikpKQ0KCSBxdWFkIGVudHJ5 KQ0KICAgIChjb25kDQogICAgICgoYW5kIChub3QgcHJldi1idWZmZXIpDQoJICAgKG1lbXEg KG50aCAxIHF1aXQtcmVzdG9yZSkgJyh3aW5kb3cgZnJhbWUpKQ0KCSAgIChlcSAobnRoIDMg cXVpdC1yZXN0b3JlKSBidWZmZXIpDQoJICAgOzsgRGVsZXRlIFdJTkRPVyBpZiBwb3NzaWJs ZS4NCgkgICAod2luZG93LS1kZWxldGUgd2luZG93IG5pbCAoZXEgYnVyeS1vci1raWxsICdr aWxsKSkpDQogICAgICA7OyBJZiB0aGUgcHJldmlvdXNseSBzZWxlY3RlZCB3aW5kb3cgaXMg c3RpbGwgYWxpdmUsIHNlbGVjdCBpdC4NCiAgICAgICh3aGVuICh3aW5kb3ctbGl2ZS1wIChu dGggMiBxdWl0LXJlc3RvcmUpKQ0KCShzZWxlY3Qtd2luZG93IChudGggMiBxdWl0LXJlc3Rv cmUpKSkpDQogICAgICgoYW5kIChsaXN0cCAoc2V0cSBxdWFkIChudGggMSBxdWl0LXJlc3Rv cmUpKSkNCgkgICAoYnVmZmVyLWxpdmUtcCAoY2FyIHF1YWQpKQ0KCSAgIChlcSAobnRoIDMg cXVpdC1yZXN0b3JlKSBidWZmZXIpKQ0KICAgICAgOzsgU2hvdyBhbm90aGVyIGJ1ZmZlciBz dG9yZWQgaW4gcXVpdC1yZXN0b3JlIHBhcmFtZXRlci4NCiAgICAgICh3aGVuIChhbmQgKGlu dGVnZXJwIChudGggMyBxdWFkKSkNCgkJICgvPSAobnRoIDMgcXVhZCkgKHdpbmRvdy10b3Rh bC1zaXplIHdpbmRvdykpKQ0KCTs7IFRyeSB0byByZXNpemUgV0lORE9XIHRvIGl0cyBvbGQg aGVpZ2h0IGJ1dCBkb24ndCBzaWduYWwgYW4NCgk7OyBlcnJvci4NCgkoY29uZGl0aW9uLWNh c2UgbmlsDQoJICAgICh3aW5kb3ctcmVzaXplIHdpbmRvdyAoLSAobnRoIDMgcXVhZCkgKHdp bmRvdy10b3RhbC1zaXplIHdpbmRvdykpKQ0KCSAgKGVycm9yIG5pbCkpKQ0KICAgICAgKHNl dC13aW5kb3ctZGVkaWNhdGVkLXAgd2luZG93IG5pbCkNCiAgICAgIDs7IFJlc3RvcmUgV0lO RE9XJ3MgcHJldmlvdXMgYnVmZmVyLCBzdGFydCBhbmQgcG9pbnQgcG9zaXRpb24uDQogICAg ICAoc2V0LXdpbmRvdy1idWZmZXItc3RhcnQtYW5kLXBvaW50DQogICAgICAgd2luZG93IChu dGggMCBxdWFkKSAobnRoIDEgcXVhZCkgKG50aCAyIHF1YWQpKQ0KICAgICAgOzsgRGVhbCB3 aXRoIHRoZSBidWZmZXIgd2UganVzdCByZW1vdmVkIGZyb20gV0lORE9XLg0KICAgICAgKHNl dHEgZW50cnkgKGFuZCAoZXEgYnVyeS1vci1raWxsICdhcHBlbmQpDQoJCSAgICAgICAoYXNz cSBidWZmZXIgKHdpbmRvdy1wcmV2LWJ1ZmZlcnMgd2luZG93KSkpKQ0KICAgICAgKHdoZW4g YnVyeS1vci1raWxsDQoJOzsgUmVtb3ZlIGJ1ZmZlciBmcm9tIFdJTkRPVydzIHByZXZpb3Vz IGFuZCBuZXh0IGJ1ZmZlcnMuDQoJKHNldC13aW5kb3ctcHJldi1idWZmZXJzDQoJIHdpbmRv dyAoYXNzcS1kZWxldGUtYWxsIGJ1ZmZlciAod2luZG93LXByZXYtYnVmZmVycyB3aW5kb3cp KSkNCgkoc2V0LXdpbmRvdy1uZXh0LWJ1ZmZlcnMNCgkgd2luZG93IChkZWxxIGJ1ZmZlciAo d2luZG93LW5leHQtYnVmZmVycyB3aW5kb3cpKSkpDQogICAgICAod2hlbiBlbnRyeQ0KCTs7 IEFwcGVuZCBvbGQgYnVmZmVyJ3MgZW50cnkgdG8gbGlzdCBvZiBXSU5ET1cncyBwcmV2aW91 cw0KCTs7IGJ1ZmZlcnMgc28gaXQncyBsZXNzIGxpa2VseSB0byBnZXQgc3dpdGNoZWQgdG8g c29vbiBidXQNCgk7OyBgZGlzcGxheS1idWZmZXItaW4tcHJldmlvdXMtd2luZG93JyBjYW4g bmV2ZXJ0aGVsZXNzIGZpbmQgaXQuDQoJKHNldC13aW5kb3ctcHJldi1idWZmZXJzDQoJIHdp bmRvdyAoYXBwZW5kICh3aW5kb3ctcHJldi1idWZmZXJzIHdpbmRvdykgKGxpc3QgZW50cnkp KSkpDQogICAgICA7OyBSZXNldCB0aGUgcXVpdC1yZXN0b3JlIHBhcmFtZXRlci4NCiAgICAg IChzZXQtd2luZG93LXBhcmFtZXRlciB3aW5kb3cgJ3F1aXQtcmVzdG9yZSBuaWwpDQogICAg ICA7OyBTZWxlY3Qgb2xkIHdpbmRvdy4NCiAgICAgICh3aGVuICh3aW5kb3ctbGl2ZS1wIChu dGggMiBxdWl0LXJlc3RvcmUpKQ0KCShzZWxlY3Qtd2luZG93IChudGggMiBxdWl0LXJlc3Rv cmUpKSkpDQogICAgICh0DQogICAgICA7OyBTaG93IHNvbWUgb3RoZXIgYnVmZmVyIGluIFdJ TkRPVyBhbmQgcmVzZXQgdGhlIHF1aXQtcmVzdG9yZQ0KICAgICAgOzsgcGFyYW1ldGVyLg0K ICAgICAgKHNldC13aW5kb3ctcGFyYW1ldGVyIHdpbmRvdyAncXVpdC1yZXN0b3JlIG5pbCkN CiAgICAgIDs7IE1ha2Ugc3VyZSB0aGF0IFdJTkRPVyBpcyBubyBtb3JlIGRlZGljYXRlZC4N CiAgICAgIChzZXQtd2luZG93LWRlZGljYXRlZC1wIHdpbmRvdyBuaWwpDQogICAgICAoc3dp dGNoLXRvLXByZXYtYnVmZmVyIHdpbmRvdyBidXJ5LW9yLWtpbGwpKSkNCg0KICAgIDs7IERl YWwgd2l0aCB0aGUgYnVmZmVyLg0KICAgIChjb25kDQogICAgICgobm90IChidWZmZXItbGl2 ZS1wIGJ1ZmZlcikpKQ0KICAgICAoKGVxIGJ1cnktb3Ita2lsbCAna2lsbCkNCiAgICAgIChr aWxsLWJ1ZmZlciBidWZmZXIpKQ0KICAgICAoYnVyeS1vci1raWxsDQogICAgICAoYnVyeS1i dWZmZXItaW50ZXJuYWwgYnVmZmVyKSkpKSkNCg0KKGRlZnVuIHF1aXQtd2luZG93ICgmb3B0 aW9uYWwga2lsbCB3aW5kb3cpDQogICJRdWl0IFdJTkRPVyBhbmQgYnVyeSBpdHMgYnVmZmVy Lg0KV0lORE9XIG11c3QgYmUgYSBsaXZlIHdpbmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhlIHNl bGVjdGVkIG9uZS4NCldpdGggcHJlZml4IGFyZ3VtZW50IEtJTEwgbm9uLW5pbCwga2lsbCB0 aGUgYnVmZmVyIGluc3RlYWQgb2YNCmJ1cnlpbmcgaXQuDQoNCkFjY29yZGluZyB0byBpbmZv cm1hdGlvbiBzdG9yZWQgaW4gV0lORE9XJ3MgYHF1aXQtcmVzdG9yZScgd2luZG93DQpwYXJh bWV0ZXIgZWl0aGVyICgxKSBkZWxldGUgV0lORE9XIGFuZCBpdHMgZnJhbWUsICgyKSBkZWxl dGUNCldJTkRPVywgKDMpIHJlc3RvcmUgdGhlIGJ1ZmZlciBwcmV2aW91c2x5IGRpc3BsYXll ZCBpbiBXSU5ET1csDQpvciAoNCkgbWFrZSBXSU5ET1cgZGlzcGxheSBzb21lIG90aGVyIGJ1 ZmZlciB0aGFuIHRoZSBwcmVzZW50DQpvbmUuICBJZiBub24tbmlsLCByZXNldCBgcXVpdC1y ZXN0b3JlJyBwYXJhbWV0ZXIgdG8gbmlsLiINCiAgKGludGVyYWN0aXZlICJQIikNCiAgKHF1 aXQtcmVzdG9yZS13aW5kb3cgd2luZG93IChpZiBraWxsICdraWxsICdidXJ5KSkpDQoNCihk ZWZjdXN0b20gZml0LWZyYW1lLXRvLWJ1ZmZlci1ib3R0b20tbWFyZ2luIDQNCiAgIkJvdHRv bSBtYXJnaW4gZm9yIGBmaXQtZnJhbWUtdG8tYnVmZmVyJy4NClRoaXMgaXMgdGhlIG51bWJl ciBvZiBsaW5lcyBgZml0LWZyYW1lLXRvLWJ1ZmZlcicgbGVhdmVzIGZyZWUgYXQgdGhlDQpi b3R0b20gb2YgdGhlIGRpc3BsYXkgaW4gb3JkZXIgdG8gbm90IG9ic2N1cmUgdGhlIHN5c3Rl bSB0YXNrIGJhci4iDQogIDp0eXBlICdpbnRlZ2VyDQogIDp2ZXJzaW9uICIyNC4yIg0KICA6 Z3JvdXAgJ3dpbmRvd3MpDQoNCihkZWZ1biBmaXQtZnJhbWUtdG8tYnVmZmVyICgmb3B0aW9u YWwgZnJhbWUgbWF4LWhlaWdodCBtaW4taGVpZ2h0KQ0KICAiQWRqdXN0IGhlaWdodCBvZiBG UkFNRSB0byBkaXNwbGF5IGl0cyBidWZmZXIncyBjb250ZW50cyBleGFjdGx5Lg0KRlJBTUUg Y2FuIGJlIGFueSBsaXZlIGZyYW1lIGFuZCBkZWZhdWx0cyB0byB0aGUgc2VsZWN0ZWQgb25l Lg0KDQpPcHRpb25hbCBhcmd1bWVudCBNQVgtSEVJR0hUIHNwZWNpZmllcyB0aGUgbWF4aW11 bSBoZWlnaHQgb2YNCkZSQU1FIGFuZCBkZWZhdWx0cyB0byB0aGUgaGVpZ2h0IG9mIHRoZSBk aXNwbGF5IGJlbG93IHRoZSBjdXJyZW50DQp0b3AgbGluZSBvZiBGUkFNRSBtaW51cyBGSVQt RlJBTUUtVE8tQlVGRkVSLUJPVFRPTS1NQVJHSU4uDQpPcHRpb25hbCBhcmd1bWVudCBNSU4t SEVJR0hUIHNwZWNpZmllcyB0aGUgbWluaW11bSBoZWlnaHQgb2YNCkZSQU1FLiINCiAgKGlu dGVyYWN0aXZlKQ0KICAoc2V0cSBmcmFtZSAod2luZG93LW5vcm1hbGl6ZS1mcmFtZSBmcmFt ZSkpDQogIChsZXQqICgocm9vdCAoZnJhbWUtcm9vdC13aW5kb3cgZnJhbWUpKQ0KCSAoZnJh bWUtbWluLWhlaWdodA0KCSAgKCsgKC0gKGZyYW1lLWhlaWdodCBmcmFtZSkgKHdpbmRvdy10 b3RhbC1zaXplIHJvb3QpKQ0KCSAgICAgd2luZG93LW1pbi1oZWlnaHQpKQ0KCSAoZnJhbWUt dG9wIChmcmFtZS1wYXJhbWV0ZXIgZnJhbWUgJ3RvcCkpDQoJICh0b3AgKGlmIChjb25zcCBm cmFtZS10b3ApDQoJCSAgKGZ1bmNhbGwgKGNhciBmcmFtZS10b3ApIChjYWRyIGZyYW1lLXRv cCkpDQoJCWZyYW1lLXRvcCkpDQoJIChmcmFtZS1tYXgtaGVpZ2h0DQoJICAoLSAoLyAoLSAo eC1kaXNwbGF5LXBpeGVsLWhlaWdodCBmcmFtZSkgdG9wKQ0KCQkoZnJhbWUtY2hhci1oZWln aHQgZnJhbWUpKQ0KCSAgICAgZml0LWZyYW1lLXRvLWJ1ZmZlci1ib3R0b20tbWFyZ2luKSkN CgkgZGVsdGEpDQogICAgKHdoZW4gKGFuZCAod2luZG93LWxpdmUtcCByb290KSAobm90ICh3 aW5kb3ctc2l6ZS1maXhlZC1wIHJvb3QpKSkNCiAgICAgICh3aXRoLXNlbGVjdGVkLXdpbmRv dyByb290DQoJKGNvbmQNCgkgKChub3QgbWF4LWhlaWdodCkNCgkgIChzZXRxIG1heC1oZWln aHQgZnJhbWUtbWF4LWhlaWdodCkpDQoJICgobnVtYmVycCBtYXgtaGVpZ2h0KQ0KCSAgKHNl dHEgbWF4LWhlaWdodCAobWluIG1heC1oZWlnaHQgZnJhbWUtbWF4LWhlaWdodCkpKQ0KCSAo dA0KCSAgKGVycm9yICIlcyBpcyBhbiBpbnZhbGlkIG1heGltdW0gaGVpZ2h0IiBtYXgtaGVp Z2h0KSkpDQoJKGNvbmQNCgkgKChub3QgbWluLWhlaWdodCkNCgkgIChzZXRxIG1pbi1oZWln aHQgZnJhbWUtbWluLWhlaWdodCkpDQoJICgobnVtYmVycCBtaW4taGVpZ2h0KQ0KCSAgKHNl dHEgbWluLWhlaWdodCAobWluIG1pbi1oZWlnaHQgZnJhbWUtbWluLWhlaWdodCkpKQ0KCSAo dA0KCSAgKGVycm9yICIlcyBpcyBhbiBpbnZhbGlkIG1pbmltdW0gaGVpZ2h0IiBtaW4taGVp Z2h0KSkpDQoJKHNldHEgZGVsdGENCgkgICAgICA7OyBDb3VudCBhIGZpbmFsIG5ld2xpbmUg LSB0aGlzIGNvbXBlbnNhdGVzIGZvciB0aGUNCgkgICAgICA7OyBtaXNzaW5nIHBvc3QtcHJv Y2VzaW5nIHBhcnQgYWZ0ZXIgcmVzaXppbmcgdGhlIGZyYW1lLg0KCSAgICAgICgtICgrIChj b3VudC1zY3JlZW4tbGluZXMgbmlsIG5pbCB0KQ0KCQkgICAgOzsgRm9yIG5vbi1taW5pYnVm ZmVycyBjb3VudCB0aGUgbW9kZSBsaW5lLCBpZiBhbnkuDQoJCSAgICAoaWYgKGFuZCAobm90 ICh3aW5kb3ctbWluaWJ1ZmZlci1wKSkNCgkJCSAgICAgbW9kZS1saW5lLWZvcm1hdCkNCgkJ CTENCgkJICAgICAgMCkNCgkJICAgIDs7IENvdW50IHRoZSBoZWFkZXIgbGluZSwgaWYgYW55 Lg0KCQkgICAgKGlmIGhlYWRlci1saW5lLWZvcm1hdCAxIDApKQ0KCQkgKHdpbmRvdy10b3Rh bC1zaXplKSkpKQ0KICAgICAgOzsgTW92ZSBhd2F5IGZyb20gZmluYWwgbmV3bGluZS4NCiAg ICAgICh3aGVuIChhbmQgKGVvYnApIChib2xwKSAobm90IChib2JwKSkpDQoJKHNldC13aW5k b3ctcG9pbnQgcm9vdCAobGluZS1iZWdpbm5pbmctcG9zaXRpb24gMCkpKQ0KICAgICAgKHNl dC13aW5kb3ctc3RhcnQgcm9vdCAocG9pbnQtbWluKSkNCiAgICAgIChzZXQtd2luZG93LXZz Y3JvbGwgcm9vdCAwKQ0KICAgICAgKGNvbmRpdGlvbi1jYXNlIG5pbA0KCSAgKHNldC1mcmFt ZS1oZWlnaHQNCgkgICBmcmFtZQ0KCSAgIChtaW4gKG1heCAoKyAoZnJhbWUtaGVpZ2h0IGZy YW1lKSBkZWx0YSkNCgkJICAgICBtaW4taGVpZ2h0KQ0KCQltYXgtaGVpZ2h0KSkNCgkoZXJy b3IgKHNldHEgZGVsdGEgbmlsKSkpKQ0KICAgIGRlbHRhKSkNCg0KOzsgVXNhZ2UNCihkZWZ1 biByZWNvdmVyLWZpbGUgKGZpbGUpDQogICJWaXNpdCBmaWxlIEZJTEUsIGJ1dCBnZXQgY29u dGVudHMgZnJvbSBpdHMgbGFzdCBhdXRvLXNhdmUgZmlsZS4iDQogIDs7IEFjdHVhbGx5IHB1 dHRpbmcgdGhlIGZpbGUgbmFtZSBpbiB0aGUgbWluaWJ1ZmZlciBzaG91bGQgYmUgdXNlZA0K ICA7OyBvbmx5IHJhcmVseS4NCiAgOzsgTm90IGp1c3QgYmVjYXVzZSB1c2VycyBvZnRlbiB1 c2UgdGhlIGRlZmF1bHQuDQogIChpbnRlcmFjdGl2ZSAiRlJlY292ZXIgZmlsZTogIikNCiAg KHNldHEgZmlsZSAoZXhwYW5kLWZpbGUtbmFtZSBmaWxlKSkNCiAgKGlmIChhdXRvLXNhdmUt ZmlsZS1uYW1lLXAgKGZpbGUtbmFtZS1ub25kaXJlY3RvcnkgZmlsZSkpDQogICAgICAoZXJy b3IgIiVzIGlzIGFuIGF1dG8tc2F2ZSBmaWxlIiAoYWJicmV2aWF0ZS1maWxlLW5hbWUgZmls ZSkpKQ0KICAobGV0ICgoZmlsZS1uYW1lIChsZXQgKChidWZmZXItZmlsZS1uYW1lIGZpbGUp KQ0KCQkgICAgIChtYWtlLWF1dG8tc2F2ZS1maWxlLW5hbWUpKSkpDQogICAgKGNvbmQgKChp ZiAoZmlsZS1leGlzdHMtcCBmaWxlKQ0KCSAgICAgICAobm90IChmaWxlLW5ld2VyLXRoYW4t ZmlsZS1wIGZpbGUtbmFtZSBmaWxlKSkNCgkgICAgIChub3QgKGZpbGUtZXhpc3RzLXAgZmls ZS1uYW1lKSkpDQoJICAgKGVycm9yICJBdXRvLXNhdmUgZmlsZSAlcyBub3QgY3VycmVudCIN CgkJICAoYWJicmV2aWF0ZS1maWxlLW5hbWUgZmlsZS1uYW1lKSkpDQoJICAoKHdpdGgtdGVt cC1idWZmZXItd2luZG93DQoJICAgICIqRGlyZWN0b3J5KiINCgkgICAgIycobGFtYmRhICh3 aW5kb3cgX3ZhbHVlKQ0KCQkod2l0aC1zZWxlY3RlZC13aW5kb3cgd2luZG93DQoJCSAgKHVu d2luZC1wcm90ZWN0DQoJCSAgICAgICh5ZXMtb3Itbm8tcCAoZm9ybWF0ICJSZWNvdmVyIGF1 dG8gc2F2ZSBmaWxlICVzPyAiIGZpbGUtbmFtZSkpDQoJCSAgICAod2hlbiAod2luZG93LWxp dmUtcCB3aW5kb3cpDQoJCSAgICAgIChxdWl0LXJlc3RvcmUtd2luZG93IHdpbmRvdyAna2ls bCkpKSkpDQoJICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyIHN0YW5kYXJkLW91dHB1dA0KCSAg ICAgIChsZXQgKChzd2l0Y2hlcyBkaXJlZC1saXN0aW5nLXN3aXRjaGVzKSkNCgkJKGlmIChm aWxlLXN5bWxpbmstcCBmaWxlKQ0KCQkgICAgKHNldHEgc3dpdGNoZXMgKGNvbmNhdCBzd2l0 Y2hlcyAiIC1MIikpKQ0KCQk7OyBVc2UgaW5zZXJ0LWRpcmVjdG9yeS1zYWZlbHksIG5vdCBp bnNlcnQtZGlyZWN0b3J5LA0KCQk7OyBiZWNhdXNlIHRoZXNlIGZpbGVzIG1pZ2h0IG5vdCBl eGlzdC4gIEluIHBhcnRpY3VsYXIsDQoJCTs7IEZJTEUgbWlnaHQgbm90IGV4aXN0IGlmIHRo ZSBhdXRvLXNhdmUgZmlsZSB3YXMgZm9yDQoJCTs7IGEgYnVmZmVyIHRoYXQgZGlkbid0IHZp c2l0IGEgZmlsZSwgc3VjaCBhcyAiKm1haWwqIi4NCgkJOzsgVGhlIGNvZGUgaW4gdjIwLngg Y2FsbGVkIGBscycgZGlyZWN0bHksIHNvIHdlIG5lZWQNCgkJOzsgdG8gZW11bGF0ZSB3aGF0 IGBscycgZGlkIGluIHRoYXQgY2FzZS4NCgkJKGluc2VydC1kaXJlY3Rvcnktc2FmZWx5IGZp bGUgc3dpdGNoZXMpDQoJCShpbnNlcnQtZGlyZWN0b3J5LXNhZmVseSBmaWxlLW5hbWUgc3dp dGNoZXMpKSkpDQoJICAgKHN3aXRjaC10by1idWZmZXIgKGZpbmQtZmlsZS1ub3NlbGVjdCBm aWxlIHQpKQ0KCSAgIChsZXQgKChpbmhpYml0LXJlYWQtb25seSB0KQ0KCQkgOzsgS2VlcCB0 aGUgY3VycmVudCBidWZmZXItZmlsZS1jb2Rpbmctc3lzdGVtLg0KCQkgKGNvZGluZy1zeXN0 ZW0gYnVmZmVyLWZpbGUtY29kaW5nLXN5c3RlbSkNCgkJIDs7IEF1dG8tc2F2ZWQgZmlsZSBz aG91bGQgYmUgcmVhZCB3aXRoIHNwZWNpYWwgY29kaW5nLg0KCQkgKGNvZGluZy1zeXN0ZW0t Zm9yLXJlYWQgJ2F1dG8tc2F2ZS1jb2RpbmcpKQ0KCSAgICAgKGVyYXNlLWJ1ZmZlcikNCgkg ICAgIChpbnNlcnQtZmlsZS1jb250ZW50cyBmaWxlLW5hbWUgbmlsKQ0KCSAgICAgKHNldC1i dWZmZXItZmlsZS1jb2Rpbmctc3lzdGVtIGNvZGluZy1zeXN0ZW0pKQ0KCSAgIChhZnRlci1m aW5kLWZpbGUgbmlsIG5pbCB0KSkNCgkgICh0ICh1c2VyLWVycm9yICJSZWNvdmVyLWZpbGUg Y2FuY2VsbGVkIikpKSkpDQoNCihkZWZ1biBzYXZlLWJ1ZmZlcnMta2lsbC1lbWFjcyAoJm9w dGlvbmFsIGFyZykNCiAgIk9mZmVyIHRvIHNhdmUgZWFjaCBidWZmZXIsIHRoZW4ga2lsbCB0 aGlzIEVtYWNzIHByb2Nlc3MuDQpXaXRoIHByZWZpeCBBUkcsIHNpbGVudGx5IHNhdmUgYWxs IGZpbGUtdmlzaXRpbmcgYnVmZmVycyB3aXRob3V0IGFza2luZy4NCklmIHRoZXJlIGFyZSBh Y3RpdmUgcHJvY2Vzc2VzIHdoZXJlIGBwcm9jZXNzLXF1ZXJ5LW9uLWV4aXQtZmxhZycNCnJl dHVybnMgbm9uLW5pbCwgYXNrcyB3aGV0aGVyIHByb2Nlc3NlcyBzaG91bGQgYmUga2lsbGVk Lg0KUnVucyB0aGUgbWVtYmVycyBvZiBga2lsbC1lbWFjcy1xdWVyeS1mdW5jdGlvbnMnIGlu IHR1cm4gYW5kIHN0b3BzDQppZiBhbnkgcmV0dXJucyBuaWwuICBJZiBgY29uZmlybS1raWxs LWVtYWNzJyBpcyBub24tbmlsLCBjYWxscyBpdC4iDQogIChpbnRlcmFjdGl2ZSAiUCIpDQog IChzYXZlLXNvbWUtYnVmZmVycyBhcmcgdCkNCiAgKGFuZCAob3IgKG5vdCAobWVtcSB0ICht YXBjYXIgKGZ1bmN0aW9uDQoJCQkJICAobGFtYmRhIChidWYpIChhbmQgKGJ1ZmZlci1maWxl LW5hbWUgYnVmKQ0KCQkJCQkJICAgICAoYnVmZmVyLW1vZGlmaWVkLXAgYnVmKSkpKQ0KCQkJ CShidWZmZXItbGlzdCkpKSkNCgkgICAoeWVzLW9yLW5vLXAgIk1vZGlmaWVkIGJ1ZmZlcnMg ZXhpc3Q7IGV4aXQgYW55d2F5PyAiKSkNCiAgICAgICAob3IgKG5vdCAoZmJvdW5kcCAncHJv Y2Vzcy1saXN0KSkNCgkgICA7OyBwcm9jZXNzLWxpc3QgaXMgbm90IGRlZmluZWQgb24gTVNE T1MuDQoJICAgKGxldCAoKHByb2Nlc3NlcyAocHJvY2Vzcy1saXN0KSkNCgkJIGFjdGl2ZSkN CgkgICAgICh3aGlsZSBwcm9jZXNzZXMNCgkgICAgICAgKGFuZCAobWVtcSAocHJvY2Vzcy1z dGF0dXMgKGNhciBwcm9jZXNzZXMpKSAnKHJ1biBzdG9wIG9wZW4gbGlzdGVuKSkNCgkJICAg IChwcm9jZXNzLXF1ZXJ5LW9uLWV4aXQtZmxhZyAoY2FyIHByb2Nlc3NlcykpDQoJCSAgICAo c2V0cSBhY3RpdmUgdCkpDQoJICAgICAgIChzZXRxIHByb2Nlc3NlcyAoY2RyIHByb2Nlc3Nl cykpKQ0KCSAgICAgKG9yIChub3QgYWN0aXZlKQ0KCQkgKHdpdGgtdGVtcC1idWZmZXItd2lu ZG93DQoJCSAgKGdldC1idWZmZXItY3JlYXRlICIqUHJvY2VzcyBMaXN0KiIpDQoJCSAgIyco bGFtYmRhICh3aW5kb3cgX3ZhbHVlKQ0KCQkgICAgICAod2l0aC1zZWxlY3RlZC13aW5kb3cg d2luZG93DQoJCQkodW53aW5kLXByb3RlY3QNCgkJCSAgICAoeWVzLW9yLW5vLXAgIkFjdGl2 ZSBwcm9jZXNzZXMgZXhpc3Q7IGtpbGwgdGhlbSBhbmQgZXhpdCBhbnl3YXk/ICIpDQoJCQkg ICh3aGVuICh3aW5kb3ctbGl2ZS1wIHdpbmRvdykNCgkJCSAgICAocXVpdC1yZXN0b3JlLXdp bmRvdyB3aW5kb3cgJ2tpbGwpKSkpKQ0KCQkgIChsaXN0LXByb2Nlc3NlcyB0KSkpKSkNCiAg ICAgICA7OyBRdWVyeSB0aGUgdXNlciBmb3Igb3RoZXIgdGhpbmdzLCBwZXJoYXBzLg0KICAg ICAgIChydW4taG9vay13aXRoLWFyZ3MtdW50aWwtZmFpbHVyZSAna2lsbC1lbWFjcy1xdWVy eS1mdW5jdGlvbnMpDQogICAgICAgKG9yIChudWxsIGNvbmZpcm0ta2lsbC1lbWFjcykNCgkg ICAoZnVuY2FsbCBjb25maXJtLWtpbGwtZW1hY3MgIlJlYWxseSBleGl0IEVtYWNzPyAiKSkN CiAgICAgICAoa2lsbC1lbWFjcykpKQ0KDQooZGVmdW4gZGlyZWQtbWFyay1wb3AtdXAgKGJ1 ZmZlci1vci1uYW1lIG9wLXN5bWJvbCBmaWxlcyBmdW5jdGlvbiAmcmVzdCBhcmdzKQ0KICAi UmV0dXJuIEZVTkNUSU9OJ3MgcmVzdWx0IG9uIEFSR1MgYWZ0ZXIgc2hvd2luZyB3aGljaCBm aWxlcyBhcmUgbWFya2VkLg0KRGlzcGxheXMgdGhlIGZpbGUgbmFtZXMgaW4gYSB3aW5kb3cg c2hvd2luZyBhIGJ1ZmZlciBuYW1lZA0KQlVGRkVSLU9SLU5BTUU7IHRoZSBkZWZhdWx0IG5h bWUgYmVpbmcgXCIgKk1hcmtlZCBGaWxlcypcIi4gIFRoZQ0Kd2luZG93IGlzIG5vdCBzaG93 biBpZiB0aGVyZSBpcyBqdXN0IG9uZSBmaWxlLCBgZGlyZWQtbm8tY29uZmlybScNCmlzIHQs IG9yIE9QLVNZTUJPTCBpcyBhIG1lbWJlciBvZiB0aGUgbGlzdCBpbiBgZGlyZWQtbm8tY29u ZmlybScuDQoNCkZJTEVTIGlzIHRoZSBsaXN0IG9mIG1hcmtlZCBmaWxlcy4gIEl0IGNhbiBh bHNvIGJlICh0IEZJTEVOQU1FKQ0KaW4gdGhlIGNhc2Ugb2Ygb25lIG1hcmtlZCBmaWxlLCB0 byBkaXN0aW5ndWlzaCB0aGF0IGZyb20gdXNpbmcNCmp1c3QgdGhlIGN1cnJlbnQgZmlsZS4N Cg0KRlVOQ1RJT04gc2hvdWxkIG5vdCBtYW5pcHVsYXRlIGZpbGVzLCBqdXN0IHJlYWQgaW5w dXQgXChhbg0KYXJndW1lbnQgb3IgY29uZmlybWF0aW9uKS4iDQogIChpZiAob3IgKGVxIGRp cmVkLW5vLWNvbmZpcm0gdCkNCgkgIChtZW1xIG9wLXN5bWJvbCBkaXJlZC1uby1jb25maXJt KQ0KCSAgOzsgSWYgRklMRVMgZGVmYXVsdGVkIHRvIHRoZSBjdXJyZW50IGxpbmUncyBmaWxl Lg0KCSAgKD0gKGxlbmd0aCBmaWxlcykgMSkpDQogICAgICAoYXBwbHkgZnVuY3Rpb24gYXJn cykNCiAgICAobGV0ICgoYnVmZmVyIChnZXQtYnVmZmVyLWNyZWF0ZSAob3IgYnVmZmVyLW9y LW5hbWUgIiAqTWFya2VkIEZpbGVzKiIpKSkpDQogICAgICAod2l0aC1jdXJyZW50LWJ1ZmZl ciBidWZmZXINCgkobGV0ICgoc3BsaXQtaGVpZ2h0LXRocmVzaG9sZCAwKQ0KCSAgICAgIChk aXNwbGF5LWJ1ZmZlci1hcHAtYWN0aW9uDQoJICAgICAgIChjb25zICdkaXNwbGF5LWJ1ZmZl ci1iZWxvdy1zZWxlY3RlZCBuaWwpKSkNCgkgICh3aXRoLXRlbXAtYnVmZmVyLXdpbmRvdw0K CSAgIGJ1ZmZlcg0KCSAgICMnKGxhbWJkYSAod2luZG93IF92YWx1ZSkNCgkgICAgICAgKHdp dGgtc2VsZWN0ZWQtd2luZG93IHdpbmRvdw0KCQkgKHVud2luZC1wcm90ZWN0DQoJCSAgICAg KGFwcGx5IGZ1bmN0aW9uIGFyZ3MpDQoJCSAgICh3aGVuICh3aW5kb3ctbGl2ZS1wIHdpbmRv dykNCgkJICAgICAocXVpdC1yZXN0b3JlLXdpbmRvdyB3aW5kb3cgJ2tpbGwpKSkpKQ0KCSAg IDs7IEhhbmRsZSAodCBGSUxFKSBqdXN0IGxpa2UgKEZJTEUpLCBoZXJlLiAgVGhhdCB2YWx1 ZSBpcw0KCSAgIDs7IHVzZWQgKG9ubHkgaW4gc29tZSBjYXNlcyksIHRvIG1lYW4ganVzdCBv bmUgZmlsZSB0aGF0IHdhcw0KCSAgIDs7IG1hcmtlZCwgcmF0aGVyIHRoYW4gdGhlIGN1cnJl bnQgbGluZSBmaWxlLg0KCSAgIChkaXJlZC1mb3JtYXQtY29sdW1ucy1vZi1maWxlcw0KCSAg ICAoaWYgKGVxIChjYXIgZmlsZXMpIHQpIChjZHIgZmlsZXMpIGZpbGVzKSkNCgkgICAocmVt b3ZlLXRleHQtcHJvcGVydGllcyAocG9pbnQtbWluKSAocG9pbnQtbWF4KQ0KCQkJCSAgICco bW91c2UtZmFjZSBuaWwgaGVscC1lY2hvIG5pbCkpKSkpKSkpDQo= --------------070709030607050701050304-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 18 12:21:32 2012 Received: (at 11939) by debbugs.gnu.org; 18 Jul 2012 16:21:32 +0000 Received: from localhost ([127.0.0.1]:48747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrX0F-0000QL-JO for submit@debbugs.gnu.org; Wed, 18 Jul 2012 12:21:32 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:33305) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SrX0D-0000QE-Bx for 11939@debbugs.gnu.org; Wed, 18 Jul 2012 12:21:30 -0400 Received: (qmail invoked by alias); 18 Jul 2012 16:15:10 -0000 Received: from 62-47-60-60.adsl.highway.telekom.at (EHLO [62.47.60.60]) [62.47.60.60] by mail.gmx.net (mp033) with SMTP; 18 Jul 2012 18:15:10 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/9sEMlxY79LElkvS2Br4Ufo9zwm4YyY4FZdMjfr+ hRG6mXx2CTiq12 Message-ID: <5006E151.5080301@gmx.at> Date: Wed, 18 Jul 2012 18:16:17 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> In-Reply-To: <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > It does now. I did not realize that creation of a new frame by MS Windows with > the minibuffer frame selected (& having the focus) would change the focus. And > I did not realize that such a change in focus would provoke another invocation > of that function (via command `handle-switch-frame', apparently), with the > minibuffer frame unfocused. Can a minibuffer-less frame get the focus? >> So `1on1-fit-minibuffer-frame' assumes that the selected frame is the >> standalone minibuffer frame and that that frame has focus. Why don't >> you verify all that in the function's body? > > See above - you already asked that. It _is_ the minibuffer frame for the call > that I expected. I did not expect the second call provoked by the frame switch > command (via post-command-hook), with the wrong frame focused. Can you check somehow that the minibuffer-less frame is focussed? >> > The minibuffer was still active, >> >> ... you mean `active-minibuffer-window' returned the window of the >> minibuffer-only frame ... > > No, I meant only that the minibuffer was still active: accepting typed input. When? > My next sentence made it clear that the minibuffer-only frame was NOT selected: > >> > but the selected frame was another one (e.g. *Process List*). > > Now maybe there is no real notion of a minibuffer being active, and it is more > correct to speak of an minibuffer _window_ being active. > > I was describing things from a (possibly naive) user perspective: a > `read-from-minibuffer' was still in progress; the minibuffer was in principle > available for entering text (but its window was not selected). IOW, if it were > selected it would accept input. I don't understand: With `minibuffer-auto-raise' nil you can redirect focus to a frame A while keeping frame B selected. Or am I missing something? I'd rather think that a new popped up frame doesn't have it's focus redirected yet to the minibuffer frame or something like that. > Yes. The focus is in the minibuffer frame. AFAICT, each time > `read-from-minibuffer' is called the focus (correctly) moves to that frame. I > have not noticed any case where that did not happen. Do you think there are > such cases? Apparently just the one where a new frame just popped up. > OK. I'm not familiar with the code, but it's good to know that `h-s-f' (and > presumably also `switch-frame') do not affect focus. IIUC `handle-switch-frame' has to switch focus only if the frame that previosly had focus gets deleted. > I have not noticed that. In fact, I thought that switching frames always did > seem to change the focus. But perhaps it is something else and not just `h-s-f' > that actually causes the focus change (e.g. when you click another frame with > the mouse). Perhaps it is (always?) the window mgr that changes the focus? I don't think so since redirecting frame focus and not bringing the focussed frame to the foreground works. > Yes, but it's still not clear to me just what is going on here. The window mgr > changes the focus when it creates the new frame. But > `1on1-fit-minibuffer-frame' is invoked via `post-command-hook', which means that > there is a command that initiates it. I was thinking that that command must be > `h-s-f', and my testing seemed to confirm that (see fix #3, below), but if it is > not I would like to know what it really is. You can try putting something on `mouse-leave-buffer-hook'. IIUC `handle-switch-frame' calls this even when the mouse is not used. > If the focus change happens via the window mgr after > `1on1-fit-minibuffer-frame', and if `h-s-f' then provokes the second call to > `1on1-fit-minibuffer-frame', how can resetting the focus to the minibuffer frame > before the end of the first `1on1-fit-minibuffer-frame' solve the problem? That > resetting would need to take place after the window mgr changed the focus, no? I suppose that Emacs has selected the new frame but not redirected frame focus yet. Note that each frame (see frame.h) has a focus_frame field which, if nil, tells which frame should get the input. If this field is not set and the new frame does not have a minibuffer, input gets lost until you manually select the minibuffer frame. > > It seems therefor like the window mgr changes the focus _before_ the end of the > first `1on1-fit-minibuffer-frame'. But if I add a `message' call at the end, it > shows that the focus ... I'm not sure whether "the focus" exists. Rather, each frame seems to either have focus itself or have it redirected elsewhere. But there need not exist one single focus for two different frames. > is still in the minibuffer frame. That is what I do not > understand: On the one hand, the focus seems to remain in the minibuffer frame > throughout the first call to `1-f-m-f'. On the other hand, explicitly setting > the focus to the minibuffer frame at the end of `1-f-m-f' solves the problem. > Can you explain that? Because the focus of the new frame was not yet directed to the minibuffer frame, I suppose. > What the function does: fit the minibuffer frame to its displayed content. As I > said, the function should be a no-op if the minibuffer is not active or the > minibuffer frame is not in focus. The minibuffer frame can be in focus all the time without ever being selected. > FYI, this is the full condition under which it will not be a no-op: > > ;; We could assume the minibuffer frame is `1on1-minibuffer-frame', but we do > not. > (and 1on1-fit-minibuffer-frame-flag > (active-minibuffer-window) > ;; Do this because this command is on `post-command-hook', > ;; and an event such as `handle-switch-frame' might have > ;; changed the selected frame. > (eq last-event-frame (window-frame (minibuffer-window))) > (save-selected-window > (select-window (minibuffer-window)) > ;; We should be able to use just (one-window-p), > ;; but an Emacs bug means we need this: > (one-window-p nil 'selected-frame))) > > Perhaps you see some improvement/simplification possible there. (I don't recall > what Emacs bug was involved wrt the last clause or what release that bug is in, > FWIW.) > > And yes, I know that you feel that `one-window-p' is not the right way to check > for one-windowness. But I need this to work for multiple Emacs versions, and so > far I've found that `one-window-p' DTRT. Still, I'm open to suggestions if you > see an improvement here. If you understand it, `one-window-p' is OK. For me the NOMINI and ALL-FRAMES arguments are difficult to understand. >> I think you should make sure two things: (1) >> `1on1-fit-minibuffer-frame' should do something iff the frame in >> question is a minibuffer frame. > > What do you mean by "a minibuffer frame"? It just has a non-nil `minibuffer' > parameter? Or that parameter has a value of `only'? Or something else? I don't know. How do usually check whether you are in your minibuffer frame? > Is the following test not sufficient to ensure that it is "a minibuffer frame"? > > (eq last-event-frame (window-frame (minibuffer-window))) Probably. I'd have to look how this is assigned. > Let me know if you think I should add an additional test or replace that test > with another. > >> (2) `1on1-fit-minibuffer-frame' should avoid having any >> side-effects wrt window selection or focus unless you explictly want that. > > That is the case - it has no side effects wrt window selection or focus. The > selection window and the focus are at the end what they were at the beginning. > > All it does, when it is not a no-op, is (maybe) resize and reposition the > minibuffer frame. OK. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 18 13:30:03 2012 Received: (at 11939) by debbugs.gnu.org; 18 Jul 2012 17:30:03 +0000 Received: from localhost ([127.0.0.1]:48819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrY4Y-0002rl-Re for submit@debbugs.gnu.org; Wed, 18 Jul 2012 13:30:03 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:25934) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrY4W-0002qu-Bh for 11939@debbugs.gnu.org; Wed, 18 Jul 2012 13:30:01 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6IHNoZL002135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 17:23:50 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6IHNnCW026627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 17:23:49 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6IHNn84009074; Wed, 18 Jul 2012 12:23:49 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Jul 2012 10:23:48 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Wed, 18 Jul 2012 10:23:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5006E14B.3000407@gmx.at> Thread-Index: Ac1lAIWhqm0AetOFRregWQ6MPO/WIgABNDAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > I'm using cmd.exe. How? What are you doing to not get this error, which I get when I use emacs -Q without loading the Cygwin stuff? "Spawning child process: invalid argument" > >> I suppose that we should (at least optionally) have all functions > >> accessing the minibuffer redirect frame focus to it first. > > > > I thought that was already the case - it seems to be. In the problem > > reported for this bug the minibuffer frame had the focus, but it then > > lost it because of a frame switch (I mean, because a new frame > > creation by Windows switched the focus). > > As a matter of fact `yes-or-no-p' indirectly calls > read_minibuf which does > > if (!EQ (mini_frame, selected_frame)) > Fredirect_frame_focus (selected_frame, mini_frame); > > So focus is redirected but somehow this doesn't always work > when popping up a new frame. Yes, that's more or less what I was trying to say. My guess is still that it does get redirected but when the frame is popped up the new frame takes the focus. IOW, that redirection was from the frame that was selected before the popped-up frame gets selected/focused. Just a guess, based on what I've seen. > In any case, it's not necessary to do the defaliasing, > `yes-or-no-p' should do the same, in principle. Moreover, my > `redirect-frame-focus' call in `y-or-n-p' was silly because I mixed up > the arguments. So let's forget about this. Forgotten. > I still don't understand the consequences described in the > doc-string of `redirect-frame-focus' as > > A frame's focus redirection can be changed by `select-frame'. > If frame FOO is selected, and then a different frame BAR is > selected, any frames redirecting their focus to FOO are shifted > to redirect their focus to BAR. This allows focus redirection > to work properly when the user switches from one frame to another > using `select-window'. I think that last part means only that focus switches when you select a frame, even if the previously selected frame was not really selected but had the focus only via a redirection from the actually selected frame. > This means that a frame whose focus is redirected to itself is > treated differently from a frame whose focus is redirected to > nil; the former is affected by `select-frame', while the latter is not. It does not say what does affect the latter. Not too clear to me. > so there might be still some surprises around the corner. > > IMHO the thing that's crucial is that if you want to peruse a separate > minibuffer frame after popping up a new frame, you have to do it from > the freshly popped up frame. Sounds reasonable. What might (?) be good would be to find a way to simply counteract (undo) the auto-focus/selection of the new frame whenever focus was in the minibuffer frame (and the minibuffer is active). IOW, perhaps that can be done automatically. Dunno whether doing that systematically would be a good idea or not (or whether it is easy to do). > For example, if you pop up a new frame and > then want to ask a `yes-or-no-p' question, you have to select the new > frame, issue the `yes-or-no-p' there, Yes, that would be one way of solving the problem, perhaps, if we could ensure that that happened. But the ordering of such events might be fragile - and it might depend on the platform etc. > and hope that read_minibuf correctly redirects the prompt to the minibuffer frame. My guess is that it does, always. Again, my guess is that it did that correctly, but the new frame was then created (the creation might have started before the read_minibuf, but the new focus took effect after the redirection to the minibuffer, in any case). Just a guess. > If `minibuffer-auto-raise' is non-nil, this will raise the minibuffer > frame, otherwise it will only redirect input to that frame. I suppose > that was already your understanding of this issue but I was surprised > that issuing the `yes-or-no-p' from an old frame won't work. I'll have to get to the rest of your message(s) a bit later. Thx. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 00:01:17 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 04:01:17 +0000 Received: from localhost ([127.0.0.1]:49222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrhvR-0004tR-As for submit@debbugs.gnu.org; Thu, 19 Jul 2012 00:01:17 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:30549) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrhvO-0004tJ-OX for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 00:01:16 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6J3t1nN016690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 03:55:02 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6J3t0vp008870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 03:55:01 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6J3sxnt003445; Wed, 18 Jul 2012 22:54:59 -0500 Received: from dradamslap1 (/10.159.99.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Jul 2012 20:54:59 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Wed, 18 Jul 2012 20:54:57 -0700 Message-ID: <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5006E14B.3000407@gmx.at> Thread-Index: Ac1lAIWhqm0AetOFRregWQ6MPO/WIgAUnZVA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > I attach yet another version of `with-temp-buffer-window'. Please > test it with #1 > (progn > (load "~/with-temp-buffer-window.el") > (shell) > (setq minibuffer-auto-raise t) ; Optional > (setq pop-up-frame-function > (lambda () (make-frame '((minibuffer . nil))))) > (setq pop-up-frames t)) #2 > (progn > (setq pop-up-frames t) > (load "~/with-temp-buffer-window.el") > (shell)) > > and with your usual settings and tell me what you see. Also test it > with `minibuffer-auto-raise' either nil or t. > > If the above work, test also the delete files in dired scenario. The > first dialogue will probably fail in the usual way, then you have to > load `with-temp-buffer-window.el' once more and try another time. I used my normal setup. I tried #1. No problem. I started again and tried #1 with nil `minibuffer-auto-raise'. Still no problem. I tried #2. Still no problem. My setup already has non-nil pop-up-frames, so apparently all that is needed is your file. If I comment out the load of your file and try #2 then the bugged behavior reappears. So it seems that you have found a solution. > Finally, try to exit it in various ways, for example by > deleting some frame during the dialogue. > I found a not yet 100% reproducible way to crash Emacs doing that. I could not reproduce that problem. I was able, after hitting C-x C-c, to click the corner "X" and thus delete each of the frames. When I did that on the last frame (the minibuffer frame), an Emacs popup window gave me the question about killing active processes (instead of the question appearing in the minibuffer). I clicked the Yes button. Emacs exited normally. Perhaps the crash you see is related to bug #11984, which I see mentioned in passing? ----- But I'm sorry to say that I am totally confused now - not by these recent tests you've had me do with your code, but by the code fix that I reported for my own code (on 7/16), where I spoke of 3 fixes, each of which worked. Now, none of them work. I am certain that before, when I reported them, that each of the 3 fixes worked. (And the same is and was true for all Emacs versions - all worked and now none work.) I do not understand at all. It is true that if I do not add that test of (eq last-event-frame (window-frame (minibuffer-window))), which is fix one I chose, then the *Process List* frame and buffer are current/selected. But that test does _not_ solve the focus problem. I still cannot type "yes" into the minibuffer frame. All that happens is that `1on1-fit-minibuffer-frame' does nothing, and that does not help with the frame focus problem. Similarly if I, instead of that test, add the call to `select-frame-set-input-focus' at the end of the function - that too no longer is a fix. So I am totally confused. I am glad at least that you seem to have found a solution, with your code, for the Emacs 24 case. I'm disappointed and incredulous, however, about my own "fix" that does not work, especially because it worked (on 7/16) in all Emacs versions. I have no idea what is going on. And I'm afraid I'm probably just confusing you now with my current reporting. Calling it a day now. If I figure something out I'll let you know. Sorry for the confusion. Thx - Drew From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 00:03:11 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 04:03:11 +0000 Received: from localhost ([127.0.0.1]:49227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrhxF-0004w8-SN for submit@debbugs.gnu.org; Thu, 19 Jul 2012 00:03:10 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:36038) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrhxC-0004vz-1Y for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 00:03:08 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6J3usia016251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 03:56:55 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6J3urIb015057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 03:56:54 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6J3urOH028776; Wed, 18 Jul 2012 22:56:53 -0500 Received: from dradamslap1 (/10.159.99.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Jul 2012 20:56:53 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Wed, 18 Jul 2012 20:56:50 -0700 Message-ID: <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5006E151.5080301@gmx.at> Thread-Index: Ac1lAIicWAewgj8GSbCoSpO6m9G2LAASVSpw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Can a minibuffer-less frame get the focus? In what scenario? I don't know what you are asking. Of course a minibuffer-less frame can get the focus either programmatically (a function executing in the minibuffer can select another frame) or through user interaction (the user can click another frame, etc.). In my use, the focus can change fairly often, but intentionally (e.g. via a user initiating some command/key from the minibuffer). > >> So `1on1-fit-minibuffer-frame' assumes that the selected > >> frame is the standalone minibuffer frame and that that > >> frame has focus. Why don't you verify all that in the > >> function's body? > > > > See above - you already asked that. It _is_ the > > minibuffer frame for the call that I expected. I did not > > expect the second call provoked by the frame switch > > command (via post-command-hook), with the wrong frame focused. > > Can you check somehow that the minibuffer-less frame is focussed? Again, I don't know what you mean, or how to do that. I'm pretty sure that I saw earlier (e.g. when I reported the bug) that the new frame, which was read-only, had the focus. I could tell via debug messages and because it raised a buffer-read-only error. If I remove the test I added that prevents `1on1-fit...' from doing anything if the minibuffer frame is not selected, I can see that buffer and frame *Process List* are selected. And I believe that that is where the typed input goes in that case. > >> > The minibuffer was still active, > >> > >> ... you mean `active-minibuffer-window' returned the window of the > >> minibuffer-only frame ... > > > > No, I meant only that the minibuffer was still active: > > accepting typed input. > > When? Let's not get confused with the language here. I was not talking about the minibuffer _frame_ accepting input, i.e., having the focus. That is of course the problem. I was talking only about the minibuffer still being active (not exited) and `read-from-minibuffer' still expecting input. > > My next sentence made it clear that the minibuffer-only > > frame was NOT selected: > > > >> > but the selected frame was another one (e.g. *Process List*). > > > > Now maybe there is no real notion of a minibuffer being > > active, and it is more correct to speak of an minibuffer _window_ > > being active. > > > > I was describing things from a (possibly naive) user perspective: a > > `read-from-minibuffer' was still in progress; the minibuffer was in > > principle available for entering text (but its window was not > > selected). IOW, if it were selected it would accept input. > > I don't understand: With `minibuffer-auto-raise' nil you can redirect > focus to a frame A while keeping frame B selected. Or am I missing > something? I'd rather think that a new popped up frame doesn't have > it's focus redirected yet to the minibuffer frame or something like > that. That sounds right to me also. That is what I wrote (as my "guess") in previous messages. > > Yes. The focus is in the minibuffer frame. AFAICT, each time > > `read-from-minibuffer' is called the focus (correctly) > > moves to that frame. I have not noticed any case where that did > > not happen. Do you think there are such cases? > > Apparently just the one where a new frame just popped up. It is still my guess that the focus _was_ directed to the minibuffer for/by `read-from-minibuffer', but that thereafter the new frame was popped up and the window mgr gave it the focus (i.e., took focus away from the minibuffer frame). No, I do not have any proof of that, but that's my conceptual model so far. But you understand this stuff at a better, lower level than I: you understand it at the level of windows etc. It is no doubt correct to speak of the minibuffer window and not (as I did, waving my hands) of the "minibuffer" expecting input. I'm just trying to make sense of this as best I can, without a good understanding of windows and frames etc. You need not pay attention to my interpretations of the behavior. > > OK. I'm not familiar with the code, but it's good to know > > that `h-s-f' (and presumably also `switch-frame') do not affect focus. > > IIUC `handle-switch-frame' has to switch focus only if the frame that > previosly had focus gets deleted. > > > I have not noticed that. In fact, I thought that switching > > frames always did seem to change the focus. But perhaps it is > > something else and not just `h-s-f' that actually causes the > > focus change (e.g. when you click another frame with > > the mouse). Perhaps it is (always?) the window mgr that > > changes the focus? > > I don't think so since redirecting frame focus and not bringing the > focussed frame to the foreground works. I don't see how that contradicts things. I was not saying that a frame could not have the focus unless it was in front. I'm not sure what we're talking about anymore. What seems to me to be happening is that the window mgr gives the new frame the focus. I'm guessing that it does that after the minibuffer already had the focus (correctly), but I don't know that for a fact. But in all other cases (i.e., where there is no such bug), reading from the minibuffer does move the focus to the minibuffer frame. To me, the simplest assumption that fits the observed behavior is that the minibuffer frame did get the focus for reading input, but then the window mgr popped up the new frame and gave it the focus. > > Yes, but it's still not clear to me just what is going on > > here. The window mgr changes the focus when it creates the new > > frame. But `1on1-fit-minibuffer-frame' is invoked via > > `post-command-hook', which means that there is a command that > > initiates it. I was thinking that that command must be > > `h-s-f', and my testing seemed to confirm that (see fix > > #3, below), but if it is not I would like to know what it really is. > > You can try putting something on `mouse-leave-buffer-hook'. IIUC > `handle-switch-frame' calls this even when the mouse is not used. Did you see the #3 that I referenced? It seems pretty clear to me that `h-s-f' is the command whose post-command-hook action invoked `1on1-fit-minibuffer-frame' the second time. That was tested vis `this-command' etc. > > If the focus change happens via the window mgr after > > `1on1-fit-minibuffer-frame', and if `h-s-f' then provokes > > the second call to `1on1-fit-minibuffer-frame', how can > > resetting the focus to the minibuffer frame > > before the end of the first `1on1-fit-minibuffer-frame' > > solve the problem? That resetting would need to take place > > after the window mgr changed the focus, no? > > I suppose that Emacs has selected the new frame but not > redirected frame focus yet. Note that each frame (see frame.h) > has a focus_frame field which, if nil, tells which frame should > get the input. If this field is not set and the new frame does > not have a minibuffer, input gets lost until you manually select > the minibuffer frame. Perhaps that is the explanation. But until I added the test to do nothing if the minibuffer frame was not selected I had the impression that the *Process List* buffer had the focus AND received the typed input. I thought I could tell this from the read-only error. But I no longer see that error message now when I take out that test. I see debug message output saying that the current buffer and current frame are *Process List*. But I guess that is not the same thing as saying that that buffer & frame have the focus for input. When this happens, if I click the frame for *Messages* and then type more input, the debug messages say that the current buffer and frame are *Messages*, but the typed input is not inserted in *Messages*. So maybe you are right that "input gets lost". It does not appear in any frame, at least. Dunno whether the act of adding debug output messages interferes with what's going on at all. > > It seems therefor like the window mgr changes the focus > > _before_ the end of the first `1on1-fit-minibuffer-frame'. > > But if I add a `message' call at the end, it shows that the focus > > ... I'm not sure whether "the focus" exists. Rather, each frame seems > to either have focus itself or have it redirected elsewhere. > But there need not exist one single focus for two different frames. OK. I didn't realize that. So things are more complicated than my simple conceptual model allows. > > is still in the minibuffer frame. That is what I do not > > understand: On the one hand, the focus seems to remain in > > the minibuffer frame throughout the first call to `1-f-m-f'. > > On the other hand, explicitly setting the focus to the > > minibuffer frame at the end of `1-f-m-f' solves the problem. > > Can you explain that? > > Because the focus of the new frame was not yet directed to the > minibuffer frame, I suppose. I guess so. > > What the function does: fit the minibuffer frame to its > > displayed content. As I said, the function should be a > > no-op if the minibuffer is not active or the > > minibuffer frame is not in focus. > > The minibuffer frame can be in focus all the time without > ever being selected. > > If you understand it, `one-window-p' is OK. For me the NOMINI and > ALL-FRAMES arguments are difficult to understand. > > >> I think you should make sure two things: (1) > >> `1on1-fit-minibuffer-frame' should do something iff the frame in > >> question is a minibuffer frame. > > > > What do you mean by "a minibuffer frame"? It just has a > > non-nil `minibuffer' parameter? Or that parameter has a > > value of `only'? Or something else? > > I don't know. How do usually check whether you are in your > minibuffer frame? I don't usually check. But if I did I guess I'd do it the way I do in the code I showed (but which does not seem to work now). But I'm open to suggestions. Keep in mind that, apart from this bug, whenever the minibuffer (window) is active the minibuffer frame is focused (receives the input). > > Is the following test not sufficient to ensure that it is > > "a minibuffer frame"? > > (eq last-event-frame (window-frame (minibuffer-window))) > > Probably. I'd have to look how this is assigned. Thanks for hanging in there. - Drew From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 06:47:20 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 10:47:20 +0000 Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SroGN-0007PD-M5 for submit@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:20 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:47390) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SroGL-0007P5-VR for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:19 -0400 Received: (qmail invoked by alias); 19 Jul 2012 10:41:06 -0000 Received: from 62-47-39-3.adsl.highway.telekom.at (EHLO [62.47.39.3]) [62.47.39.3] by mail.gmx.net (mp040) with SMTP; 19 Jul 2012 12:41:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19zsEB/iQJzfKo0BDtn4FbXTOS5fVP8zXpUmxyucW JHlQh3Ea+Dmb/t Message-ID: <5007E47B.3050907@gmx.at> Date: Thu, 19 Jul 2012 12:42:03 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> In-Reply-To: <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > #1 >> (progn >> (load "~/with-temp-buffer-window.el") >> (shell) >> (setq minibuffer-auto-raise t) ; Optional >> (setq pop-up-frame-function >> (lambda () (make-frame '((minibuffer . nil))))) >> (setq pop-up-frames t)) > > #2 >> (progn >> (setq pop-up-frames t) >> (load "~/with-temp-buffer-window.el") >> (shell)) >> >> and with your usual settings and tell me what you see. Also test it >> with `minibuffer-auto-raise' either nil or t. >> >> If the above work, test also the delete files in dired scenario. The >> first dialogue will probably fail in the usual way, then you have to >> load `with-temp-buffer-window.el' once more and try another time. > > I used my normal setup. I tried #1. No problem. I started again and tried #1 > with nil `minibuffer-auto-raise'. Still no problem. I tried #2. Still no > problem. You should have tried #1 and #2 with emacs -Q. Otherwise, your private settings will shadow #1 and #2 (I tested #1 and #2 here but would like a confirmation). > My setup already has non-nil pop-up-frames, so apparently all that is needed is > your file. If I comment out the load of your file and try #2 then the bugged > behavior reappears. > > So it seems that you have found a solution. Since you do set `pop-up-frames' to non-nil you have inirectly confirmed that it works for your setup. You did not report whether it works for `minibuffer-auto-raise' nil. Can you look into that? >> Finally, try to exit it in various ways, for example by >> deleting some frame during the dialogue. >> I found a not yet 100% reproducible way to crash Emacs doing that. > > I could not reproduce that problem. I was able, after hitting C-x C-c, to click > the corner "X" and thus delete each of the frames. When I did that on the last > frame (the minibuffer frame), an Emacs popup window gave me the question about > killing active processes (instead of the question appearing in the minibuffer). > I clicked the Yes button. Emacs exited normally. > > Perhaps the crash you see is related to bug #11984, which I see mentioned in > passing? No. The crash happens because the following assumption in frame.c /* We know that there must be some frame with a minibuffer out there. If this were not true, all of the frames present would have to be minibufferless, which implies that at some point their minibuffer frames must have been deleted, but that is prohibited at the top; you can't delete surrogate minibuffer frames. */ if (NILP (frame_with_minibuf)) abort (); does not always hold during the exit dialogue. And it's bad because it crashes Emacs when I try to avoid the exit because of a running subprocess. > But I'm sorry to say that I am totally confused now - not by these recent tests > you've had me do with your code, but by the code fix that I reported for my own > code (on 7/16), where I spoke of 3 fixes, each of which worked. > > Now, none of them work. I am certain that before, when I reported them, that > each of the 3 fixes worked. (And the same is and was true for all Emacs > versions - all worked and now none work.) I do not understand at all. Trivial. At the time you wrote the "fixes" you had "fixed" it already by doing something else. Now you "just" have to find out what else you did then ;-) Are you sure you ran your changes without my file loaded? > It is true that if I do not add that test of (eq last-event-frame (window-frame > (minibuffer-window))), which is fix one I chose, then the *Process List* frame > and buffer are current/selected. But that test does _not_ solve the focus > problem. I still cannot type "yes" into the minibuffer frame. If you use Emacs 24.1 without my changes, then `list-processes' will pop up a new frame and give it focus. When it now asks the `y-or-n-p' question you _are_ lost if the new frame does not have a minibuffer and you can't redirect it to one. > All that happens is that `1on1-fit-minibuffer-frame' does nothing, and that does > not help with the frame focus problem. Similarly if I, instead of that test, > add the call to `select-frame-set-input-focus' at the end of the function - that > too no longer is a fix. Try explicitly redirecting the focus from the new frame to the minibuffer-only frame via `redirect-frame-focus'. > So I am totally confused. I am glad at least that you seem to have found a > solution, with your code, for the Emacs 24 case. I'm disappointed and > incredulous, however, about my own "fix" that does not work, especially because > it worked (on 7/16) in all Emacs versions. I have no idea what is going on. Une solution peut en cacher une autre. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 06:47:25 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 10:47:25 +0000 Received: from localhost ([127.0.0.1]:49604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SroGS-0007PT-Gn for submit@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:24 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:56977) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SroGP-0007PL-Vb for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:23 -0400 Received: (qmail invoked by alias); 19 Jul 2012 10:40:51 -0000 Received: from 62-47-39-3.adsl.highway.telekom.at (EHLO [62.47.39.3]) [62.47.39.3] by mail.gmx.net (mp032) with SMTP; 19 Jul 2012 12:40:51 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18UlVJV7vMU9TbCb+B2A0KbRlvI7DDlsmyzZSa7IA tWrkIUHfFR1O3j Message-ID: <5007E46C.7030206@gmx.at> Date: Thu, 19 Jul 2012 12:41:48 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > How? What are you doing to not get this error, which I get when I use emacs -Q > without loading the Cygwin stuff? > > "Spawning child process: invalid argument No idea. Maybe this is the Powershell issue described in http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windows-error-spawning.html I just checked on a SP3 machine and am sure that just installing SP3 is not sufficient for the problem to show up. >> I still don't understand the consequences described in the >> doc-string of `redirect-frame-focus' as >> >> A frame's focus redirection can be changed by `select-frame'. >> If frame FOO is selected, and then a different frame BAR is >> selected, any frames redirecting their focus to FOO are shifted >> to redirect their focus to BAR. This allows focus redirection >> to work properly when the user switches from one frame to another >> using `select-window'. > > I think that last part means only that focus switches when you select a frame, > even if the previously selected frame was not really selected but had the focus > only via a redirection from the actually selected frame. It seems to say that when a frame X has focus redirected to the selected frame A and I now select a frame B then focus for X is redirected to B. But why is that useful? >> This means that a frame whose focus is redirected to itself is >> treated differently from a frame whose focus is redirected to >> nil; the former is affected by `select-frame', while the latter is not. > > It does not say what does affect the latter. Not too clear to me. It seems to say that when a selected frame A's focus is redirected to A itself and I now select frame B, focus from A is redirected to B. Now suppose a minibuffer-only frame is selected and had focus directed to itself. If now a minibuffer-less frame gets selected, focus will be directed to that frame which hardly makes sense to me. >> so there might be still some surprises around the corner. >> >> IMHO the thing that's crucial is that if you want to peruse a separate >> minibuffer frame after popping up a new frame, you have to do it from >> the freshly popped up frame. > > Sounds reasonable. What might (?) be good would be to find a way to simply > counteract (undo) the auto-focus/selection of the new frame whenever focus was > in the minibuffer frame (and the minibuffer is active). IOW, perhaps that can > be done automatically. Dunno whether doing that systematically would be a good > idea or not (or whether it is easy to do). Someone (maybe Jan) once said that it's hard to override any such decisions when they are made by the window manager. >> For example, if you pop up a new frame and >> then want to ask a `yes-or-no-p' question, you have to select the new >> frame, issue the `yes-or-no-p' there, > > Yes, that would be one way of solving the problem, perhaps, if we could ensure > that that happened. But the ordering of such events might be fragile - and it > might depend on the platform etc. IIUC creating a WM window (via CreateWindow) returns a handle to a new WM window independently from whether that window already appears on the screen and/or obscures other windows. I don't know whether and how the window manager informs Emacs that a window has appeared on the screen. I suppose it doesn't and that information is passed to emacs implicitly when the user "selects" that window by using the keyboard or the mouse. >> and hope that read_minibuf correctly redirects the prompt to the minibuffer > frame. > > My guess is that it does, always. Apparently not always as we know meanwhile. > Again, my guess is that it did that > correctly, but the new frame was then created (the creation might have started > before the read_minibuf, but the new focus took effect after the redirection to > the minibuffer, in any case). Just a guess. From what you said it seems to work as long as no new frames are created. When a new frame is created, it may take some time for this mechanism to adapt itself to the new configuration. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 06:47:28 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 10:47:28 +0000 Received: from localhost ([127.0.0.1]:49607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SroGW-0007Ph-17 for submit@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:28 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:58054) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SroGS-0007PS-Cj for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:25 -0400 Received: (qmail invoked by alias); 19 Jul 2012 10:41:12 -0000 Received: from 62-47-39-3.adsl.highway.telekom.at (EHLO [62.47.39.3]) [62.47.39.3] by mail.gmx.net (mp020) with SMTP; 19 Jul 2012 12:41:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19l868px25lf1++GgYh+PtM216hjT2LMhvh3pTzsg 93nHt98+vZ83qB Message-ID: <5007E482.3030401@gmx.at> Date: Thu, 19 Jul 2012 12:42:10 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> In-Reply-To: <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Can a minibuffer-less frame get the focus? > > In what scenario? I don't know what you are asking. > > Of course a minibuffer-less frame can get the focus either programmatically (a > function executing in the minibuffer can select another frame) or through user > interaction (the user can click another frame, etc.). Here and everywhere else I meant focus redirection for interaction with the minibuffer. Obviously `redirect-frame-focus' can redirect focus to a minibuffer-less frame. But choose_minibuf_frame has this /* I don't think that any frames may validly have a null minibuffer window anymore. */ if (NILP (sf->minibuffer_window)) abort (); and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't have a valid minibuffer window, emacs should abort. If it does, the latter if (!EQ (mini_frame, selected_frame)) Fredirect_frame_focus (selected_frame, mini_frame); in read_minibuf should redirect focus but apparently it doesn't. >> >> So `1on1-fit-minibuffer-frame' assumes that the selected >> >> frame is the standalone minibuffer frame and that that >> >> frame has focus. Why don't you verify all that in the >> >> function's body? >> > >> > See above - you already asked that. It _is_ the >> > minibuffer frame for the call that I expected. I did not >> > expect the second call provoked by the frame switch >> > command (via post-command-hook), with the wrong frame focused. >> >> Can you check somehow that the minibuffer-less frame is focussed? > > Again, I don't know what you mean, or how to do that. Probably by checking whether the focus of the minibuffer-less frame A is redirected to the minibuffer-equipped frame B. >> > No, I meant only that the minibuffer was still active: >> > accepting typed input. >> >> When? > > Let's not get confused with the language here. I was not talking about the > minibuffer _frame_ accepting input, i.e., having the focus. That is of course > the problem. > > I was talking only about the minibuffer still being active (not exited) But what does that mean in practice? Apart from looping. > and > `read-from-minibuffer' still expecting input. Obviously so. > It is still my guess that the focus _was_ directed to the minibuffer for/by > `read-from-minibuffer', but that thereafter the new frame was popped up and the > window mgr gave it the focus (i.e., took focus away from the minibuffer frame). From the window manager's POV the minibuffer-less frame does have focus. The emacs redirection mechanism works on top of that. > No, I do not have any proof of that, but that's my conceptual model so far. > > But you understand this stuff at a better, lower level than I: you understand it > at the level of windows etc. I understand next to nothing about WM windows. > It is no doubt correct to speak of the minibuffer > window and not (as I did, waving my hands) of the "minibuffer" expecting input. It makes a difference if you have a minibuffer-less frame that has no minibuffer window it can direct input to. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 13:49:35 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 17:49:35 +0000 Received: from localhost ([127.0.0.1]:51134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Srur1-0003iP-8H for submit@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:35 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:28908) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sruqy-0003iG-N1 for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:33 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6JHhHcF021514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 17:43:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6JHhGqo011196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 17:43:17 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6JHhGDM000679; Thu, 19 Jul 2012 12:43:16 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2012 10:43:16 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Thu, 19 Jul 2012 10:43:15 -0700 Message-ID: <446B437450EC47968D15C20D7142296B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5007E47B.3050907@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac1lmwHphdxJHQrqTYCJlIvGNpd52QAJJpYg X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> and with your usual settings and tell me what you see. > > You should have tried #1 and #2 with emacs -Q. Sorry, I thought that's what you meant by "with your usual settings". > Otherwise, your private settings will shadow #1 and #2 > (I tested #1 and #2 here but would like a confirmation). #1 (emacs -Q): No problem. #2 (emacs -Q): Does not work. The *Process List* frame is in front, and the question is posed in the minibuffer of the *shell* frame. Typing seems to go nowhere, but when I hit RET after typing I get this error msg: yes-or-no-p: Buffer is read-only: # Interestingly, If I then try C-x C-c from *Messages*, after manually bring that frame to the front, then again *Process List* is moved to the front and the question is posed in the *Messages* frame. I expect that info might help, and perhaps you guessed already that that would happen. > You did not report whether it works for `minibuffer-auto-raise' nil. > Can you look into that? It is nil by default, no? So the tests for #2 test that. But #1 with the value nil works also. The only difference is that with the value nil the *Process List* frame is foremost (in front), and with it t the *shell* frame is in foremost. It's a choice, I guess, whether it is more important to see all of the question (prompt) or to see the *Process List* buffer completely. I'm not sure I have a settled opinion about that. In the case of emacs -Q, where there is no standalone minibuffer frame, I think the best behavior (if possible) would be to have the question appear in the minibuffer of the *Process List* frame (and have that frame be foremost). In the case of a standalone minibuffer frame, the best behavior is probably to always have the minibuffer frame foremost (at least when it asks a question). Typically, a user with a standalone m. frame has it positioned out of the way as much as possible. In my case, for instance, it stretches across the bottom of my screen (and new frames are popped up by the window mgr at or near the top of the screen). > > Perhaps the crash you see is related to bug #11984, which > > I see mentioned in passing? > > No. The crash happens because the following assumption in frame.c > > /* We know that there must be some frame with a minibuffer out > there. If this were not true, all of the frames present > would have to be minibufferless, which implies that at some > point their minibuffer frames must have been deleted, but > that is prohibited at the top; you can't delete surrogate > minibuffer frames. */ > if (NILP (frame_with_minibuf)) > abort (); > > does not always hold during the exit dialogue. And it's bad > because it crashes Emacs when I try to avoid the exit because > of a running subprocess. Got it. I don't get a crash (on MS Windows). Are you seeing the crash on MS Windows also? > Trivial. At the time you wrote the "fixes" you had "fixed" it already > by doing something else. Now you "just" have to find out > what else you did then ;-) Are you sure you ran your changes without > my file loaded? No, I'm not sure. In fact, I thought about that after sending my last mail (I was tired at the time). And looking over the thread I see now that I must have been loading your (earlier) code also. The problem I was looking into at the time was why your code made things work with emacs -Q but not with my setup. The fix to my code no doubt enabled your fix to do its job. But I thought that I had tested with all Emacs versions, and they all worked after my fix. I'll have to revisit this when I get some time. I imagine that your code is applicable only to Emacs 24+ (is that right?), so it could not have helped fix things with my setup for other Emacs versions. > If you use Emacs 24.1 without my changes, then `list-processes' will > pop up a new frame and give it focus. When it now asks the `y-or-n-p' > question you _are_ lost if the new frame does not have a minibuffer and > you can't redirect it to one. Got it. What about other Emacs releases - are relevant at all in this context? Should we expect that your code can help them also? > > All that happens is that `1on1-fit-minibuffer-frame' does > > nothing, and that does not help with the frame focus problem. > > Similarly if I, instead of that test, add the call to > > `select-frame-set-input-focus' at the end of the function - that > > too no longer is a fix. > > Try explicitly redirecting the focus from the new frame to the > minibuffer-only frame via `redirect-frame-focus'. Where? At the end of `1on1-fit-minibuffer-frame', instead of `select-frame-set-input-focus'? And would this be in order to try to make things work even without your code (e.g., for older Emacs versions)? Because if not I do not need to do it, since the code I have now already works well in Emacs 24, when I use your code also. IOW, I'm not clear what you are suggesting, and what problem it might solve. If it is a possible cure for the problem in other Emacs versions, e.g. without your code, then I'll definitely try it. > Une solution peut en cacher une autre. :-D Ca y est. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 13:49:44 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 17:49:44 +0000 Received: from localhost ([127.0.0.1]:51137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Srur9-0003ii-Oe for submit@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:44 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:49597) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Srur7-0003ia-Je for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:42 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6JHhRMN019105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 17:43:28 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6JHhQHN011379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 17:43:27 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6JHhQMn031564; Thu, 19 Jul 2012 12:43:26 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2012 10:43:26 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <5007E46C.7030206@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Thu, 19 Jul 2012 10:43:25 -0700 Message-ID: <55F70CDDACA84503826C907CDE8CE684@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5007E46C.7030206@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac1lmwOyi4HyinGRQiG+loiJiua8XQAMggCA X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > "Spawning child process: invalid argument > > No idea. Maybe this is the Powershell issue described in > http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windo > ws-error-spawning.html > > I just checked on a SP3 machine and am sure that just > installing SP3 is not sufficient for the problem to show up. I do not have/use Powershell, AFAIK. But I see that my env var SHELL has the value "/bin/bash". That is no doubt the cause. > >> I still don't understand the consequences described in the > >> doc-string of `redirect-frame-focus' as > >> > >> A frame's focus redirection can be changed by `select-frame'. > >> If frame FOO is selected, and then a different frame BAR is > >> selected, any frames redirecting their focus to FOO > >> are shifted to redirect their focus to BAR. This allows focus > >> redirection to work properly when the user switches from one > >> frame to another using `select-window'. > > > > I think that last part means only that focus switches when > > you select a frame, even if the previously selected frame > > was not really selected but had the focus > > only via a redirection from the actually selected frame. > > It seems to say that when a frame X has focus redirected to > the selected frame A and I now select a frame B then focus > for X is redirected to B. But why is that useful? The reason given is to pass redirection on, when you switch to another frame. But I agree that it is not clear, and I too wonder about the usefulness. I would think that redirection should be a simple mapping from one frame to another. Now maybe what was really meant is that if X redirects to Y and Y redirects to Z then X ends up redirecting to Z. That would make sense (and also go without saying). Dunno. > >> This means that a frame whose focus is redirected to itself is > >> treated differently from a frame whose focus is redirected to > >> nil; the former is affected by `select-frame', while > >> the latter is not. > > > > It does not say what does affect the latter. Not too clear to me. > > It seems to say that when a selected frame A's focus is > redirected to A itself and I now select frame B, focus from A is > redirected to B. Yes, I think it says that. And it says that a frame that is redirected to nil is not affected by select-frame. (It does not say what does affect a frame that is redirected to nil.) > Now suppose a minibuffer-only frame is selected and had focus directed to > itself. If now a minibuffer-less frame gets selected, focus will be > directed to that frame which hardly makes sense to me. I agree. But why would someone redirect the minibuffer frame's focus to itself? What are you envisioning? FWIW, the only redirection that I use (AFAIK) is to redirect my *Completions* (special-display) frame to the minibuffer frame. That seems to work just as I would expect - no problems. But nothing prevents you from explicitly selecting *Completions* and even trying to type input there, even when the minibuffer is active. But *Completions* is read-only, so if you do that you get a read-only error. For example, in the minibuffer, Icicle mode binds `C-insert' to a command that does (select-window (get-buffer-window "*Completions*" 0)). You can do various things there, but if you try to type a self-inserting char or delete a char then you get this error: "Buffer is read-only: #". > Someone (maybe Jan) once said that it's hard to override any such > decisions when they are made by the window manager. I did not mean override (prevent/nullify). I meant automatically take remedial action after the window manager's autofocus takes effect. I.e., automatically move the focus back where it was. But again, I have no idea whether (a) that is easy to do or (b) whether it is really a good idea to do it. > IIUC creating a WM window (via CreateWindow) returns a handle to a new > WM window independently from whether that window already > appears on the screen and/or obscures other windows. > > I don't know whether and how the window manager informs Emacs > that a window has appeared on the screen. I suppose it doesn't > and that information is passed to emacs implicitly > when the user "selects" that window by using the keyboard or > the mouse. How does Emacs determine the selected frame? Doesn't the code of `selected-frame' help understand this? > >> and hope that read_minibuf correctly redirects the prompt > >> to the minibuffer frame. > > > > My guess is that it does, always. > > Apparently not always as we know meanwhile. I did not really mean "redirects the prompt". I was thinking of it moving the input focus (which would also put the prompt where that focus is, presumably). My guess was/is that it might always move the focus to the minibuffer frame, but that the focus is then moved away from it to the new frame that is popped up. How do you know that that is not what happens? I.e., how do you know that there are some situations where the focus is *not* (initially) switched to the minibuffer frame? (I'm not saying you are wrong - just wondering how you know that.) > > Again, my guess is that it did that > > correctly, but the new frame was then created (the > > creation might have started before the read_minibuf, but the > > new focus took effect after the redirection to > > the minibuffer, in any case). Just a guess. > > From what you said it seems to work as long as no new frames are > created. When a new frame is created, it may take some time for this > mechanism to adapt itself to the new configuration. Perhaps, but waiting does not help. Perhaps you meant that there is some timeout and if things are too slow then the focus is automatically moved to the new frame? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 19 13:52:04 2012 Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 17:52:04 +0000 Received: from localhost ([127.0.0.1]:51142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrutP-0003mG-GD for submit@debbugs.gnu.org; Thu, 19 Jul 2012 13:52:04 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:32384) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrutO-0003mA-1Q for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 13:52:03 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6JHjlsA023758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 17:45:48 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6JHjlcS012749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 17:45:47 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6JHjlV0002473; Thu, 19 Jul 2012 12:45:47 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2012 10:45:46 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Thu, 19 Jul 2012 10:45:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5007E482.3030401@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac1lmwV80SFb8pWLRfSiqc3AiprHqQAN2XBw X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > But choose_minibuf_frame has this > > /* I don't think that any frames may validly have a > null minibuffer window anymore. */ > if (NILP (sf->minibuffer_window)) > abort (); Wow, that comment seems weird. Unless a frame that has nil as the value of its `minibuffer' frame parameter is still expected to have a minibuffer _window_. That's a distinction that is beyond me. I do not claim to understand things at the Emacs window level. But certainly there can be frames that have no minibuffer - their `minibuffer' frame parameter value is nil. > and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't > have a valid minibuffer window, emacs should abort. What does abort mean here - does it mean that Emacs exits? > If it does, the latter > if (!EQ (mini_frame, selected_frame)) > Fredirect_frame_focus (selected_frame, mini_frame); > > in read_minibuf should redirect focus but apparently it doesn't. Again, are you sure it does not? I've been (stubbornly) guessing that it always does, but then, in the problematic case we've been looking at, the focus is grabbed away and given to the new frame that is popped up. I understand that you don't see it that way, that you instead guess that in this problematic case there is never any redirection of focus to the minibuffer frame. But I haven't yet understood why you think that. (I do not say you are wrong.) > >> >> So `1on1-fit-minibuffer-frame' assumes that the selected > >> >> frame is the standalone minibuffer frame and that that > >> >> frame has focus. Why don't you verify all that in the > >> >> function's body? > >> > > >> > See above - you already asked that. It _is_ the > >> > minibuffer frame for the call that I expected. I did not > >> > expect the second call provoked by the frame switch > >> > command (via post-command-hook), with the wrong frame focused. > >> > >> Can you check somehow that the minibuffer-less frame is focussed? > > > > Again, I don't know what you mean, or how to do that. > > Probably by checking whether the focus of the minibuffer-less > frame A is redirected to the minibuffer-equipped frame B. I don't know how to do that. And in `1on1-fit-minibuffer-frame' I do not know how to find out what the minibuffer-less frame is. That function is just invoked by `post-command-hook'. It seems that in the problematic case it is command `handle-switch-frame' that is the command current when `post-command-hook' does its thing here. But I don't know how to determine what frame was switched to. I can check `selected-frame', which is what I do, but I'm not sure what you are suggesting I do. > > I was talking only about the minibuffer still being active > > (not exited) > > But what does that mean in practice? Apart from looping. In my mind it means only that (active-minibuffer-window) returns non-nil. But again, I'm really no expert on this stuff, and I do not pretend to understand what really happens, especially at the level of Emacs windows. AFAIK, the only test available to Lisp programmers to tell whether the minibuffer is active (expecting input), wherever it might be located, is `active-minibuffer-window'. > > It is still my guess that the focus _was_ directed to the > > minibuffer for/by `read-from-minibuffer', but that thereafter > > the new frame was popped up and the window mgr gave it the focus > > (i.e., took focus away from the minibuffer frame). > > From the window manager's POV the minibuffer-less frame does have > focus. OK, but did the minibuffer frame ever receive the focus, after `read-from-minibuffer' was invoked? That's the question that I think we are assuming different answers to. I'm guessing yes, and I think you are saying no. I'm guessing yes, but then the window mgr gave the focus instead to the new frame it created. > The emacs redirection mechanism works on top of that. > > > No, I do not have any proof of that, but that's my > > conceptual model so far. > > > > But you understand this stuff at a better, lower level > > than I: you understand it at the level of windows etc. > > I understand next to nothing about WM windows. Me too. I meant Emacs windows. > > It is no doubt correct to speak of the minibuffer > > window and not (as I did, waving my hands) of the > > "minibuffer" expecting input. > > It makes a difference if you have a minibuffer-less frame that has no > minibuffer window it can direct input to. OK. What's needed I guess is to make sure somehow that every frame redirects input to the minibuffer frame when the minibuffer becomes active. Perhaps it would help to imagine the new frame scenario a bit like the switch-to-*Completions*-frame scenario (dunno). As I mentioned in my other reply today, you can, when the minibuffer is active, explicitly switch the focus to the *Completions* frame, to do something there (e.g. move to some completion candidate). In Icicles you can do this by hitting `C-insert' from the minibuffer (i.e., in a minibuffer keymap). You can then switch back to the minibuffer by hitting `C-insert' again (this time, that's a key binding in `completion-list-mode-map'). For example, you can use `C-insert' to move to *Completions*, then move to a particular completion, then use `C-insert' to move back to the minibuffer. The latter `C-insert' brings the candidate back, i.e., inserts it into the minibuffer. Now in the case of the new frame that is popped up while reading from the minibuffer, the window mgr (I'm supposing) does the equivalent of my `C-insert': it switches the focus to the new frame, just like `C-insert' switches the focus to *Completions*. That's not an intention on the part of the user, but it happens (due to MS Windows). So a possible (hack) solution, if we could detect that unprogrammed (in Emacs) focus switch, might be to automatically switch focus back to the minibuffer frame (IF the minibuffer is active). Does this new frame creation necessarily go through Emacs `make-frame'? Maybe there is a hook there that could be used for such a hack? Dunno - just some rough ideas. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 21 07:07:36 2012 Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 11:07:36 +0000 Received: from localhost ([127.0.0.1]:54076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsXX5-0002LI-4f for submit@debbugs.gnu.org; Sat, 21 Jul 2012 07:07:35 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:53084) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SsXX1-0002L8-ST for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 07:07:33 -0400 Received: (qmail invoked by alias); 21 Jul 2012 11:01:08 -0000 Received: from 62-47-44-153.adsl.highway.telekom.at (EHLO [62.47.44.153]) [62.47.44.153] by mail.gmx.net (mp012) with SMTP; 21 Jul 2012 13:01:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19kI6NdY0tkU/XikJSppINQvlPgPXJrbUOCtuEqOM OVfOlggm5fO0pB Message-ID: <500A8C0E.4040006@gmx.at> Date: Sat, 21 Jul 2012 13:01:34 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> In-Reply-To: <446B437450EC47968D15C20D7142296B@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > #2 (emacs -Q): Does not work. The *Process List* frame is in front, and the > question is posed in the minibuffer of the *shell* frame. Typing seems to go > nowhere, but when I hit RET after typing I get this error msg: > > yes-or-no-p: Buffer is read-only: # > > Interestingly, If I then try C-x C-c from *Messages*, after manually bring that > frame to the front, then again *Process List* is moved to the front and the > question is posed in the *Messages* frame. I expect that info might help, and > perhaps you guessed already that that would happen. Are you sure you started Emacs again before you went through (progn (setq pop-up-frames t) (load "~/with-temp-buffer-window.el") (shell)) Here I get a new frame in the foreground, focussed, with the process list in its root window and the `yes-or-no-p' prompt in its minibuffer window. Please try once more. If this does not work on your system, we might have a smoking gun. >> You did not report whether it works for `minibuffer-auto-raise' nil. >> Can you look into that? > > It is nil by default, no? So the tests for #2 test that. It's a NOOP for #2. > But #1 with the value nil works also. The only difference is that with the > value nil the *Process List* frame is foremost (in front), and with it t the > *shell* frame is in foremost. > > It's a choice, I guess, whether it is more important to see all of the question > (prompt) or to see the *Process List* buffer completely. I'm not sure I have a > settled opinion about that. Occasionally they obscure each other. > In the case of emacs -Q, where there is no standalone minibuffer frame, I think > the best behavior (if possible) would be to have the question appear in the > minibuffer of the *Process List* frame (and have that frame be foremost). That's what happens here in scenario #2. > In the case of a standalone minibuffer frame, the best behavior is probably to > always have the minibuffer frame foremost (at least when it asks a question). > Typically, a user with a standalone m. frame has it positioned out of the way as > much as possible. In my case, for instance, it stretches across the bottom of > my screen (and new frames are popped up by the window mgr at or near the top of > the screen). In any case, this is what the user may customize via `minibuffer-auto-raise'. > Got it. I don't get a crash (on MS Windows). Are you seeing the crash on MS > Windows also? On Windows. > But I thought that I had tested with all Emacs versions, and they all worked > after my fix. I'll have to revisit this when I get some time. I imagine that > your code is applicable only to Emacs 24+ (is that right?), so it could not have > helped fix things with my setup for other Emacs versions. Yes. But maybe you could adapt your buffer display function accordingly. >> If you use Emacs 24.1 without my changes, then `list-processes' will >> pop up a new frame and give it focus. When it now asks the `y-or-n-p' >> question you _are_ lost if the new frame does not have a minibuffer and >> you can't redirect it to one. > > Got it. What about other Emacs releases - are relevant at all in this context? > Should we expect that your code can help them also? If you have an appropriate hook. >> Try explicitly redirecting the focus from the new frame to the >> minibuffer-only frame via `redirect-frame-focus'. > > Where? At the end of `1on1-fit-minibuffer-frame', instead of > `select-frame-set-input-focus'? I think so. > And would this be in order to try to make things work even without your code > (e.g., for older Emacs versions)? Because if not I do not need to do it, since > the code I have now already works well in Emacs 24, when I use your code also. > > IOW, I'm not clear what you are suggesting, and what problem it might solve. If > it is a possible cure for the problem in other Emacs versions, e.g. without your > code, then I'll definitely try it. If your `1on1-fit-minibuffer-frame' can hook in after the new frame pops up, it might be worth a try. With `temp-output-buffer-show' the only suitable hook at your disposition is `temp-buffer-show-hook' where selecting another window won't work because the hook's call is wrapped in `with-selected-window'. But you can remember the new frame's window and select it later, for example, in `post-command-hook'. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 21 07:08:07 2012 Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 11:08:07 +0000 Received: from localhost ([127.0.0.1]:54085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsXXa-0002MZ-Qf for submit@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:07 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:55197) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SsXXW-0002M0-1C for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:03 -0400 Received: (qmail invoked by alias); 21 Jul 2012 11:01:39 -0000 Received: from 62-47-44-153.adsl.highway.telekom.at (EHLO [62.47.44.153]) [62.47.44.153] by mail.gmx.net (mp038) with SMTP; 21 Jul 2012 13:01:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+e4tlNTiWe4vxJaltcx2guE5SuF5voFYX/Xjrmwq yqV0zRSIWn6sB7 Message-ID: <500A8C2D.8040005@gmx.at> Date: Sat, 21 Jul 2012 13:02:05 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> But choose_minibuf_frame has this >> >> /* I don't think that any frames may validly have a >> null minibuffer window anymore. */ >> if (NILP (sf->minibuffer_window)) >> abort (); > > Wow, that comment seems weird. Unless a frame that has nil as the value of its > `minibuffer' frame parameter is still expected to have a minibuffer _window_. > That's a distinction that is beyond me. I do not claim to understand things at > the Emacs window level. Usually, each frame must have a minibuffer window. How else should `read-minibuffer' work? But within the C routines this invariant seems too strong. > But certainly there can be frames that have no minibuffer - their `minibuffer' > frame parameter value is nil. That's a different story. IIUC only the selected frame must have the minibuffer_window slot always set. >> and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't >> have a valid minibuffer window, emacs should abort. > > What does abort mean here - does it mean that Emacs exits? Ungracefully, yes. >> If it does, the latter >> if (!EQ (mini_frame, selected_frame)) >> Fredirect_frame_focus (selected_frame, mini_frame); >> >> in read_minibuf should redirect focus but apparently it doesn't. > > Again, are you sure it does not? I've been (stubbornly) guessing that it always > does, but then, in the problematic case we've been looking at, the focus is > grabbed away and given to the new frame that is popped up. > > I understand that you don't see it that way, that you instead guess that in this > problematic case there is never any redirection of focus to the minibuffer > frame. But I haven't yet understood why you think that. (I do not say you are > wrong.) As explained many times before I'm just speculating. Note, however, that the redirection in the code above works only for the selected frame. That's why I ask the `yes-or-no-p' questions with the new frame selected. >> Probably by checking whether the focus of the minibuffer-less >> frame A is redirected to the minibuffer-equipped frame B. > > I don't know how to do that. > > And in `1on1-fit-minibuffer-frame' I do not know how to find out what the > minibuffer-less frame is. That function is just invoked by `post-command-hook'. > > It seems that in the problematic case it is command `handle-switch-frame' that > is the command current when `post-command-hook' does its thing here. But I > don't know how to determine what frame was switched to. I can check > `selected-frame', which is what I do, but I'm not sure what you are suggesting I > do. Why don't you try what I suggested earlier: Put something on `mouse-leave-buffer-hook' and in a `pre-' or `post-command-hook' check whether that something got executed. Then you can be sure that somewhere in between a `handle-switch-frame' interfered. > OK, but did the minibuffer frame ever receive the focus, after > `read-from-minibuffer' was invoked? That's the question that I think we are > assuming different answers to. I'm guessing yes, and I think you are saying no. > I'm guessing yes, but then the window mgr gave the focus instead to the new > frame it created. So you mean the following happens: (1) Emacs ask a `yes-or-no-p' with input focus directed to frame A. (2) The window manager redirects focus to the new frame B and the `handle-switch-frame' which should redirect focus from B to A gets delayed as long as Emacs waits for minibuffer input. > OK. What's needed I guess is to make sure somehow that every frame redirects > input to the minibuffer frame when the minibuffer becomes active. Which won't help in (2) above. > Perhaps it would help to imagine the new frame scenario a bit like the > switch-to-*Completions*-frame scenario (dunno). > > As I mentioned in my other reply today, you can, when the minibuffer is active, > explicitly switch the focus to the *Completions* frame, to do something there > (e.g. move to some completion candidate). Which function precisely does that? > So a possible (hack) solution, if we could detect that unprogrammed (in Emacs) > focus switch, might be to automatically switch focus back to the minibuffer > frame (IF the minibuffer is active). Or assume that the focus switch happened and react accordingly. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 21 07:08:27 2012 Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 11:08:27 +0000 Received: from localhost ([127.0.0.1]:54092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsXXt-0002NI-98 for submit@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:56634) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SsXXp-0002N4-IV for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:23 -0400 Received: (qmail invoked by alias); 21 Jul 2012 11:01:28 -0000 Received: from 62-47-44-153.adsl.highway.telekom.at (EHLO [62.47.44.153]) [62.47.44.153] by mail.gmx.net (mp019) with SMTP; 21 Jul 2012 13:01:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1838YUVhwk3XRy+QkSsGJiHl/HlXVXeprNeWsVl1C /vCNfqBDZBUX7A Message-ID: <500A8C22.7000706@gmx.at> Date: Sat, 21 Jul 2012 13:01:54 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <5007E46C.7030206@gmx.at> <55F70CDDACA84503826C907CDE8CE684@us.oracle.com> In-Reply-To: <55F70CDDACA84503826C907CDE8CE684@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Now maybe what was really meant is that if X redirects to Y and Y redirects to Z > then X ends up redirecting to Z. That would make sense (and also go without > saying). Dunno. Maybe because it would be too easy to introduce circular redirection this way. >> Now suppose a minibuffer-only frame is selected and had focus directed to >> itself. If now a minibuffer-less frame gets selected, focus will be >> directed to that frame which hardly makes sense to me. > > I agree. But why would someone redirect the minibuffer frame's focus to itself? Indeed, that would not be reasonable. > What are you envisioning? I was only speculating. >> Someone (maybe Jan) once said that it's hard to override any such >> decisions when they are made by the window manager. > > I did not mean override (prevent/nullify). I meant automatically take remedial > action after the window manager's autofocus takes effect. I.e., automatically > move the focus back where it was. I'm not quite sure what "after" means in this context. IIUC Emacs is not informed that the frame has been posted on screen. It will know about it only implicitly when it's passed input directed to that frame. >> IIUC creating a WM window (via CreateWindow) returns a handle to a new >> WM window independently from whether that window already >> appears on the screen and/or obscures other windows. >> >> I don't know whether and how the window manager informs Emacs >> that a window has appeared on the screen. I suppose it doesn't >> and that information is passed to emacs implicitly >> when the user "selects" that window by using the keyboard or >> the mouse. > > How does Emacs determine the selected frame? Doesn't the code of > `selected-frame' help understand this? Emacs selects a new frame. But if it's minibufferless, it doesn't necesarily redirect input to the minibuffer frame. IIUC it does so only when it reads input from that frame. > I did not really mean "redirects the prompt". I was thinking of it moving the > input focus (which would also put the prompt where that focus is, presumably). I suppose we mean the same here. > My guess was/is that it might always move the focus to the minibuffer frame, but > that the focus is then moved away from it to the new frame that is popped up. The window manager moves the focus to the new frame and Emacs selects it. But Emacs apparently does not redirect input focus. > How do you know that that is not what happens? I.e., how do you know that there > are some situations where the focus is *not* (initially) switched to the > minibuffer frame? (I'm not saying you are wrong - just wondering how you know > that.) I have no other explanation. >> From what you said it seems to work as long as no new frames are >> created. When a new frame is created, it may take some time for this >> mechanism to adapt itself to the new configuration. > > Perhaps, but waiting does not help. Perhaps you meant that there is some > timeout and if things are too slow then the focus is automatically moved to the > new frame? My speculation is still the same: The window manager focuses the new frame and Emacs does not redirect input to the minibuffer frame. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 21 14:19:52 2012 Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 18:19:52 +0000 Received: from localhost ([127.0.0.1]:55859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseHO-0005Uj-Rj for submit@debbugs.gnu.org; Sat, 21 Jul 2012 14:19:51 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:44505) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseHL-0005Ua-Jw for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 14:19:48 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6LIDL0l009890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2012 18:13:21 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6LIDJE0005313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jul 2012 18:13:20 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6LIDJIQ029005; Sat, 21 Jul 2012 13:13:19 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jul 2012 11:13:19 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sat, 21 Jul 2012 11:13:10 -0700 Message-ID: <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500A8C0E.4040006@gmx.at> Thread-Index: Ac1nMCWREn6FNGxRSSKBDn+crtxr9AAGWyzA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Are you sure you started Emacs again before you went through > (progn > (setq pop-up-frames t) > (load "~/with-temp-buffer-window.el") > (shell)) > > Here I get a new frame in the foreground, focussed, with the process > list in its root window and the `yes-or-no-p' prompt in its minibuffer > window. Please try once more. If this does not work on your > system, we might have a smoking gun. My bad, I think. I think what I did was forget to load your code (!). I tried again, using emacs -Q with the following, and it did what you say (i.e., no problem): (progn (load-file "~/drews-lisp-20/contrib/cygwin-mount.el") (load-file "~/drews-lisp-20/setup-cygwin.el") (setq pop-up-frames t) (load "~/with-temp-buffer-window.el") (shell)) > >> You did not report whether it works for > `minibuffer-auto-raise' nil. > >> Can you look into that? > > > > It is nil by default, no? So the tests for #2 test that. > > It's a NOOP for #2. I tried also with the above code, inserting (setq minibuffer-auto-raise nil) after (shell). No problem, and no difference from not having that code. > > the best behavior (if possible) would be to have the > > question appear in the minibuffer of the *Process List* > > frame (and have that frame be foremost). > > That's what happens here in scenario #2. Same here. > > Got it. I don't get a crash (on MS Windows). Are you > > seeing the crash on MS Windows also? > > On Windows. Hm. > > I imagine that your code is applicable only to Emacs 24+ > > (is that right?), so it could not have > > helped fix things with my setup for other Emacs versions. > > Yes. But maybe you could adapt your buffer display function > accordingly. What do you mean? > > What about other Emacs releases - are relevant at > > all in this context? > > Should we expect that your code can help them also? > > If you have an appropriate hook. Meaning? Is this something I can do (how)? > >> Try explicitly redirecting the focus from the new frame to the > >> minibuffer-only frame via `redirect-frame-focus'. > > > > Where? At the end of `1on1-fit-minibuffer-frame', instead of > > `select-frame-set-input-focus'? > > I think so. > > > And would this be in order to try to make things work even > > without your code (e.g., for older Emacs versions)? Because if > > not I do not need to do it, since the code I have now already > > works well in Emacs 24, when I use your code also. > > > > IOW, I'm not clear what you are suggesting, and what > > problem it might solve. If it is a possible cure for the problem > > in other Emacs versions, e.g. without your code, then I'll > > definitely try it. > > If your `1on1-fit-minibuffer-frame' can hook in after the new > frame pops up, it might be worth a try. With > `temp-output-buffer-show' the only suitable hook at your > disposition is `temp-buffer-show-hook' where selecting another > window won't work because the hook's call is wrapped in > `with-selected-window'. But you can remember the new > frame's window and select it later, for example, in > `post-command-hook'. I don't understand everything you said, but that's OK - I can refer back to it later if I need to try to understand more. I tried adding this at the end of `1on1-fit-minibuffer-frame', instead of guarding the function with the test (eq last-event-frame (window-frame (minibuffer-window))): (redirect-frame-focus last-event-frame (window-frame (minibuffer-window))) Is that what you meant? That works, in all Emacs versions, even without your code! And so does using this in its place: (select-frame-set-input-focus (window-frame (minibuffer-window))) (Is there a difference? What is the advantage of either?) But there is a problem, for Emacs 23+. It happens in my setup, with the call to `redirect-frame-focus' added at the end of `1on1-fit-minibuffer-frame'. I can also repro it with a reduced version of my setup - essentially loading oneonone.el and fit-frame.el and doing (add-hook 'post-command-hook '1on1-fit-minibuffer-frame) so that I pick up the redirection that is needed. [BTW, for oneonone.el users who do not use fit-frame.el I suppose I will put the redirection directly on `post-command-hook', instead of putting it at the end of `1on1-fit-minibuffer-frame'. I will no doubt have to use a similar guard: do nothing unless (a) the minibuffer window is active, (b) the minibuffer frame is `last-event-frame', and (c) the minibuffer window is alone in its frame.] Anyway, this the problem: 1. When I do C-x C-c, and respond to the yes/no question, it seems I must wait a tiny bit before typing yes/no. Otherwise, the first char (e.g. `y') is lost, so I end up with just `es' (I see the `y' nowhere). Not a big deal; just FYI. 2. If I type "no," and then I do `C-x k', then even though *Process List* has its frame border highlighted as if it is selected, the buffer proposed for deletion is *shell*. OK, so I kill *shell*, and confirm ("yes') to kill its processes also. (BTW, `C-x k' in my setup also deletes the window/frame.) So far, so good. But if I try to use `C-x k' again to kill *Process List*, then, as soon as I hit the `k': a. The default buffer to kill is proposed as some other buffer, not *Process List* (in my setup the default value is automatically inserted in the minibuffer, so I can see it without doing M-n). b. Emacs crashes, but gives no "fatal error" dialog box - hence no way to access gdb. It just directly shows the MS Windows dialog box for sending an error report to MS. When I click yes/no in that dialog box Emacs exits (disappears). I can repro this systematically, but there seems to be no way to use gdb. If I do something else instead of `C-x k' - e.g. `C-x o', then there is no problem. I can, for instance, use `C-x o' to move among frames (`C-x o' moves to the other frame in my setup, if there is no other window on the same frame), coming eventually to *Process List*, and then use `C-x k' to kill *Process List*. This crash is reproducible also with Emacs 23.3, not just with the latest Emacs 24 build. It does not happen with Emacs 22.3, however. Dunno whether this crash is related to the crashes you are seeing. Anyway, it seems we are very close, for my needs. I suppose I can put that redirection on `post-command-hook' (instead of in `1on1-fit-minibuffer-frame', which some oneonone.el users will not use), and things should generally work. I will try that next. Another problem I saw, when I used only a reduced version of my setup, was that (presumably because of the redirection?) `query-replace' no longer worked: When I hit `y' or `.' to replace, no replacement occurred. I will try later to repro this etc. I want to get this info off to you now so you can digest it. Thx - Drew From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 21 14:20:30 2012 Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 18:20:30 +0000 Received: from localhost ([127.0.0.1]:55864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseI2-0005Vz-1n for submit@debbugs.gnu.org; Sat, 21 Jul 2012 14:20:30 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:40167) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseHz-0005Vs-Sw for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 14:20:28 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6LIE2wF010180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2012 18:14:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6LIE1XR001984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jul 2012 18:14:01 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6LIE1cq029170; Sat, 21 Jul 2012 13:14:01 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jul 2012 11:14:01 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <5007E46C.7030206@gmx.at> <55F70CDDACA84503826C907CDE8CE684@us.oracle.com> <500A8C22.7000706@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sat, 21 Jul 2012 11:13:52 -0700 Message-ID: <1918C98634184976B0C93FFC5F5CF7BE@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500A8C22.7000706@gmx.at> Thread-Index: Ac1nMEBkudDnmUz9T5yaC0tpTB7taAAONeKQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> Someone (maybe Jan) once said that it's hard to override any such > >> decisions when they are made by the window manager. > > > > I did not mean override (prevent/nullify). I meant > > automatically take remedial action after the window manager's > > autofocus takes effect. I.e., automatically > > move the focus back where it was. > > I'm not quite sure what "after" means in this context. IIUC Emacs is > not informed that the frame has been posted on screen. It will know > about it only implicitly when it's passed input directed to > that frame. OK. I really know nothing about this area. > Emacs selects a new frame. But if it's minibufferless, it doesn't > necesarily redirect input to the minibuffer frame. IIUC it > does so only when it reads input from that frame. I see. And if reading from the minibuffer was already started (e.g. before the new frame was actually created) then the new frame will not have its focus directed to the minibuffer, even though reading is in progress. > My speculation is still the same: The window manager focuses the new > frame and Emacs does not redirect input to the minibuffer frame. OK. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 21 14:20:35 2012 Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 18:20:35 +0000 Received: from localhost ([127.0.0.1]:55867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseI6-0005WF-Nx for submit@debbugs.gnu.org; Sat, 21 Jul 2012 14:20:35 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:51440) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseI4-0005W6-1T for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 14:20:32 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6LIE6kx014105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2012 18:14:07 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6LIE5o5000640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jul 2012 18:14:06 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6LIE5Ot013958; Sat, 21 Jul 2012 13:14:05 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jul 2012 11:14:05 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> <500A8C2D.8040005@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Sat, 21 Jul 2012 11:13:56 -0700 Message-ID: <2F2A096477C74296B873241B8AD78AF5@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500A8C2D.8040005@gmx.at> Thread-Index: Ac1nMDWpYd1RKO4ETqOC49nYWo/0AAANk/kw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Usually, each frame must have a minibuffer window. How else should > `read-minibuffer' work? It can read from the minibuffer in a standalone minibuffer frame? > But within the C routines this invariant seems too strong. > > > But certainly there can be frames that have no minibuffer > > - their `minibuffer' frame parameter value is nil. > > That's a different story. IIUC only the selected frame must have the > minibuffer_window slot always set. That's what I was guessing, that a frame's `minibuffer' parameter might be non-nil but it somehow has a minibuffer _window_. Seems odd, but I guess these things are at two different levels. I am used to the Lisp & frame level - I know almost nothing about the C & window level. > >> Fredirect_frame_focus (selected_frame, mini_frame); in > >> read_minibuf should redirect focus but apparently it doesn't. > > > > Again, are you sure...?... > > I'm just speculating. Note, however, that the redirection > in the code above works only for the selected frame. > That's why I ask the `yes-or-no-p' questions with the > new frame selected. > > Why don't you try what I suggested earlier: Put something on > `mouse-leave-buffer-hook' and in a `pre-' or > `post-command-hook' check whether that something got executed. > Then you can be sure that somewhere in between a > `handle-switch-frame' interfered. Sorry, I don't follow you (and I haven't found where you suggested something similar earlier). If you can be more specific I'll be glad to try whatever you ask. > > did the minibuffer frame ever receive the focus, after > > `read-from-minibuffer' was invoked? That's the question > > that I think we are assuming different answers to. I'm > > guessing yes, and I think you are saying no. > > I'm guessing yes, but then the window mgr gave the focus > > instead to the new frame it created. > > So you mean the following happens: > > (1) Emacs ask a `yes-or-no-p' with input focus directed to frame A. > > (2) The window manager redirects focus to the new frame B and the > `handle-switch-frame' which should redirect focus from B > to A gets delayed as long as Emacs waits for minibuffer input. I didn't mean that, but maybe that's what happens. All I meant was that (I'm guessing that): a. Emacs asks the question, directing focus to the minibuffer frame for the user to input a response. b. MS Windows creates the new frame and gives it the focus, taking the focus away from the minibuffer. > > OK. What's needed I guess is to make sure somehow that > > every frame redirects input to the minibuffer frame when > > the minibuffer becomes active. > > Which won't help in (2) above. Right, and maybe not in my supposition either. > > Perhaps it would help to imagine the new frame scenario a > > bit like the switch-to-*Completions*-frame scenario (dunno). > > > > As I mentioned in my other reply today, you can, when the > > minibuffer is active, explicitly switch the focus to the > > *Completions* frame, to do something there > > (e.g. move to some completion candidate). > > Which function precisely does that? With just oneonone.el loaded (which creates a standalone minibuffer and special-display *Help* and *Completions*, with the latter frame redirected to the minibuffer frame), even just `C-x o' during completion will do it. I.e., from the minibuffer, `C-x o' moves you (focus) to *Completions*. Or you can click *Completions* with the mouse - same effect. In Icicles, you can use C- to flip back and forth between the minibuffer and *Completions*. C- is command `switch-to-*Completions*' in the minibuffer completion keymaps, and C- is command `icicle-insert-completion' in keymap `completion-list-mode-map'. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 04:54:47 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 08:54:47 +0000 Received: from localhost ([127.0.0.1]:56807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ssrw7-0001LL-6p for submit@debbugs.gnu.org; Sun, 22 Jul 2012 04:54:47 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52709) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Ssrw4-0001LB-B5 for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 04:54:45 -0400 Received: (qmail invoked by alias); 22 Jul 2012 08:48:15 -0000 Received: from 62-47-34-6.adsl.highway.telekom.at (EHLO [62.47.34.6]) [62.47.34.6] by mail.gmx.net (mp070) with SMTP; 22 Jul 2012 10:48:15 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+mm2QRurmmSw2xFWyIQVayb55VEZN2joPOywpU27 /529s373z8fY65 Message-ID: <500BBE6F.6020007@gmx.at> Date: Sun, 22 Jul 2012 10:48:47 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> In-Reply-To: <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > I imagine that your code is applicable only to Emacs 24+ >> > (is that right?), so it could not have >> > helped fix things with my setup for other Emacs versions. >> >> Yes. But maybe you could adapt your buffer display function >> accordingly. > > What do you mean? Write you own version of `special-display-popup-frame' replacing (let* ((frame (with-current-buffer buffer (make-frame (append args special-display-frame-alist)))) (window (frame-selected-window frame))) (display-buffer-record-window 'frame window buffer) (set-window-dedicated-p window t) with something like (let* ((frame (with-current-buffer buffer (make-frame (append args special-display-frame-alist)))) (window (frame-selected-window frame))) (with-selected-window window (redirect-frame-focus frame last-event-frame)) (display-buffer-record-window 'frame window buffer) (set-window-dedicated-p window t) where I used `last-event-frame' because you mentioned it. I'm not familiar with that variable. >> > What about other Emacs releases - are relevant at >> > all in this context? >> > Should we expect that your code can help them also? >> >> If you have an appropriate hook. > > Meaning? Is this something I can do (how)? The above should be applicable to earlier versions to. > (redirect-frame-focus last-event-frame > (window-frame (minibuffer-window))) > > Is that what you meant? Not really because I don't understand the semantics of `last-event-frame' well enough. But if it works, all the better. > That works, in all Emacs versions, even without your code! And so does using > this in its place: > > (select-frame-set-input-focus > (window-frame (minibuffer-window))) > > (Is there a difference? What is the advantage of either?) If you do this wrapped in a `with-selected-window' it should do the same as `redirect-frame-focus'. Otherwise, it will probably bring the frame into foreground. If `redirect-frame-focus' works, stay with it. > 1. When I do C-x C-c, and respond to the yes/no question, it seems I must wait a > tiny bit before typing yes/no. Otherwise, the first char (e.g. `y') is lost, so > I end up with just `es' (I see the `y' nowhere). Not a big deal; just FYI. Does this happen _only_ with your code or also in the emacs -Q scenarios _without_ your code? What happens with a `y-or-no-p' defalias? > 2. If I type "no," and then I do `C-x k', then even though *Process List* has > its frame border highlighted as if it is selected, the buffer proposed for > deletion is *shell*. OK, so I kill *shell*, and confirm ("yes') to kill its > processes also. (BTW, `C-x k' in my setup also deletes the window/frame.) So > far, so good. > > But if I try to use `C-x k' again to kill *Process List*, then, as soon as I hit > the `k': > > a. The default buffer to kill is proposed as some other buffer, not *Process > List* (in my setup the default value is automatically inserted in the > minibuffer, so I can see it without doing M-n). > > b. Emacs crashes, but gives no "fatal error" dialog box - hence no way to access > gdb. It just directly shows the MS Windows dialog box for sending an error > report to MS. When I click yes/no in that dialog box Emacs exits (disappears). Could be the abort in delete_frame I've told you about. Why don't you run Emacs in the debugger jsut from the beginning? (In a running instance of Emacs go to the src directory, type M-x gdb, give your full-path emacs.exe as argument, type "run" and do your things until the emacs fired up this way becomes unresponsive. A "bt full" in the first instance should tell you what happened.) > I can repro this systematically, but there seems to be no way to use gdb. If I > do something else instead of `C-x k' - e.g. `C-x o', then there is no problem. > I can, for instance, use `C-x o' to move among frames (`C-x o' moves to the > other frame in my setup, if there is no other window on the same frame), coming > eventually to *Process List*, and then use `C-x k' to kill *Process List*. > > This crash is reproducible also with Emacs 23.3, not just with the latest Emacs > 24 build. It does not happen with Emacs 22.3, however. Dunno whether this > crash is related to the crashes you are seeing. > > Anyway, it seems we are very close, for my needs. I suppose I can put that > redirection on `post-command-hook' (instead of in `1on1-fit-minibuffer-frame', > which some oneonone.el users will not use), and things should generally work. I > will try that next. That's a bad idea in my opinion. Redirect as soon as possible. Why don't you use `after-make-frame-functions'? martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 04:55:29 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 08:55:29 +0000 Received: from localhost ([127.0.0.1]:56811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ssrwm-0001MY-PC for submit@debbugs.gnu.org; Sun, 22 Jul 2012 04:55:29 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:53962) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Ssrwl-0001MR-Cg for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 04:55:28 -0400 Received: (qmail invoked by alias); 22 Jul 2012 08:48:59 -0000 Received: from 62-47-34-6.adsl.highway.telekom.at (EHLO [62.47.34.6]) [62.47.34.6] by mail.gmx.net (mp001) with SMTP; 22 Jul 2012 10:48:59 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19DZbRy1ihDYTCmoQUa1YWP0HUFYI8aQsM3jrHNKx d6X9QiL0GrATpH Message-ID: <500BBE9B.3080006@gmx.at> Date: Sun, 22 Jul 2012 10:49:31 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> <500A8C2D.8040005@gmx.at> <2F2A096477C74296B873241B8AD78AF5@us.oracle.com> In-Reply-To: <2F2A096477C74296B873241B8AD78AF5@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Usually, each frame must have a minibuffer window. How else should >> `read-minibuffer' work? > > It can read from the minibuffer in a standalone minibuffer frame? Is this a question or an answer? > That's what I was guessing, that a frame's `minibuffer' parameter might be > non-nil but it somehow has a minibuffer _window_. Seems odd, but I guess these > things are at two different levels. I am used to the Lisp & frame level - I > know almost nothing about the C & window level. Emacs must be able to work internally even if you make all your frames minibuffer-less. >> `mouse-leave-buffer-hook' and in a `pre-' or >> `post-command-hook' check whether that something got executed. >> Then you can be sure that somewhere in between a >> `handle-switch-frame' interfered. > > Sorry, I don't follow you (and I haven't found where you suggested something > similar earlier). If you can be more specific I'll be glad to try whatever you > ask. When you want to check of `handle-switch-frame' executions you cannot trace otherwise and you do not run emacs in the debugger, the most simple way to trace these is to put some function on `mouse-leave-buffer-hook', and inspect the output of that function later on. > All I meant was that (I'm guessing that): > > a. Emacs asks the question, directing focus to the minibuffer frame for the user > to input a response. > > b. MS Windows creates the new frame and gives it the focus, taking the focus > away from the minibuffer. I can live with that assumption. >> > As I mentioned in my other reply today, you can, when the >> > minibuffer is active, explicitly switch the focus to the >> > *Completions* frame, to do something there >> > (e.g. move to some completion candidate). >> >> Which function precisely does that? > > With just oneonone.el loaded (which creates a standalone minibuffer and > special-display *Help* and *Completions*, with the latter frame redirected to > the minibuffer frame), even just `C-x o' during completion will do it. I.e., > from the minibuffer, `C-x o' moves you (focus) to *Completions*. > > Or you can click *Completions* with the mouse - same effect. > > In Icicles, you can use C- to flip back and forth between the minibuffer > and *Completions*. C- is command `switch-to-*Completions*' in the > minibuffer completion keymaps, and C- is command > `icicle-insert-completion' in keymap `completion-list-mode-map'. I see. On first reading I missed the term "explictly". IIUC what we need is a mechansim that switches frames implicitly to the minibuffer frame. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 12:53:41 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 16:53:41 +0000 Received: from localhost ([127.0.0.1]:57838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SszPY-0006D4-KU for submit@debbugs.gnu.org; Sun, 22 Jul 2012 12:53:41 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:20975) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SszPU-0006Cv-Vv for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 12:53:38 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6MGl6b2000485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2012 16:47:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6MGl5FT005772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 16:47:05 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6MGl5v8005817; Sun, 22 Jul 2012 11:47:05 -0500 Received: from dradamslap1 (/10.159.217.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 09:47:04 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sun, 22 Jul 2012 09:46:51 -0700 Message-ID: <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500BBE6F.6020007@gmx.at> Thread-Index: Ac1n5r1RXTf1E07lTgO2h5EDNqL/2wAPUdBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> > I imagine that your code is applicable only to Emacs 24+ > >> > (is that right?), so it could not have > >> > helped fix things with my setup for other Emacs versions. > >> > >> Yes. But maybe you could adapt your buffer display function > >> accordingly. > > > > What do you mean? > > Write you own version of `special-display-popup-frame' replacing > ... with something like... > where I used `last-event-frame' because you mentioned it. I'm not > familiar with that variable. I really don't want to get into more redefining of such stuff if I can avoid it. But we'll see. I never heard of `last-event-frame' either until this thread, when I started looking at this stuff more closely, trying to find something that would help. > >> > What about other Emacs releases - are relevant at > >> > all in this context? Should we expect that your code > >> > can help them also? > >> > >> If you have an appropriate hook. > > > > Meaning? Is this something I can do (how)? > > The above should be applicable to earlier versions to. What do you mean by "the above" here? The redefinition code you just suggested (elided above) or something else? > > (redirect-frame-focus last-event-frame > > (window-frame (minibuffer-window))) > > Is that what you meant? > > Not really because I don't understand the semantics of > `last-event-frame' well enough. But if it works, all the better. > > > That works, in all Emacs versions, even without your code! > > And so does using this in its place: > > > > (select-frame-set-input-focus > > (window-frame (minibuffer-window))) > > > > (Is there a difference? What is the advantage of either?) > > If you do this wrapped in a `with-selected-window' it should > do the same as `redirect-frame-focus'. Otherwise, it will > probably bring the frame into foreground. If > `redirect-frame-focus' works, stay with it. Got it. Good to know that difference. > > 1. When I do C-x C-c, and respond to the yes/no question, > > it seems I must wait a tiny bit before typing yes/no. > > Otherwise, the first char (e.g. `y') is lost, so > > I end up with just `es' (I see the `y' nowhere). Not a > > big deal; just FYI. > > Does this happen _only_ with your code or also in the emacs > -Q scenarios _without_ your code? What happens with a > `y-or-no-p' defalias? Not sure what you mean. There is no equivalent in the emacs -Q tests you asked me to do. There is nothing on post-command-hook etc. > Could be the abort in delete_frame I've told you about. Why don't you > run Emacs in the debugger jsut from the beginning? (In a running > instance of Emacs go to the src directory, type M-x gdb, give your > full-path emacs.exe as argument, type "run" and do your > things until the emacs fired up this way becomes unresponsive. > A "bt full" in the first instance should tell you what happened.) I must be missing something when I try to follow that recipe. I started Emacs with my setup. I moved to the src directory (in Emacs 24.1, since I don't have src for later builds - but Emacs 24.1 has the same problem). I typed M-x gdb, appended c:/Emacs-24.1/bin/emacs.exe and hit RET. That seemed to pop up a new emacs -Q session (splash page, none of my customizations, minibuffer in the same frame, etc.), with this message in buffer *Warnings*, whose window split the screen with the splash page: "Error (initialization): User has no home directory" (There are no messages in *Messages*.) And in buffer *gud-emacs.exe* I see this: (gdb) run Starting program: /cygdrive/c/Emacs-24.1/bin/emacs.exe Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll Loaded symbols for /cygdrive/c/WINDOWS/WinSxS/X86_Microsoft.Windows.Common-Controls_6595b64144ccf1d f_6.0.2600.6028_x-ww_61e65202/comctl32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/msvcrt.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/gdi32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/user32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/shlwapi.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/comdlg32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/shell32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/mpr.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/ole32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/usp10.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/winmm.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/winspool.drv Should I have appended something different to `M-x gdb'? This is what I use when I start Emacs with my setup: C:\Emacs-24.1\bin\runemacs.exe --debug-init That is what I used this time too, before using `M-x gdb' in src/. > > Anyway, it seems we are very close, for my needs. I > > suppose I can put that redirection on `post-command-hook' > > (instead of in `1on1-fit-minibuffer-frame', which some > > oneonone.el users will not use), and things should > > generally work. I will try that next. > > That's a bad idea in my opinion. Redirect as soon as possible. Why > don't you use `after-make-frame-functions'? I'm not sure what you mean. I tried this: 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'. 2. Put back the guard (eq last-event-frame (window-frame (minibuffer-window))) at the beginning of `1on1-fit-minibuffer-frame' (so it is a no-op otherwise). 3. Defined this and added it to `after-make-frame-functions': (defun 1on1-redirect-to-minibuffer (new-frame) "..." (when (and 1on1-fit-minibuffer-frame-flag (active-minibuffer-window) (save-selected-window (select-window (minibuffer-window)) (one-window-p nil 'selected-frame))) (redirect-frame-focus new-frame (window-frame (minibuffer-window))))) That did not help at all. The original symptoms returned (typing yes/no did not go to the minibuffer etc.). From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 13:02:40 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 17:02:40 +0000 Received: from localhost ([127.0.0.1]:57872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SszYF-0006QK-M3 for submit@debbugs.gnu.org; Sun, 22 Jul 2012 13:02:40 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:51604) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SszYB-0006QC-R9 for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 13:02:37 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6MGu5FT003791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2012 16:56:06 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6MGu4g6014742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 16:56:05 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6MGu4bx018111; Sun, 22 Jul 2012 11:56:04 -0500 Received: from dradamslap1 (/10.159.217.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 09:56:04 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> <500A8C2D.8040005@gmx.at> <2F2A096477C74296B873241B8AD78AF5@us.oracle.com> <500BBE9B.3080006@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Sun, 22 Jul 2012 09:55:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500BBE9B.3080006@gmx.at> Thread-Index: Ac1n5tby4hHLUxsGSPymF2Pct6PhsQAQwQwA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> Usually, each frame must have a minibuffer window. How > >> else should `read-minibuffer' work? > > > > It can read from the minibuffer in a standalone minibuffer frame? > > Is this a question or an answer? An answer, followed by "Is that not correct?", since I'm not sure we're talking about the same thing. I would expect that it is obvious to you too that Emacs can read from a minibuffer in a standalone frame. And it's not clear to me why that possibility is not an answer to your question. Keep in mind that I do not understand windows, including minibuffer windows, at the level you do. > > That's what I was guessing, that a frame's `minibuffer' > > parameter might be non-nil but it somehow has a minibuffer > > _window_. Seems odd, but I guess these things are at two > > different levels. I am used to the Lisp & frame level - I > > know almost nothing about the C & window level. > > Emacs must be able to work internally even if you make all your frames > minibuffer-less. I never claimed otherwise. But I don't see the relation here. And I do not make all my frames minibuffer-less. So I guess I'm not following you very well. > >> `mouse-leave-buffer-hook' and in a `pre-' or > >> `post-command-hook' check whether that something got executed. > >> Then you can be sure that somewhere in between a > >> `handle-switch-frame' interfered. > > > > Sorry, I don't follow you (and I haven't found where you > > suggested something similar earlier). If you can be more > > specific I'll be glad to try whatever you ask. > > When you want to check of `handle-switch-frame' executions you cannot > trace otherwise and you do not run emacs in the debugger, the most > simple way to trace these is to put some function on > `mouse-leave-buffer-hook', and inspect the output of that > function later on. OK, but I still do not know what you would like me to do/test. Can you give me a recipe to test? > I see. On first reading I missed the term "explictly". IIUC what we > need is a mechansim that switches frames implicitly to the minibuffer > frame. Yes, I think so. But the trick might be to do this only when it should be done. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 13:13:16 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 17:13:16 +0000 Received: from localhost ([127.0.0.1]:57883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsziW-0006ew-3C for submit@debbugs.gnu.org; Sun, 22 Jul 2012 13:13:16 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:51950) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsziT-0006en-Bd for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 13:13:14 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M7K00000NFFKN00@a-mtaout20.012.net.il> for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 20:06:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7K000NANJ68F90@a-mtaout20.012.net.il>; Sun, 22 Jul 2012 20:06:42 +0300 (IDT) Date: Sun, 22 Jul 2012 20:06:45 +0300 From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' In-reply-to: <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <838veb209m.fsf@gnu.org> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Date: Sun, 22 Jul 2012 09:46:51 -0700 > Cc: 11939@debbugs.gnu.org > > > Could be the abort in delete_frame I've told you about. Why don't you > > run Emacs in the debugger jsut from the beginning? (In a running > > instance of Emacs go to the src directory, type M-x gdb, give your > > full-path emacs.exe as argument, type "run" and do your > > things until the emacs fired up this way becomes unresponsive. > > A "bt full" in the first instance should tell you what happened.) > > I must be missing something when I try to follow that recipe. > > I started Emacs with my setup. I moved to the src directory (in Emacs 24.1, > since I don't have src for later builds - but Emacs 24.1 has the same problem). > I typed M-x gdb, appended c:/Emacs-24.1/bin/emacs.exe and hit RET. > > That seemed to pop up a new emacs -Q session (splash page, none of my > customizations, minibuffer in the same frame, etc.), with this message in buffer > *Warnings*, whose window split the screen with the splash page: > > "Error (initialization): User has no home directory" > > (There are no messages in *Messages*.) > > And in buffer *gud-emacs.exe* I see this: > > (gdb) run > Starting program: /cygdrive/c/Emacs-24.1/bin/emacs.exe > Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll > Loaded symbols for > /cygdrive/c/WINDOWS/WinSxS/X86_Microsoft.Windows.Common-Controls_6595b64144ccf1d > f_6.0.2600.6028_x-ww_61e65202/comctl32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/msvcrt.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/gdi32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/user32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/shlwapi.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/comdlg32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/shell32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/mpr.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/ole32.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/usp10.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/winmm.dll > Loaded symbols for /cygdrive/c/WINDOWS/system32/winspool.drv > > Should I have appended something different to `M-x gdb'? This is what I use > when I start Emacs with my setup: > > C:\Emacs-24.1\bin\runemacs.exe --debug-init Don't invoke GDB from inside Emacs, that's only good when you do that from the same version of Emacs you are debugging, and even then there are a few gotchas. Instead, go to the directory where you have .gdbinit, and type from the shell prompt: >gdb /path/to/emacs.exe RET When GDB ends its initialization and shows the "(gdb)" prompt, type: (gdb) run --debug-init You should now have your normal Emacs session, with all the customizations you normally have. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 15:49:43 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 19:49:43 +0000 Received: from localhost ([127.0.0.1]:57978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St29v-0001f0-Ah for submit@debbugs.gnu.org; Sun, 22 Jul 2012 15:49:43 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:33478) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St29t-0001et-Am for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 15:49:42 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6MJh8mQ030137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2012 19:43:09 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6MJh8T9027754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 19:43:08 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6MJh8Oq007694; Sun, 22 Jul 2012 14:43:08 -0500 Received: from dradamslap1 (/10.159.217.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 12:43:07 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sun, 22 Jul 2012 12:42:54 -0700 Message-ID: <8C6D5530BE054E50BA934C60A6FC86E9@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <838veb209m.fsf@gnu.org> Thread-Index: Ac1oLF/gRE9RxIQkRPurYCvZXJsADAAFXxQw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Don't invoke GDB from inside Emacs, that's only good when you do that > from the same version of Emacs you are debugging, and even then there > are a few gotchas. > > Instead, go to the directory where you have .gdbinit, and type from > the shell prompt: > >gdb /path/to/emacs.exe RET > > When GDB ends its initialization and shows the "(gdb)" prompt, type: > (gdb) run --debug-init OK, thanks. I did exactly that. > You should now have your normal Emacs session, with all the > customizations you normally have. No, unfortunately, I get exactly the same behavior described earlier: an emacs -Q session with a splash screen and a displayed buffer *Warnings* with this message: Error (initialization): User has no home directory And no messages in *Messages*, except this: Warning: Lisp directory `c:/Emacs-24-2012-07-16/../site-lisp' does not exist. For information about GNU Emacs and the GNU system, type C-h C-a. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 16:56:31 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 20:56:31 +0000 Received: from localhost ([127.0.0.1]:58009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3CY-00037G-RS for submit@debbugs.gnu.org; Sun, 22 Jul 2012 16:56:31 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:43744) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3CU-000375-Po for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 16:56:28 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M7K00200XT7RY00@a-mtaout20.012.net.il> for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 23:49:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7K002A7XV6LW40@a-mtaout20.012.net.il>; Sun, 22 Jul 2012 23:49:54 +0300 (IDT) Date: Sun, 22 Jul 2012 23:49:57 +0300 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' In-reply-to: <8C6D5530BE054E50BA934C60A6FC86E9@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <834noz1pxm.fsf@gnu.org> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <8C6D5530BE0@[87.69.210.75]> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Sun, 22 Jul 2012 12:42:54 -0700 > > > Don't invoke GDB from inside Emacs, that's only good when you do that > > from the same version of Emacs you are debugging, and even then there > > are a few gotchas. > > > > Instead, go to the directory where you have .gdbinit, and type from > > the shell prompt: > > >gdb /path/to/emacs.exe RET > > > > When GDB ends its initialization and shows the "(gdb)" prompt, type: > > (gdb) run --debug-init > > OK, thanks. I did exactly that. > > > You should now have your normal Emacs session, with all the > > customizations you normally have. > > No, unfortunately, I get exactly the same behavior described earlier: an emacs > -Q session with a splash screen and a displayed buffer *Warnings* with this > message: > > Error (initialization): User has no home directory ^^^^^^^^^^^^^^^^^^^^^^^^^^^ What does that last message tell you? I think this is the key to unlock your mystery. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 17:08:48 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 21:08:48 +0000 Received: from localhost ([127.0.0.1]:58017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3OR-0003OW-GN for submit@debbugs.gnu.org; Sun, 22 Jul 2012 17:08:48 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:30947) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3OP-0003OP-M5 for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 17:08:46 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6ML2Cqo028683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2012 21:02:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6ML2CXo008543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 21:02:12 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6ML2B1i002303; Sun, 22 Jul 2012 16:02:11 -0500 Received: from dradamslap1 (/10.159.218.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 14:02:11 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <8C! 6D5530BE0@[87.69.210. 75]> <834noz1pxm.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Sun, 22 Jul 2012 14:01:58 -0700 Message-ID: <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <834noz1pxm.fsf@gnu.org> Thread-Index: Ac1oS42IG4mS/1QfSGSLHcnnqXo8TAAASW6g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Error (initialization): User has no home directory > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > What does that last message tell you? I think this is the key to > unlock your mystery. Perhaps you can tell me how so? The bash cmd prompt recognizes ~ correctly. And so does Emacs (aside from emacs -Q). And env var HOME is also defined correctly and recognized by both bash (outside and inside Emacs, aside from emacs -Q) and Emacs (aside from emacs -Q). Can you please demystify the mystery that you see? From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 17:13:57 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 21:13:57 +0000 Received: from localhost ([127.0.0.1]:58022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3TQ-0003Vd-Qw for submit@debbugs.gnu.org; Sun, 22 Jul 2012 17:13:56 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:27625) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3TP-0003VU-7Q for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 17:13:55 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6ML7LKw005231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2012 21:07:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6ML7K8Y027671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 21:07:21 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6ML7Kj3004009; Sun, 22 Jul 2012 16:07:20 -0500 Received: from dradamslap1 (/10.159.218.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 14:07:20 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <8C! 6D5530BE0@[87.69.210.75! ]> <834noz1pxm.fsf@gn u.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Sun, 22 Jul 2012 14:07:07 -0700 Message-ID: <17596044AE2445258E9917F2CBA249E7@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> Thread-Index: Ac1oS42IG4mS/1QfSGSLHcnnqXo8TAAASW6gAAAtywA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > The bash cmd prompt recognizes ~ correctly. And so does > Emacs (aside from emacs -Q). > > And env var HOME is also defined correctly and recognized by > both bash (outside > and inside Emacs, aside from emacs -Q) and Emacs (aside from > emacs -Q). Perhaps I should add that in a bash command prompt outside Emacs, echoing $HOME or ~ shows this: /cygdrive/c Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/, and (getenv "HOME") returns "c:\\". From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 17:23:43 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 21:23:43 +0000 Received: from localhost ([127.0.0.1]:58028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3cs-0003in-N8 for submit@debbugs.gnu.org; Sun, 22 Jul 2012 17:23:42 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:24616) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3cr-0003ig-5N for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 17:23:41 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6MLH99U009122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2012 21:17:10 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6MLH8Vq000292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 21:17:08 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6MLH8rV029337; Sun, 22 Jul 2012 16:17:08 -0500 Received: from dradamslap1 (/10.159.218.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 14:17:08 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <8C! 6D5530BE0@[87.69.210.75! ]> <834noz1pxm.fsf@gn u.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Sun, 22 Jul 2012 14:16:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> Thread-Index: Ac1oS42IG4mS/1QfSGSLHcnnqXo8TAAASW6gAABl/OA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > > Error (initialization): User has no home directory > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > What does that last message tell you? I think this is the key to > > unlock your mystery. > > Perhaps you can tell me how so? And in Emacs (including emacs -Q), my `user-login-name' is defined correctly. I mention this because I notice that there seem to be 2 spaces between "User" and "has" in that message. Perhaps it is trying to print a user name of only "" between the two words. BTW, if that is the case, then that error message is pretty lame. It is almost always better to quote the name that a message wants to refer to (i.e., wants to quote). That message would be clearer (if this in fact is the problem) if it said: "User `' has no home directory". Or perhaps "User name is empty". From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 17:27:56 2012 Received: (at 11939) by debbugs.gnu.org; 22 Jul 2012 21:27:56 +0000 Received: from localhost ([127.0.0.1]:58032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3gy-0003oO-8f for submit@debbugs.gnu.org; Sun, 22 Jul 2012 17:27:56 -0400 Received: from dancol.org ([96.126.100.184]:46529) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St3gw-0003oG-5x for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 17:27:54 -0400 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1St3ab-0004WL-Ep; Sun, 22 Jul 2012 14:21:21 -0700 Message-ID: <500C6EC9.1010202@dancol.org> Date: Sun, 22 Jul 2012 14:21:13 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <8C! 6D5530BE0@[87.69.210.75! ]> <834noz1pxm.fsf@gn u.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> <17596044AE2445258E9917F2CBA249E7@us.oracle.com> In-Reply-To: <17596044AE2445258E9917F2CBA249E7@us.oracle.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig70E49FB68C71F8969E99D301" X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 'Eli Zaretskii' , 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig70E49FB68C71F8969E99D301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/22/12 2:07 PM, Drew Adams wrote: >> The bash cmd prompt recognizes ~ correctly. And so does=20 >> Emacs (aside from emacs -Q). >> >> And env var HOME is also defined correctly and recognized by=20 >> both bash (outside >> and inside Emacs, aside from emacs -Q) and Emacs (aside from=20 >> emacs -Q). >=20 > Perhaps I should add that in a bash command prompt outside Emacs, echoi= ng $HOME > or ~ shows this: >=20 > /cygdrive/c >=20 > Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/, > and (getenv "HOME") returns "c:\\". If you want to use Cygwin, you should run a Cygwin Emacs. Any ad-hoc Cygwin integration in NT Emacs is necessarily incomplete. Is there any interest in now taking my patch that allows compiling Cygwin Emacs with Win32 widgets? I've been using it since I submitted that patch, and it's been working fine for me. --------------enig70E49FB68C71F8969E99D301 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlAMbsoACgkQ17c2LVA10VszUwCeN7kOxNQ/OBFsWbVS5tDUWTAp PGAAnRJRiHjOC+/sWigraHe2e4d8MiEz =LFlq -----END PGP SIGNATURE----- --------------enig70E49FB68C71F8969E99D301-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 22 21:20:55 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 01:20:55 +0000 Received: from localhost ([127.0.0.1]:58200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St7KR-0000Ua-12 for submit@debbugs.gnu.org; Sun, 22 Jul 2012 21:20:55 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:31366) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1St7KO-0000UR-Lc for 11939@debbugs.gnu.org; Sun, 22 Jul 2012 21:20:54 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6N1ECIN012231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 01:14:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6N1EBne000688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 01:14:12 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6N1EAS2024072; Sun, 22 Jul 2012 20:14:11 -0500 Received: from dradamslap1 (/10.159.218.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jul 2012 18:14:10 -0700 From: "Drew Adams" To: "'Daniel Colascione'" References: <5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <8C! 6D5530BE0@[87.69.210.75! ]> <834noz1pxm.fsf@gn u.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> <17596044AE2445258E9917F2CBA249E7@us.oracle.com> <500C6EC9.1010202! @dancol.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Sun, 22 Jul 2012 18:13:57 -0700 Message-ID: <7FA4B48E3C19497AAB3F41AD1546D070@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <500C6EC9.1010202@dancol.org> Thread-Index: Ac1oT/JGItlp2FfXRx2yZkG+Ql7PqgAH6tEA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 'Eli Zaretskii' , 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > If you want to use Cygwin, you should run a Cygwin Emacs. Any ad-hoc > Cygwin integration in NT Emacs is necessarily incomplete. I appreciate the advice, but sorry, I like to live dangerously, I guess. ;-) I have used vanilla GNU Emacs with Cygwin for decades, and I have no plans to change that. Yes, I am aware of the arguments and admonitions against it, esp. from Eli, and I do not say that such are wrong. But I am not interested, sorry. My use of Cygwin is quite limited. I do no code development, for example (other than piddling around with Emacs Lisp for fun). > Is there any > interest in now taking my patch that allows compiling Cygwin Emacs > with Win32 widgets? I've been using it since I submitted that patch, > and it's been working fine for me. Please do not sidetrack this bug thread. Bring that topic up in emacs-devel if you want to. Thx. (FWIW, I, for one, am not interested in a Cygwin Emacs.) From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 05:40:27 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 09:40:28 +0000 Received: from localhost ([127.0.0.1]:58967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StF7r-00048D-In for submit@debbugs.gnu.org; Mon, 23 Jul 2012 05:40:27 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:39109) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1StF7p-000485-2m for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 05:40:26 -0400 Received: (qmail invoked by alias); 23 Jul 2012 09:33:50 -0000 Received: from 62-47-50-184.adsl.highway.telekom.at (EHLO [62.47.50.184]) [62.47.50.184] by mail.gmx.net (mp037) with SMTP; 23 Jul 2012 11:33:50 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19Cn6tx9WpCz5tMByM5DeO28IxWHUSYFB2q7XXn85 2Jsc5ey+BEFuLR Message-ID: <500D1A93.606@gmx.at> Date: Mon, 23 Jul 2012 11:34:11 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> In-Reply-To: <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > 1. When I do C-x C-c, and respond to the yes/no question, >> > it seems I must wait a tiny bit before typing yes/no. >> > Otherwise, the first char (e.g. `y') is lost, so >> > I end up with just `es' (I see the `y' nowhere). Not a >> > big deal; just FYI. >> >> Does this happen _only_ with your code or also in the emacs >> -Q scenarios _without_ your code? What happens with a >> `y-or-no-p' defalias? > > Not sure what you mean. There is no equivalent in the emacs -Q tests you asked > me to do. There is nothing on post-command-hook etc. So the delay is due to processing `post-command-hook'? >> That's a bad idea in my opinion. Redirect as soon as possible. Why >> don't you use `after-make-frame-functions'? > > I'm not sure what you mean. I tried this: > > 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'. > > 2. Put back the guard (eq last-event-frame (window-frame (minibuffer-window))) > at the beginning of `1on1-fit-minibuffer-frame' (so it is a no-op otherwise). > > 3. Defined this and added it to `after-make-frame-functions': > > (defun 1on1-redirect-to-minibuffer (new-frame) > "..." > (when (and 1on1-fit-minibuffer-frame-flag > (active-minibuffer-window) > (save-selected-window > (select-window (minibuffer-window)) > (one-window-p nil 'selected-frame))) > (redirect-frame-focus > new-frame > (window-frame (minibuffer-window))))) > > That did not help at all. The original symptoms returned (typing yes/no did not > go to the minibuffer etc.). Here (Emacs 24.1 release because trunk crashes to frequently these days) I can do something like (progn ;; (setq minibuffer-auto-raise t) ;; (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil))))) (setq pop-up-frames t) (add-hook 'after-make-frame-functions #'(lambda (frame) (redirect-frame-focus frame frame))) (shell)) where the two forms in comments are optional. In all cases, focus is redirected appropriately after C-x C-c (although I think that when the new frame does have a minibuffer window, no redirection should be done at all and the prompt should appear in the new frame - but it seems difficult to get that right). And obviously things look better with `minibuffer-auto-raise' non-nil. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 05:40:44 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 09:40:44 +0000 Received: from localhost ([127.0.0.1]:58970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StF87-00048h-VA for submit@debbugs.gnu.org; Mon, 23 Jul 2012 05:40:44 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:40125) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1StF85-00048Z-7S for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 05:40:42 -0400 Received: (qmail invoked by alias); 23 Jul 2012 09:34:06 -0000 Received: from 62-47-50-184.adsl.highway.telekom.at (EHLO [62.47.50.184]) [62.47.50.184] by mail.gmx.net (mp069) with SMTP; 23 Jul 2012 11:34:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18eR/Q3RTYe13kzlnxmYLUoBMejRi1LmajLlY/ZAQ DsvCp8ORfLs6n4 Message-ID: <500D1AA4.1080301@gmx.at> Date: Mon, 23 Jul 2012 11:34:28 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> <500A8C2D.8040005@gmx.at> <2F2A096477C74296B873241B8AD78AF5@us.oracle.com> <500BBE9B.3080006@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> >> Usually, each frame must have a minibuffer window. How >> >> else should `read-minibuffer' work? >> > >> > It can read from the minibuffer in a standalone minibuffer frame? >> >> Is this a question or an answer? > > An answer, followed by "Is that not correct?", since I'm not sure we're talking > about the same thing. I would expect that it is obvious to you too that Emacs > can read from a minibuffer in a standalone frame. And it's not clear to me why > that possibility is not an answer to your question. But then you didn't answer my initial question. I didn't ask about standalone frames only, I asked about "each" frame. >> > That's what I was guessing, that a frame's `minibuffer' >> > parameter might be non-nil but it somehow has a minibuffer >> > _window_. Seems odd, but I guess these things are at two >> > different levels. I am used to the Lisp & frame level - I >> > know almost nothing about the C & window level. >> >> Emacs must be able to work internally even if you make all your frames >> minibuffer-less. > > I never claimed otherwise. But I don't see the relation here. And I do not > make all my frames minibuffer-less. So I guess I'm not following you very well. When you exit emacs deleting its last frame, there might be an internal state where only a minibuffer less frame remains. And that may cause a(n unwanted) crash IIUC. >> >> `mouse-leave-buffer-hook' and in a `pre-' or >> >> `post-command-hook' check whether that something got executed. >> >> Then you can be sure that somewhere in between a >> >> `handle-switch-frame' interfered. >> > >> > Sorry, I don't follow you (and I haven't found where you >> > suggested something similar earlier). If you can be more >> > specific I'll be glad to try whatever you ask. >> >> When you want to check of `handle-switch-frame' executions you cannot >> trace otherwise and you do not run emacs in the debugger, the most >> simple way to trace these is to put some function on >> `mouse-leave-buffer-hook', and inspect the output of that >> function later on. > > OK, but I still do not know what you would like me to do/test. Can you give me > a recipe to test? No. All I did was to reply to an issue you raised earlier - that of `handle-switch-frame' possibly interfering with "normal" execution of commands. And I said that IMHO the most simple way to notice whether `handle-switch-frame' got executed in between is to put a function on `mouse-leave-buffer-hook'. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 12:10:42 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 16:10:42 +0000 Received: from localhost ([127.0.0.1]:32986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLDW-0000PQ-FJ for submit@debbugs.gnu.org; Mon, 23 Jul 2012 12:10:42 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:34007) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLDT-0000P9-2V for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 12:10:40 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M7M00900EY2P900@a-mtaout21.012.net.il> for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 19:03:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7M009EEFALFMA0@a-mtaout21.012.net.il>; Mon, 23 Jul 2012 19:03:58 +0300 (IDT) Date: Mon, 23 Jul 2012 19:04:02 +0300 From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' In-reply-to: <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83r4s2zcp9.fsf@gnu.org> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <834noz1pxm.fsf@gnu.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Sun, 22 Jul 2012 14:01:58 -0700 > > > > Error (initialization): User has no home directory > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > What does that last message tell you? I think this is the key to > > unlock your mystery. > > Perhaps you can tell me how so? [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 3.3 HDRS_LCASE_1K Odd capitalization of message headers + long header X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Sun, 22 Jul 2012 14:01:58 -0700 > > > > Error (initialization): User has no home directory > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > What does that last message tell you? I think this is the key to > > unlock your mystery. > > Perhaps you can tell me how so? How could I, without knowing all that you told about your environment since my message? Even now, with all that additional info in hand, I can only guess (see below). By contrast, you should be well equipped to find out what is going on, because this message comes from startup.el (says 'grep'). > The bash cmd prompt recognizes ~ correctly. And so does Emacs (aside from emacs > -Q). > > And env var HOME is also defined correctly and recognized by both bash (outside > and inside Emacs, aside from emacs -Q) and Emacs (aside from emacs -Q). > > Can you please demystify the mystery that you see? Given this: > Perhaps I should add that in a bash command prompt outside Emacs, echoing $HOME > or ~ shows this: > > /cygdrive/c > > Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/, > and (getenv "HOME") returns "c:\\". I'm guessing that you invoked GDB from the Cygwin Bash's prompt, which has the effect of setting HOME to /cygdrive/c, which the native Windows Emacs doesn't grok. The code in startup.el that looks for ~/.emacs tests the value of HOME by calling file-directory-p, which fails for /cygdrive/c, the result being the error message. I'm guessing that invoking GDB from the Windows shell cmd.exe should fix this. In any case, since the purpose of this discussion is not to "fix" your environment, I suggest that instead of invoking Emacs from GDB, you invoke it normally (presumably from a desktop shortcut); then immediately attach GDB to it, like you do when Emacs crashes; then type "continue" at GDB's prompt to let Emacs run; and finally do whatever Martin asked you to for which he wanted GDB to kick in. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 12:18:41 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 16:18:41 +0000 Received: from localhost ([127.0.0.1]:33004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLLE-0000my-FQ for submit@debbugs.gnu.org; Mon, 23 Jul 2012 12:18:41 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:36235) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLLC-0000mm-ES for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 12:18:39 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NGC2jV009106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 16:12:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6NGC1TD009884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 16:12:01 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6NGC1q7014404; Mon, 23 Jul 2012 11:12:01 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 09:12:01 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <500D1A93.606@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 23 Jul 2012 09:12:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <500D1A93.606@gmx.at> Thread-Index: Ac1otkaDlNjcXDsxSGmPyy4rwlV3uwAMwUPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> > 1. When I do C-x C-c, and respond to the yes/no question, > >> > it seems I must wait a tiny bit before typing yes/no. > >> > Otherwise, the first char (e.g. `y') is lost, so > >> > I end up with just `es' (I see the `y' nowhere). Not a > >> > big deal; just FYI. > >> > >> Does this happen _only_ with your code or also in the emacs > >> -Q scenarios _without_ your code? What happens with a > >> `y-or-no-p' defalias? > > > > Not sure what you mean. There is no equivalent in the > > emacs -Q tests you asked me to do. There is nothing on > > post-command-hook etc. > > So the delay is due to processing `post-command-hook'? Is that a question or an answer? ;-) If it is a question, I don't have the answer. I can only report the symptom: the first char is seemingly lost (does not show up in the minibuffer, at least, and I have not seen it anywhere else). As I said, this is not a big deal. I mention it FYI. > >> That's a bad idea in my opinion. Redirect as soon as > >> possible. Why don't you use `after-make-frame-functions'? > > > > I'm not sure what you mean. I tried this: > > > > 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'. > > > > 2. Put back the guard (eq last-event-frame (window-frame > > (minibuffer-window))) at the beginning of `1on1-fit-minibuffer-frame' > > (so it is a no-op otherwise). > > > > 3. Defined this and added it to `after-make-frame-functions': > > > > (defun 1on1-redirect-to-minibuffer (new-frame) > > "..." > > (when (and 1on1-fit-minibuffer-frame-flag > > (active-minibuffer-window) > > (save-selected-window > > (select-window (minibuffer-window)) > > (one-window-p nil 'selected-frame))) > > (redirect-frame-focus > > new-frame > > (window-frame (minibuffer-window))))) > > > > That did not help at all. The original symptoms returned > > (typing yes/no did not go to the minibuffer etc.). > > Here (Emacs 24.1 release because trunk crashes to frequently > these days) I can do something like > > (progn > ;; (setq minibuffer-auto-raise t) > ;; (setq pop-up-frame-function > ;; (lambda () (make-frame '((minibuffer . nil))))) > (setq pop-up-frames t) > (add-hook 'after-make-frame-functions > #'(lambda (frame) > (redirect-frame-focus frame frame))) > (shell)) > > where the two forms in comments are optional. In all cases, focus is > redirected appropriately after C-x C-c (although I think that when the > new frame does have a minibuffer window, no redirection should be done > at all and the prompt should appear in the new frame - but it seems > difficult to get that right). And obviously things look better with > `minibuffer-auto-raise' non-nil. Yes, if I try that with emacs -Q then it does what you say (with Emacs 24.1 and later). And uncommenting those two lines also behaves as I think you intend. In both cases, the question is posed, and the response is accepted, in the minibuffer of frame *shell* (i.e., not the minibuffer of frame *Process List* in the case where it has one). But if *Process List* has no minibuffer (uncommented test case), and it is selected (e.g., later, manually, after replying "no" once) when you hit `C-x C-c' (i.e., the second `C-x C-c'), then frame *shell* is raised and receives the input, even though there is nothing on that frame that the user needs to see (apart from the question/answer). It is better, IMO, for the question/response to be in frame *Process List*, as we discussed earlier. (This is all for the case where there is no standalone minibuffer frame.) The reason I provided the description I did was that I thought we were talking about my setup with a standalone minibuffer frame. See my previous description (quoted above) for what happens in that context. For that context, your suggestion of using `after-make-frame-functions', as I understood it, did not help. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 12:18:45 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 16:18:45 +0000 Received: from localhost ([127.0.0.1]:33006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLLI-0000nK-OS for submit@debbugs.gnu.org; Mon, 23 Jul 2012 12:18:45 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:36248) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLLD-0000mx-Uc for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 12:18:41 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NGC4Qn009151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 16:12:04 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6NGC311020104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 16:12:04 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6NGC36g031895; Mon, 23 Jul 2012 11:12:03 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 09:12:03 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500173A5.3040608@gmx.at><1986D90E22154321A44B6E0110CA4F5A@us.oracle.com><50019C2F.8060103@gmx.at><6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com><5002BEC6.3040106@gmx.at><893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> <500A8C2D.8040005@gmx.at> <2F2A096477C74296B873241B8AD78AF5@us.oracle.com> <500BBE9B.3080006@gmx.at> <500D1AA4.1 080301@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Mon, 23 Jul 2012 09:12:02 -0700 Message-ID: <6E0F640C9DEF44CBA1A9D960A2E650EF@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <500D1AA4.1080301@gmx.at> Thread-Index: Ac1otk90RuC+ugjwTxyOf9y+NQFkwwAMcpIQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> >> Usually, each frame must have a minibuffer window. How > >> >> else should `read-minibuffer' work? > >> > > >> > It can read from the minibuffer in a standalone minibuffer frame? > >> > >> Is this a question or an answer? > > > > An answer, followed by "Is that not correct?", since I'm > > not sure we're talking about the same thing. I would expect that > > it is obvious to you too that Emacs can read from a minibuffer in a > > standalone frame. And it's not clear to me why > > that possibility is not an answer to your question. > > But then you didn't answer my initial question. I didn't ask about > standalone frames only, I asked about "each" frame. I was saying only that using a standalone minibuffer frame is a case where it is not true that each frame has a minibuffer. And yet it is a case works. That's all I was pointing out. Whether a frame with nil `minibuffer' parameter might actually have a minibuffer _window_ is not something I know about, as I said. I'm sure I'm not saying anything here that you are not aware of, so if this part is only a word game for you then let's move on, please. > >> > That's what I was guessing, that a frame's `minibuffer' > >> > parameter might be non-nil but it somehow has a minibuffer > >> > _window_. Seems odd, but I guess these things are at two > >> > different levels. I am used to the Lisp & frame level - I > >> > know almost nothing about the C & window level. > >> > >> Emacs must be able to work internally even if you make > >> all your frames minibuffer-less. > > > > I never claimed otherwise. But I don't see the relation > > here. And I do not make all my frames minibuffer-less. > > So I guess I'm not following you very well. > > When you exit emacs deleting its last frame, there might be an internal > state where only a minibuffer less frame remains. And that may cause > a(n unwanted) crash IIUC. OK. Do you see me saying anything that contradicts that? I do not understand what the point is here - what it is that we are discussing. I am not disputing anything I hear you to be saying. > >> >> `mouse-leave-buffer-hook' and in a `pre-' or > >> >> `post-command-hook' check whether that something got executed. > >> >> Then you can be sure that somewhere in between a > >> >> `handle-switch-frame' interfered. > >> > > >> > Sorry, I don't follow you (and I haven't found where you > >> > suggested something similar earlier). If you can be more > >> > specific I'll be glad to try whatever you ask. > >> > >> When you want to check of `handle-switch-frame' executions you cannot > >> trace otherwise and you do not run emacs in the debugger, the most > >> simple way to trace these is to put some function on > >> `mouse-leave-buffer-hook', and inspect the output of that > >> function later on. > > > > OK, but I still do not know what you would like me to > > do/test. Can you give me a recipe to test? > > No. All I did was to reply to an issue you raised earlier - that of > `handle-switch-frame' possibly interfering with "normal" execution of > commands. And I said that IMHO the most simple way to notice whether > `handle-switch-frame' got executed in between is to put a function on > `mouse-leave-buffer-hook'. I see. But as I said earlier, I already determined that `h-s-f' was in fact the current (i.e., last) command when `1on1-fit-minibuffer-frame' kicked in from `post-command-hook'. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 12:34:42 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 16:34:42 +0000 Received: from localhost ([127.0.0.1]:33051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLaj-0001We-W3 for submit@debbugs.gnu.org; Mon, 23 Jul 2012 12:34:42 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:34039) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StLah-0001WT-G1 for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 12:34:41 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NGS3Vu026257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 16:28:04 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6NGS27p018504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 16:28:02 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6NGS1FD023254; Mon, 23 Jul 2012 11:28:01 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 09:28:01 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83! 4noz1pxm.fsf@gnu.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> <83r4s2zcp9.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 23 Jul 2012 09:28:00 -0700 Message-ID: <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83r4s2zcp9.fsf@gnu.org> Thread-Index: Ac1o7MnAQR+wNINiQhCTyKN49Vzq9AAAYxsw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > I suggest that instead of invoking Emacs from GDB, you > invoke it normally (presumably from a desktop shortcut); then > immediately attach GDB to it, like you do when Emacs crashes; then > type "continue" at GDB's prompt to let Emacs run; and finally do > whatever Martin asked you to for which he wanted GDB to kick in. That I would like to try, but I don't know the recipe. What I have done in the past I did after getting the Emacs popup dialog window about a fatal crash (what you have called the "Emacs abort dialog"), following instructions that you gave me in the past. For the current crash, which presents no such dialog box, I tried following Martin's instructions for invoking gdb from within Emacs. You then instructed me not to do that but to instead invoke gdb outside Emacs. That's when I tried doing invoking it from a bash shell etc. If you give me the recipe for invoking gdb from within Emacs the right way then I will be glad to try it. In sum, this is not clear to me: "immediately attach GDB to it, like you do when Emacs crashes". Thx. P.S. These are the instructions from you that I follow when I do get the "Emacs abort dialog" box: > when you see the Emacs abort dialog do this in order: > > . Find out the PID of the Emacs process > . Open a shell window and chdir to the directory where you have GDB > and .gdbinit > . Type "./gdb -p PID" and hit RET > . When you see the "(gdb)" prompt, type "c RET" > . Click YES on the Emacs abort dialog > > You should then see GDB announcing the crash, something like this: > > Program received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 3684.0x1210] > 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll > > and then the GDB prompt "(gdb)". Now you are ready to debug the > crash. At that point, I type `bt'. And perhaps `frame N' for some N followed by `p XYZ' for something XYZ such as `selected_window'. Then I type `xtype'. If you can tell me what to do differently here, where there is no "Emacs abort dialog" box, I will follow the recipe and let you know what I see. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 13:39:38 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 17:39:38 +0000 Received: from localhost ([127.0.0.1]:33238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StMba-0004P7-7L for submit@debbugs.gnu.org; Mon, 23 Jul 2012 13:39:38 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:43302) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StMbY-0004Oz-0I for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 13:39:37 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M7M00F00JABTJ00@a-mtaout23.012.net.il> for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 20:32:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7M00FZOJEZMM80@a-mtaout23.012.net.il>; Mon, 23 Jul 2012 20:32:59 +0300 (IDT) Date: Mon, 23 Jul 2012 20:33:04 +0300 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83mx2qz8kv.fsf@gnu.org> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <834n@[87.69.210.75]> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: <11939@debbugs.gnu.org> > Date: Sun, 22 Jul 2012 14:16:55 -0700 > > > > > Error (initialization): User has no home directory > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > What does that last message tell you? I think this is the key to > > > unlock your mystery. > > > > Perhaps you can tell me how so? > > And in Emacs (including emacs -Q), my `user-login-name' is defined correctly. > > I mention this because I notice that there seem to be 2 spaces between "User" > and "has" in that message. Perhaps it is trying to print a user name of only "" > between the two words. > > BTW, if that is the case, then that error message is pretty lame. It is almost > always better to quote the name that a message wants to refer to (i.e., wants to > quote). > > That message would be clearer (if this in fact is the problem) if it said: > > "User `' has no home directory". Or perhaps "User name is empty". There's no problem with your user name. What you see above is startup.el shooting itself in the foot, because it actually _sets_ the variable that holds the user name to an empty string (for boring reasons related to the implementation; see the code around the error message for the details, if you are interested). I've committed a fix to display the user name correctly, even if that variable is set to an empty string. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 14:04:54 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 18:04:54 +0000 Received: from localhost ([127.0.0.1]:33296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StN01-00059E-3A for submit@debbugs.gnu.org; Mon, 23 Jul 2012 14:04:54 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:50444) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StMzx-000593-Fj for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 14:04:51 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M7M00A00KGNBV00@a-mtaout21.012.net.il> for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 20:58:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7M00AQPKL03060@a-mtaout21.012.net.il>; Mon, 23 Jul 2012 20:58:13 +0300 (IDT) Date: Mon, 23 Jul 2012 20:58:18 +0300 From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' In-reply-to: <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83fw8iz7et.fsf@gnu.org> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <8AEB9C65F733427397188CD0D3C799E8@us.oracle.com> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Mon, 23 Jul 2012 09:28:00 -0700 > > > I suggest that instead of invoking Emacs from GDB, you > > invoke it normally (presumably from a desktop shortcut); then > > immediately attach GDB to it, like you do when Emacs crashes; then > > type "continue" at GDB's prompt to let Emacs run; and finally do > > whatever Martin asked you to for which he wanted GDB to kick in. > > That I would like to try, but I don't know the recipe. > > What I have done in the past I did after getting the Emacs popup dialog window > about a fatal crash (what you have called the "Emacs abort dialog"), following > instructions that you gave me in the past. > > For the current crash, which presents no such dialog box, I tried following > Martin's instructions for invoking gdb from within Emacs. [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 3.3 HDRS_LCASE_1K Odd capitalization of message headers + long header X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Mon, 23 Jul 2012 09:28:00 -0700 > > > I suggest that instead of invoking Emacs from GDB, you > > invoke it normally (presumably from a desktop shortcut); then > > immediately attach GDB to it, like you do when Emacs crashes; then > > type "continue" at GDB's prompt to let Emacs run; and finally do > > whatever Martin asked you to for which he wanted GDB to kick in. > > That I would like to try, but I don't know the recipe. > > What I have done in the past I did after getting the Emacs popup dialog window > about a fatal crash (what you have called the "Emacs abort dialog"), following > instructions that you gave me in the past. > > For the current crash, which presents no such dialog box, I tried following > Martin's instructions for invoking gdb from within Emacs. Don't wait for the crash. Instead, attach GDB to Emacs right after starting Emacs, with "gdb -p PID". When GDB attaches to a program, the program stops, so to let Emacs run normally thereafter, you will need to type "continue" at GDB prompt. After that, operate Emacs normally, and do whatever is needed to reproduce the problem. > If you give me the recipe for invoking gdb from within Emacs the right way then > I will be glad to try it. In sum, this is not clear to me: "immediately attach > GDB to it, like you do when Emacs crashes". . invoke Emacs as you normally do . find out its PID . from the shell prompt, type "gdb -p PID" from the directory where you have .gdbinit . wait until GDB starts and displays its prompt, then type "continue" at that prompt. . go to the Emacs window and reproduce the problem. . when the problem (crash) happens, the debugger will kick in and display its prompt again, so you can type GDB command there. > P.S. These are the instructions from you that I follow when I do get the "Emacs > abort dialog" box: > > > when you see the Emacs abort dialog do this in order: > > > > . Find out the PID of the Emacs process > > . Open a shell window and chdir to the directory where you have GDB > > and .gdbinit > > . Type "./gdb -p PID" and hit RET > > . When you see the "(gdb)" prompt, type "c RET" > > . Click YES on the Emacs abort dialog Do the same, just don't wait for the abort dialog. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 14:07:19 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 18:07:20 +0000 Received: from localhost ([127.0.0.1]:33310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StN2N-0005E5-5s for submit@debbugs.gnu.org; Mon, 23 Jul 2012 14:07:19 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:47104) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StN2K-0005Du-C6 for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 14:07:17 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NI0cHJ015542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 18:00:39 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6NI0cFA025945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 18:00:38 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6NI0c0o025460; Mon, 23 Jul 2012 13:00:38 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 11:00:38 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83! 4n@[87.69.210.75]> <8 3mx2qz8kv.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Mon, 23 Jul 2012 11:00:37 -0700 Message-ID: <1F6E5D1D971045DA9194FF6F356B2A9A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83mx2qz8kv.fsf@gnu.org> Thread-Index: Ac1o+TZBSenGT5l1QReIJ593DKrsWgAA8jqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > That message would be clearer (if this in fact is the > > problem) if it said: > > > > "User `' has no home directory". Or perhaps "User name is empty". > > There's no problem with your user name. What you see above is > startup.el shooting itself in the foot, because it actually _sets_ the > variable that holds the user name to an empty string (for boring > reasons related to the implementation; see the code around the error > message for the details, if you are interested). > > I've committed a fix to display the user name correctly, even if that > variable is set to an empty string. Good. Thx. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 14:36:25 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 18:36:25 +0000 Received: from localhost ([127.0.0.1]:33408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StNUX-0006xo-8l for submit@debbugs.gnu.org; Mon, 23 Jul 2012 14:36:25 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:16981) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StNUV-0006xg-7G for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 14:36:24 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6NITjr2012116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2012 18:29:45 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6NITi4W001571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 18:29:44 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6NITgSE015369; Mon, 23 Jul 2012 13:29:42 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Jul 2012 11:29:42 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <8A! EB9C65F733427397188CD 0D3C799E8@us.oracle.com> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Mon, 23 Jul 2012 11:29:40 -0700 Message-ID: <60948DD3935D452F85F95174474D06E9@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83fw8iz7et.fsf@gnu.org> Thread-Index: Ac1o/LwS9yucso4lRsyjKmBQr24hlQAAPJQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > . invoke Emacs as you normally do > . find out its PID > . from the shell prompt, type "gdb -p PID" from the directory where > you have .gdbinit > . wait until GDB starts and displays its prompt, then type > "continue" at that prompt. > . go to the Emacs window and reproduce the problem. > . when the problem (crash) happens, the debugger will kick in and > display its prompt again, so you can type GDB command there. Got it; thanks. Unfortunately, I cannot get much in the way of results that way, for this test at least. After `(gdb) continue', I followed the recipe I followed before to produce the crash. When it would have crashed before (i.e., without gdb) it now just seemed to hang. I can, however, see this in the command-prompt window (outside Emacs): $ gdb -p 4252 GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin". Attaching to process 4252 [Switching to thread 4252.0xc80] /cygdrive/c/drews-lisp-20/bin/.gdbinit:32: Error in sourced command file: No symbol "main" in current context. (gdb) continue Continuing. warning: frame 049AE200 (*shell*) obscured warning: frame 049AE200 (*shell*) reexposed by WM_PAINT warning: obscured frame 049AE200 (*shell*) found to be visible Program received signal SIGSEGV, Segmentation fault. [Switching to thread 4252.0xfb0] 0x01252ab3 in ?? () (gdb) bt #0 0x01252ab3 in ?? () (gdb) quit The program is running. Quit anyway (and detach it)? (y or y) Detaching from program: , Pid 4252 At that point, I did get the MS Windows "encountered a problem and needs to close" dialog box, and clicked button "Send Error Report", and Emacs exited. Dunno whether that helps at all. As the problem is reproducible, I can try again if you give me more instructions to try. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 23 15:37:32 2012 Received: (at 11939) by debbugs.gnu.org; 23 Jul 2012 19:37:32 +0000 Received: from localhost ([127.0.0.1]:33592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StORf-0000Nm-RC for submit@debbugs.gnu.org; Mon, 23 Jul 2012 15:37:32 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:40934) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1StORd-0000Nc-4s for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 15:37:30 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M7M00H00OF8XQ00@a-mtaout20.012.net.il> for 11939@debbugs.gnu.org; Mon, 23 Jul 2012 22:30:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7M00HY2OUXS530@a-mtaout20.012.net.il>; Mon, 23 Jul 2012 22:30:33 +0300 (IDT) Date: Mon, 23 Jul 2012 22:30:38 +0300 From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' In-reply-to: <60948DD3935D452F85F95174474D06E9@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <838veaz34x.fsf@gnu.org> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Mon, 23 Jul 2012 11:29:40 -0700 > > Unfortunately, I cannot get much in the way of results that way, for this test > at least. > > After `(gdb) continue', I followed the recipe I followed before to produce the > crash. When it would have crashed before (i.e., without gdb) it now just seemed > to hang. [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 3.3 HDRS_LCASE_1K Odd capitalization of message headers + long header X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11939@debbugs.gnu.org> > Date: Mon, 23 Jul 2012 11:29:40 -0700 > > Unfortunately, I cannot get much in the way of results that way, for this test > at least. > > After `(gdb) continue', I followed the recipe I followed before to produce the > crash. When it would have crashed before (i.e., without gdb) it now just seemed > to hang. That's not what I see: > (gdb) continue > Continuing. > warning: frame 049AE200 (*shell*) obscured > > warning: frame 049AE200 (*shell*) reexposed by WM_PAINT > > warning: obscured frame 049AE200 (*shell*) found to be visible > > > Program received signal SIGSEGV, Segmentation fault. <<<<<<<<<<< This is definitely a crash. > (gdb) quit > The program is running. Quit anyway (and detach it)? (y or y) > Detaching from program: , Pid 4252 > > At that point, I did get the MS Windows "encountered a problem and needs to > close" dialog box, and clicked button "Send Error Report", and Emacs exited. Well, don't say "quit". Instead, I hope that Martin will be able to give you instructions what to look for once you get SIGSEGV. Martin, the floor is yours ;-) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 24 08:53:04 2012 Received: (at 11939) by debbugs.gnu.org; 24 Jul 2012 12:53:04 +0000 Received: from localhost ([127.0.0.1]:35201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Stebo-0000yo-Hs for submit@debbugs.gnu.org; Tue, 24 Jul 2012 08:53:04 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:58789) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Stebm-0000yS-94 for 11939@debbugs.gnu.org; Tue, 24 Jul 2012 08:53:03 -0400 Received: (qmail invoked by alias); 24 Jul 2012 12:46:21 -0000 Received: from 62-47-32-76.adsl.highway.telekom.at (EHLO [62.47.32.76]) [62.47.32.76] by mail.gmx.net (mp070) with SMTP; 24 Jul 2012 14:46:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/wOMEkYLXwPGRQTRiPW1AgZWHGkzoyk9H5qM2tCz 62R5hlaI5bKDBe Message-ID: <500E993F.7020502@gmx.at> Date: Tue, 24 Jul 2012 14:46:55 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <500D1A93.606@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> (progn >> ;; (setq minibuffer-auto-raise t) >> ;; (setq pop-up-frame-function >> ;; (lambda () (make-frame '((minibuffer . nil))))) >> (setq pop-up-frames t) >> (add-hook 'after-make-frame-functions >> #'(lambda (frame) >> (redirect-frame-focus frame frame))) >> (shell)) >> >> where the two forms in comments are optional. In all cases, focus is >> redirected appropriately after C-x C-c (although I think that when the >> new frame does have a minibuffer window, no redirection should be done >> at all and the prompt should appear in the new frame - but it seems >> difficult to get that right). And obviously things look better with >> `minibuffer-auto-raise' non-nil. > > Yes, if I try that with emacs -Q then it does what you say (with Emacs 24.1 and > later). > > And uncommenting those two lines also behaves as I think you intend. In both > cases, the question is posed, and the response is accepted, in the minibuffer of > frame *shell* (i.e., not the minibuffer of frame *Process List* in the case > where it has one). > > But if *Process List* has no minibuffer (uncommented test case), and it is > selected (e.g., later, manually, after replying "no" once) when you hit `C-x > C-c' (i.e., the second `C-x C-c'), then frame *shell* is raised and receives the > input, even though there is nothing on that frame that the user needs to see > (apart from the question/answer). This is probably the case where a window on another frame is reused before asking the `yes-or-no-p' question. This should be easier to handle because the window manager supposedly won't focus that frame. In any case I think a `yes-or-no-p' question should terminate by killing the *Process List* buffer to avoid such confusion. > It is better, IMO, for the question/response to be in frame *Process List*, as > we discussed earlier. (This is all for the case where there is no standalone > minibuffer frame.) I think so too. > The reason I provided the description I did was that I thought we were talking > about my setup with a standalone minibuffer frame. See my previous description > (quoted above) for what happens in that context. For that context, your > suggestion of using `after-make-frame-functions', as I understood it, did not > help. What precisely is the problem with it? martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 24 08:53:20 2012 Received: (at 11939) by debbugs.gnu.org; 24 Jul 2012 12:53:20 +0000 Received: from localhost ([127.0.0.1]:35205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Stec3-0000zF-Sf for submit@debbugs.gnu.org; Tue, 24 Jul 2012 08:53:20 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:46943) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Stec1-0000z8-LG for 11939@debbugs.gnu.org; Tue, 24 Jul 2012 08:53:18 -0400 Received: (qmail invoked by alias); 24 Jul 2012 12:46:37 -0000 Received: from 62-47-32-76.adsl.highway.telekom.at (EHLO [62.47.32.76]) [62.47.32.76] by mail.gmx.net (mp038) with SMTP; 24 Jul 2012 14:46:37 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/M3BlrsIDMRGpMnVQpdh9IQmQ9xsllo9wG8PGzNK dzZZD9GlZgTMIX Message-ID: <500E994D.4060006@gmx.at> Date: Tue, 24 Jul 2012 14:47:09 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> <838veaz34x.fsf@gnu.org> In-Reply-To: <838veaz34x.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Martin, the floor is yours ;-) Thanks Eli, but I'm a stranger here myself. Drew, what does bt full say? martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 25 11:09:20 2012 Received: (at 11939) by debbugs.gnu.org; 25 Jul 2012 15:09:20 +0000 Received: from localhost ([127.0.0.1]:39181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su3DD-0006Yj-LT for submit@debbugs.gnu.org; Wed, 25 Jul 2012 11:09:19 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:51582) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su3DB-0006Yb-Ca for 11939@debbugs.gnu.org; Wed, 25 Jul 2012 11:09:18 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PF2UIZ026042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2012 15:02:30 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6PF2TcJ004001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 15:02:29 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6PF2Stl008693; Wed, 25 Jul 2012 10:02:28 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jul 2012 08:02:28 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <500D1A93.606@gmx.at> <500E993F.7020502@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Wed, 25 Jul 2012 08:02:27 -0700 Message-ID: <23244A80D9924C4D967C3364D8A6F616@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500E993F.7020502@gmx.at> Thread-Index: Ac1pmlVDjvylihZ1Q0+hwXE4zgRpkQA2bxzg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > The reason I provided the description I did was that I > > thought we were talking about my setup with a standalone > > minibuffer frame. See my previous description > > (quoted above) for what happens in that context. For that > > context, your suggestion of using `after-make-frame-functions', > > as I understood it, did not help. > > What precisely is the problem with it? (As I said, it was quoted above.) Here again is what I reported (2012-07-22) after that test: > > > Anyway, it seems we are very close, for my needs. I suppose I > > > can put that redirection on `post-command-hook' (instead of in > > > `1on1-fit-minibuffer-frame', which some oneonone.el users will > > > not use), and things should generally work. > > > > That's a bad idea in my opinion. Redirect as soon as possible. Why > > don't you use `after-make-frame-functions'? > > I'm not sure what you mean. I tried this: > > 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'. > > 2. Put back the guard > (eq last-event-frame (window-frame (minibuffer-window))) > at the beginning of `1on1-fit-minibuffer-frame' (so it is a > no-op otherwise). > > 3. Defined this and added it to `after-make-frame-functions': > > (defun 1on1-redirect-to-minibuffer (new-frame) > "..." > (when (and 1on1-fit-minibuffer-frame-flag > (active-minibuffer-window) > (save-selected-window > (select-window (minibuffer-window)) > (one-window-p nil 'selected-frame))) > (redirect-frame-focus > new-frame > (window-frame (minibuffer-window))))) > > That did not help at all. The original symptoms returned > (typing yes/no did not go to the minibuffer etc.). IOW, that was the same as doing nothing at all: the minibuffer frame did not receive the yes/no user input. So far, the most successful "fix" for my setup seems to be a combination of (a) your code (`with-temp-buffer-window.el') plus (b) either (i) calling `redirect-frame-focus' or `select-frame-set-input-focus' at the end of `1on1-fit-minibuffer-frame' or (ii) using the guard (eq last-event-frame (window-frame (minibuffer-window))) at the beginning of that function. As I said, some users of oneonone.el won't also use fit-frame.el, so for them putting a fix into `1on1-fit-minibuffer-frame' won't help. I speculated to you about putting the focus redirection instead on `post-command-hook', but you said that was a bad idea and proposed to "use `after-make-frame-functions'". I am not sure what you meant by that, but the test above, which uses that hook, did not work, in any case: the input was not redirected to the minibuffer frame. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 25 11:49:41 2012 Received: (at 11939) by debbugs.gnu.org; 25 Jul 2012 15:49:41 +0000 Received: from localhost ([127.0.0.1]:39244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su3qG-0007SW-OX for submit@debbugs.gnu.org; Wed, 25 Jul 2012 11:49:41 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:39162) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su3qD-0007SM-MM for 11939@debbugs.gnu.org; Wed, 25 Jul 2012 11:49:38 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PFgok0009454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2012 15:42:51 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6PFgn1k007312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 15:42:49 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6PFgmMq007475; Wed, 25 Jul 2012 10:42:48 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jul 2012 08:42:48 -0700 From: "Drew Adams" To: "'martin rudalics'" , "'Eli Zaretskii'" References: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> <838veaz34x.fsf@gnu.org> <500E9! 94D.4060006@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Wed, 25 Jul 2012 08:42:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500E994D.4060006@gmx.at> Thread-Index: Ac1pml7NYfBwzc4OTHOmdXXvxkKi/QA3Yq/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Martin, the floor is yours ;-) > Thanks Eli, but I'm a stranger here myself. > Drew, what does bt full say? It says this: $ gdb -p 2964 GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin". Attaching to process 2964 [Switching to thread 2964.0x1220] /cygdrive/c/drews-lisp-20/bin/.gdbinit:32: Error in sourced command file: No symbol "main" in current context. (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to thread 2964.0x15c0] 0x01102012 in ?? () (gdb) bt full #0 0x01102012 in ?? () No symbol table info available. (gdb) IOW, `bt full' just adds the statement "No symbol table info available." to what `bt' shows. Reminder: This is without your `with-temp-buffer-window.el' loaded, and with `redirect-frame-focus' added to the end of `1on1-fit-minibuffer-frame'. If I also load your `with-temp-buffer-window.el' then I do not get the crash. But in that case (i.e., with your code) the *Process List* buffer is replaced in its frame by *shell*, so I then have two frames showing *shell* at that point. This is an example of the problem of the frame (for *Process Control*) not really being special-display as it should be. Again, this is with Emacs 24.1, and the scenario is the following, after evaluating my modified `1on1-fit-minibuffer-frame' and optionally loading your code: M-x shell C-x C-c Reply "no" to the question about active processes - IOW, do not quit Emacs. C-x k At that point, if your code was not loaded, the *Process List* frame has its title bar selected/highlighted, but the buffer to be killed, by default, is *shell*. If your code was loaded then buffer *Process Control* has been replaced in its (supposedly special-display) frame by buffer *shell* (so there are two frames for *shell* now). If your code was loaded, then I can kill buffer *shell* normally, after confirming to kill its processes - the two *shell* frames disappear (as they should, with my setup). And C-x C-b shows that there is no buffer *Process List*. If your code was not loaded, then I can still kill *shell* normally, but the *Process List* frame remains (frame *shell* disappears, as it should). If I then try C-x k, and try to type a char or move the cursor in the minibuffer, then I get the crash. If, however, I do something that explicitly selects some frame, then I can proceed normally to kill any buffer using C-x k - including buffer *Process List* (which is still hanging around). An example of explicitly selecting some frame would be clicking the mouse on a frame title bar. HTH/Thx - Drew From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 25 12:24:34 2012 Received: (at 11939) by debbugs.gnu.org; 25 Jul 2012 16:24:34 +0000 Received: from localhost ([127.0.0.1]:39302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su4O2-0008Ej-DF for submit@debbugs.gnu.org; Wed, 25 Jul 2012 12:24:34 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:63934) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su4Nz-0008Eb-Qi for 11939@debbugs.gnu.org; Wed, 25 Jul 2012 12:24:32 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M7Q00800527SU00@a-mtaout22.012.net.il> for 11939@debbugs.gnu.org; Wed, 25 Jul 2012 19:17:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M7Q008ZD58IOQ20@a-mtaout22.012.net.il>; Wed, 25 Jul 2012 19:17:06 +0300 (IDT) Date: Wed, 25 Jul 2012 19:17:09 +0300 From: Eli Zaretskii Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83629blssa.fsf@gnu.org> References: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> <838veaz34x.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: <11939@debbugs.gnu.org> > Date: Wed, 25 Jul 2012 08:42:47 -0700 > > > > Martin, the floor is yours ;-) > > Thanks Eli, but I'm a stranger here myself. > > Drew, what does bt full say? > > It says this: > > $ gdb -p 2964 > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-cygwin". > Attaching to process 2964 > > [Switching to thread 2964.0x1220] > /cygdrive/c/drews-lisp-20/bin/.gdbinit:32: Error in sourced command file: > No symbol "main" in current context. > (gdb) continue > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to thread 2964.0x15c0] > 0x01102012 in ?? () > (gdb) bt full > #0 0x01102012 in ?? () > No symbol table info available. > (gdb) > > IOW, `bt full' just adds the statement "No symbol table info available." to what > `bt' shows. Try this instead: (gdb) thread apply all bt full (IOW, there's more than one thread in the program, and you happen to be in the wrong one.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 25 12:49:33 2012 Received: (at 11939) by debbugs.gnu.org; 25 Jul 2012 16:49:34 +0000 Received: from localhost ([127.0.0.1]:39322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su4mD-0000Ns-6S for submit@debbugs.gnu.org; Wed, 25 Jul 2012 12:49:33 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:46877) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su4mA-0000Nl-VM for 11939@debbugs.gnu.org; Wed, 25 Jul 2012 12:49:31 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PGgfMX026270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2012 16:42:42 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6PGge9F025206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 16:42:41 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6PGgeRM019442; Wed, 25 Jul 2012 11:42:40 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jul 2012 09:42:40 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> <838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Wed, 25 Jul 2012 09:42:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83629blssa.fsf@gnu.org> Thread-Index: Ac1qgQuBCY7MZB/TQweqSDaFR1P/ogAA1cSw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: rudalics@gmx.at, 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Try this instead: > (gdb) thread apply all bt full > > (IOW, there's more than one thread in the program, and you happen to > be in the wrong one.) Program received signal SIGSEGV, Segmentation fault. [Switching to thread 420.0x1468] 0x01102012 in ?? () (gdb) thread apply all bt full Thread 2 (thread 420.0x14c4): #0 0x7c90e514 in ntdll!LdrAccessResource () No symbol table info available. #1 0x7e4191be in USER32!GetProcessWindowStation () No symbol table info available. #2 0x7e42776b in USER32!GetMessageA () No symbol table info available. #3 0x723dfee0 in ?? () No symbol table info available. Thread 1 (thread 420.0x1468): #0 0x01102012 in ?? () No symbol table info available. (gdb) From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 25 13:35:15 2012 Received: (at 11939) by debbugs.gnu.org; 25 Jul 2012 17:35:15 +0000 Received: from localhost ([127.0.0.1]:39382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su5UR-0001Oc-6L for submit@debbugs.gnu.org; Wed, 25 Jul 2012 13:35:15 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:27594) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Su5UO-0001OU-Ej for 11939@debbugs.gnu.org; Wed, 25 Jul 2012 13:35:13 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PHSN4s011344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2012 17:28:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6PHSN5E027524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 17:28:23 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6PHSMl9014112; Wed, 25 Jul 2012 12:28:22 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jul 2012 10:28:22 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com><5002EAF4.5080107@gmx.at><6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com><5003DAF2.2060400@gmx.at><50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Wed, 25 Jul 2012 10:28:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac1qgQuBCY7MZB/TQweqSDaFR1P/ogAA1cSwAABE3VA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Martin, I tried what you suggested about `after-make-frame-functions' again, but this time with my setup (with unmodified oneonone.el). I added only this to my usual setup: (add-hook 'after-make-frame-functions (lambda (frame) (redirect-frame-focus frame frame))) I then ran through the scenario that lead to a crash (C-x C-c, no to exit, C-x k *shell* + yes, C-x k again, try to type or move cursor). No crash in this case, but when I try to type something or move the cursor after the second C-x k (which is the point at which the crash occurred), I can see that the input is being sent to buffer & frame *Process List*. That's not what you expected, is it? It is not TRT, in any case. I do not understand, BTW, why you redirect the focus from the new frame to itself, instead of to the minibuffer frame. So I tried instead redirecting the focus to the minibuffer frame. That worked OK, but the default buffer for killing with C-x k was ` *Minibuf-0*', not *shell* or *Process List*. It seems that when a new frame is created, the default value for C-x k (and other buffer commands) becomes *Minibuf-0*. I can of course choose not to use the default value, but it would be good to get this part fixed also. Or as a workaround I can explicitly select the frame of the buffer I want to kill - e.g., click the title bar of frame *shell*. After I do that, that buffer becomes the default value for C-x k. IOW, it seems that not only is the input focus redirected to the minibuffer frame, but also the current buffer is changed to *Minibuf-0*. And if I do `M-: (current-buffer)' I do get *Minibuf-0*. Is it normal for frame-focus redirection to change the current buffer also? That does not seem right to me. Anyway, aside from this problem of default value for C-x k, things seemed to work OK. So overall this seems like a reasonable solution, except for the default buffer problem. This is all I did, along with my usual setup: (add-hook 'after-make-frame-functions (lambda (frame) (redirect-frame-focus frame (window-frame (minibuffer-window))))) From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 05:50:19 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 09:50:19 +0000 Received: from localhost ([127.0.0.1]:40346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuKi2-0006UO-Sy for submit@debbugs.gnu.org; Thu, 26 Jul 2012 05:50:19 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52729) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SuKi0-0006UG-GY for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 05:50:17 -0400 Received: (qmail invoked by alias); 26 Jul 2012 09:43:25 -0000 Received: from 62-47-53-226.adsl.highway.telekom.at (EHLO [62.47.53.226]) [62.47.53.226] by mail.gmx.net (mp040) with SMTP; 26 Jul 2012 11:43:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+HUjdLACSHtqYcJahKy6kT973z63izg623SHr3TM nmtLwdJJy/cSOx Message-ID: <5011113F.8070307@gmx.at> Date: Thu, 26 Jul 2012 11:43:27 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <500D1A93.606@gmx.at> <500E993F.7020502@gmx.at> <23244A80D9924C4D967C3364D8A6F616@us.oracle.com> In-Reply-To: <23244A80D9924C4D967C3364D8A6F616@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I speculated to you > about putting the focus redirection instead on `post-command-hook', but you said > that was a bad idea and proposed to "use `after-make-frame-functions'". I am > not sure what you meant by that, but the test above, which uses that hook, did > not work, in any case: the input was not redirected to the minibuffer frame. I did so because you said that you experienced some delay when processing input and had the first characetr entered swallowed in some way. So I attributed this behavior to the use of `post-command-hook' and was suggesting an alternative method. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 05:50:58 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 09:50:58 +0000 Received: from localhost ([127.0.0.1]:40352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuKif-0006VO-NE for submit@debbugs.gnu.org; Thu, 26 Jul 2012 05:50:58 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:45293) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SuKic-0006VF-Ei for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 05:50:55 -0400 Received: (qmail invoked by alias); 26 Jul 2012 09:44:03 -0000 Received: from 62-47-53-226.adsl.highway.telekom.at (EHLO [62.47.53.226]) [62.47.53.226] by mail.gmx.net (mp039) with SMTP; 26 Jul 2012 11:44:03 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18x3ScC3iYxyaH/D8dPFgIULfGo9K+6SbBnzx8ujj D71zyzHGu2qwvg Message-ID: <5011116B.4010106@gmx.at> Date: Thu, 26 Jul 2012 11:44:11 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > (add-hook 'after-make-frame-functions > (lambda (frame) > (redirect-frame-focus frame frame))) > > I then ran through the scenario that lead to a crash (C-x C-c, no to exit, C-x k > *shell* + yes, C-x k again, try to type or move cursor). > > No crash in this case, but when I try to type something or move the cursor after > the second C-x k (which is the point at which the crash occurred), I can see > that the input is being sent to buffer & frame *Process List*. That's not what > you expected, is it? It is not TRT, in any case. > > I do not understand, BTW, why you redirect the focus from the new frame to > itself, instead of to the minibuffer frame. I came to this when trying out various scenarios and it seemed this worked for me. > So I tried instead redirecting the focus to the minibuffer frame. That worked > OK, but the default buffer for killing with C-x k was ` *Minibuf-0*', not > *shell* or *Process List*. > > It seems that when a new frame is created, the default value for C-x k (and > other buffer commands) becomes *Minibuf-0*. I can of course choose not to use > the default value, but it would be good to get this part fixed also. You mean *Minibuf-0* became the current buffer? Probably so because you selected its window. > Or as a workaround I can explicitly select the frame of the buffer I want to > kill - e.g., click the title bar of frame *shell*. After I do that, that buffer > becomes the default value for C-x k. > > IOW, it seems that not only is the input focus redirected to the minibuffer > frame, but also the current buffer is changed to *Minibuf-0*. And if I do `M-: > (current-buffer)' I do get *Minibuf-0*. Is it normal for frame-focus > redirection to change the current buffer also? That does not seem right to me. I nowhere in the code see that it does. Are you sure you did not use `select-frame-set-input-focus' in this case? > Anyway, aside from this problem of default value for C-x k, things seemed to > work OK. So overall this seems like a reasonable solution, except for the > default buffer problem. This is all I did, along with my usual setup: > > (add-hook 'after-make-frame-functions > (lambda (frame) > (redirect-frame-focus frame (window-frame (minibuffer-window))))) That was my initial idea. I forgot why it didn't work (maybe it failed when I created a new frame with a minibuffer). martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 09:58:39 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 13:58:40 +0000 Received: from localhost ([127.0.0.1]:41021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuOaN-0004WH-En for submit@debbugs.gnu.org; Thu, 26 Jul 2012 09:58:39 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:16503) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuOaJ-0004W8-NI for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 09:58:37 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6QDpgaM015113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2012 13:51:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6QDpgvV023027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 13:51:42 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6QDpgcY028762; Thu, 26 Jul 2012 08:51:42 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jul 2012 06:51:41 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50043C3D.7090201@gmx.at><208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Thu, 26 Jul 2012 06:51:38 -0700 Message-ID: <32A934E820BA4853B84229C32F7145A1@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5011116B.4010106@gmx.at> Thread-Index: Ac1rEzHwyVf2/X2CTs2xx5VjZZ30YwAIU8Cw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > I do not understand, BTW, why you redirect the focus from > > the new frame to itself, instead of to the minibuffer frame. > > I came to this when trying out various scenarios and it > seemed this worked for me. OK. It does not work for me. > > So I tried instead redirecting the focus to the minibuffer > > frame. That worked OK, but the default buffer for killing > > with C-x k was ` *Minibuf-0*', not *shell* or *Process List*. > > > > It seems that when a new frame is created, the default > > value for C-x k (and other buffer commands) becomes *Minibuf-0*. > > I can of course choose not to use the default value, but it > > would be good to get this part fixed also. > > You mean *Minibuf-0* became the current buffer? Probably so > because you selected its window. I did not do so explicitly, AFAIK. But perhaps read-from-minibuffer (actually the C code for it) does that? I do not see anywhere that I do so in my code. > > Or as a workaround I can explicitly select the frame of > > the buffer I want to kill - e.g., click the title bar of frame > > *shell*. After I do that, that buffer becomes the default > > value for C-x k. > > > > IOW, it seems that not only is the input focus redirected > > to the minibuffer frame, but also the current buffer is > > changed to *Minibuf-0*. And if I do `M-: > > (current-buffer)' I do get *Minibuf-0*. Is it normal for > > frame-focus redirection to change the current buffer also? > > That does not seem right to me. > > I nowhere in the code see that it does. Are you sure you did > not use `select-frame-set-input-focus' in this case? Yes, I'm pretty sure. I can always try to look closer, but there is certainly nothing in oneonone.el that does that. > > Anyway, aside from this problem of default value for C-x > > k, things seemed to work OK. So overall this seems like a > > reasonable solution, except for the default buffer problem. > > This is all I did, along with my usual setup: > > > > (add-hook 'after-make-frame-functions > > (lambda (frame) > > (redirect-frame-focus frame > > (window-frame (minibuffer-window))))) > > That was my initial idea. I forgot why it didn't work (maybe > it failed when I created a new frame with a minibuffer). What do you think about it now? Do you see a problem with it (aside from the current-buffer problem I mentioned)? Maybe it is worth pursuing; dunno. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 11:55:44 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 15:55:44 +0000 Received: from localhost ([127.0.0.1]:41187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuQPg-0007yR-5u for submit@debbugs.gnu.org; Thu, 26 Jul 2012 11:55:44 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:60447) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SuQPd-0007yI-Ub for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 11:55:43 -0400 Received: (qmail invoked by alias); 26 Jul 2012 15:48:49 -0000 Received: from 62-47-55-7.adsl.highway.telekom.at (EHLO [62.47.55.7]) [62.47.55.7] by mail.gmx.net (mp031) with SMTP; 26 Jul 2012 17:48:49 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+8En189CC8xnzmQWc73+IB68rrFtB/Wwfn4g4fvn 7ScCIWlwTT49xd Message-ID: <501166DB.2090406@gmx.at> Date: Thu, 26 Jul 2012 17:48:43 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> <838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 'Eli Zaretskii' , 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Program received signal SIGSEGV, Segmentation fault. > [Switching to thread 420.0x1468] > 0x01102012 in ?? () > (gdb) thread apply all bt full > > Thread 2 (thread 420.0x14c4): > #0 0x7c90e514 in ntdll!LdrAccessResource () > No symbol table info available. > #1 0x7e4191be in USER32!GetProcessWindowStation () > No symbol table info available. > #2 0x7e42776b in USER32!GetMessageA () > No symbol table info available. > #3 0x723dfee0 in ?? () > No symbol table info available. > > Thread 1 (thread 420.0x1468): > #0 0x01102012 in ?? () > No symbol table info available. > (gdb) I'm lost here. Did you type "gdb -p PID" from the directory where your .gdbinit resides? martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 11:59:23 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 15:59:23 +0000 Received: from localhost ([127.0.0.1]:41192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuQTC-00083P-P4 for submit@debbugs.gnu.org; Thu, 26 Jul 2012 11:59:23 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:32357) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuQTA-00083F-Gv for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 11:59:21 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6QFqP2O006418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2012 15:52:26 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6QFqPqA017563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 15:52:25 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6QFqONB013083; Thu, 26 Jul 2012 10:52:24 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jul 2012 08:52:24 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@gmx.at> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@gmx.at> <96A974694CF64567A3EAB85185AB3A5C@us.oracle.com> <500BBE6F.6020007@gmx.at> <1403DD3D67534F53BC023CC99A258DF5@us.oracle.com> <838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org> <81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com> <83fw8iz7et.fsf@gnu.org> <60948DD3935D452F85F95174474D06E9@us.oracle.com> <838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> <501! 166DB.2090406@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Thu, 26 Jul 2012 08:52:23 -0700 Message-ID: <17DA5BC98DFB4B538E06183DEA4ACB05@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <501166DB.2090406@gmx.at> Thread-Index: Ac1rRicCtwOheSOTRT63+r8euULvngAAGv4w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 'Eli Zaretskii' , 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > I'm lost here. Did you type "gdb -p PID" from the directory > where your .gdbinit resides? Yes. I did everything from that directory. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 12:12:47 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 16:12:47 +0000 Received: from localhost ([127.0.0.1]:41213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuQgA-0008ML-Mj for submit@debbugs.gnu.org; Thu, 26 Jul 2012 12:12:47 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:51670) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SuQg7-0008MD-NU for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 12:12:44 -0400 Received: (qmail invoked by alias); 26 Jul 2012 16:05:51 -0000 Received: from 62-47-55-7.adsl.highway.telekom.at (EHLO [62.47.55.7]) [62.47.55.7] by mail.gmx.net (mp037) with SMTP; 26 Jul 2012 18:05:51 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+zpEFXinuzvPWPEQWOC3YSr1dCojsPyRfa0irMwf 1qyWRBE4eeo0Fp Message-ID: <50116AD9.70609@gmx.at> Date: Thu, 26 Jul 2012 18:05:45 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle.com> In-Reply-To: <32A934E820BA4853B84229C32F7145A1@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > So I tried instead redirecting the focus to the minibuffer >> > frame. That worked OK, but the default buffer for killing >> > with C-x k was ` *Minibuf-0*', not *shell* or *Process List*. >> > >> > It seems that when a new frame is created, the default >> > value for C-x k (and other buffer commands) becomes *Minibuf-0*. >> > I can of course choose not to use the default value, but it >> > would be good to get this part fixed also. >> >> You mean *Minibuf-0* became the current buffer? Probably so >> because you selected its window. > > I did not do so explicitly, AFAIK. But perhaps read-from-minibuffer (actually > the C code for it) does that? I do not see anywhere that I do so in my code. It indeed selects the window and sets the current buffer. But C-x k should never offer *Minibuf-0* for killing. Does it really prompt with *Minibuf-0*? If so, then the following excerpt from Fcall_interactively case 'b': /* Name of existing buffer */ args[i] = Fcurrent_buffer (); if (EQ (selected_window, minibuf_window)) args[i] = Fother_buffer (args[i], Qnil, Qnil); args[i] = Fread_buffer (callint_message, args[i], Qt); break; is broken. IIUC it means that the current buffer is the buffer of the minibuffer window (how did that happen?) but the minibuffer window is not selected. What is missing from the form below to reproduce it? (progn (add-hook 'after-make-frame-functions #'(lambda (frame) (redirect-frame-focus frame (window-frame (minibuffer-window))))) (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil))))) (setq pop-up-frames t) (display-buffer "*Messages*") (yes-or-no-p "???")) martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 12:28:06 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 16:28:06 +0000 Received: from localhost ([127.0.0.1]:41273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuQuw-0000Ho-Qc for submit@debbugs.gnu.org; Thu, 26 Jul 2012 12:28:06 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:40944) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuQur-0000HN-Ed for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 12:28:01 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6QGL44s025451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2012 16:21:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6QGL33I009701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 16:21:04 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6QGL3pI005487; Thu, 26 Jul 2012 11:21:03 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jul 2012 09:21:03 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com><500449B7.6070309@gmx.at><023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com><5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Thu, 26 Jul 2012 09:21:02 -0700 Message-ID: <548032D12CE14E3689257D609E93482F@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50116AD9.70609@gmx.at> Thread-Index: Ac1rSIn1kztcXyYWTW23nReKIahPYwAANMaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > I did not do so explicitly, AFAIK. But perhaps > > read-from-minibuffer (actually the C code for it) does that? > > I do not see anywhere that I do so in my code. > > It indeed selects the window and sets the current buffer. But C-x k > should never offer *Minibuf-0* for killing. Does it really > prompt with *Minibuf-0*? Yes, but (I think) I explained that I have a different command bound to `C-x k'. That command proposes the name of (current-buffer) as the default value. And as I said, the name of the buffer returned by (current-buffer) here is in fact " *Minibuf-0*". > If so, then ... Fcall_interactively... is broken. See above - I am not using `kill-buffer' for `C-x k'. I doubt that anything so basic is broken. > IIUC it means that the current buffer is the buffer of the > minibuffer window (how did that happen?) Yes, that is what I am seeing, confirmed by evaluating (current-buffer) there/then. > but the minibuffer window is not selected. Are you sure? How to know? > What is missing from the form below to reproduce it? > (progn > (add-hook 'after-make-frame-functions > #'(lambda (frame) > (redirect-frame-focus > frame (window-frame (minibuffer-window))))) > (setq pop-up-frame-function > (lambda () (make-frame '((minibuffer . nil))))) > (setq pop-up-frames t) > (display-buffer "*Messages*") > (yes-or-no-p "???")) I don't know. I can try to dig into it later, I suppose (I cannot now). But perhaps try binding `C-x k' to a command that proposes the name of (current-buffer) as the default? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 12:59:26 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 16:59:26 +0000 Received: from localhost ([127.0.0.1]:41321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuRPK-00011c-35 for submit@debbugs.gnu.org; Thu, 26 Jul 2012 12:59:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:59985) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SuRPI-00011U-2d for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 12:59:25 -0400 Received: (qmail invoked by alias); 26 Jul 2012 16:52:31 -0000 Received: from 62-47-55-7.adsl.highway.telekom.at (EHLO [62.47.55.7]) [62.47.55.7] by mail.gmx.net (mp071) with SMTP; 26 Jul 2012 18:52:31 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/zh+tmOnfzG/3Btqj/k+4Y7YuQ6M+jllcBsrCDuo HDfESX959Emem8 Message-ID: <501175C9.3090803@gmx.at> Date: Thu, 26 Jul 2012 18:52:25 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> In-Reply-To: <548032D12CE14E3689257D609E93482F@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Yes, but (I think) I explained that I have a different command bound to `C-x k'. > That command proposes the name of (current-buffer) as the default value. And as > I said, the name of the buffer returned by (current-buffer) here is in fact > " *Minibuf-0*". I see. But then where do you see a problem if your function prompts with the current buffer for killing? Do you ever want to kill the minibuffer's buffer? If not, your function should provide an appropriate workaround default just as `call-interactively' does. >> IIUC it means that the current buffer is the buffer of the >> minibuffer window (how did that happen?) > > Yes, that is what I am seeing, confirmed by evaluating (current-buffer) > there/then. > >> but the minibuffer window is not selected. > > Are you sure? How to know? I assumed that you used `kill-buffer' with the standard prompt. If you use your own function, my conclusion is void. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 13:15:26 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 17:15:26 +0000 Received: from localhost ([127.0.0.1]:41346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuReo-0001OW-BT for submit@debbugs.gnu.org; Thu, 26 Jul 2012 13:15:26 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:43324) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuRem-0001OP-5Y for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 13:15:25 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6QH8UUg012091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2012 17:08:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6QH8US2020565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 17:08:30 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6QH8Ux2024465; Thu, 26 Jul 2012 12:08:30 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jul 2012 10:08:30 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Thu, 26 Jul 2012 10:08:29 -0700 Message-ID: <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <501175C9.3090803@gmx.at> Thread-Index: Ac1rTw0ZFEB+rZtCTC2ahyTW0M4uCAAABUTA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > I see. But then where do you see a problem if your function prompts > with the current buffer for killing? In the scenario I described - see my previous descriptions, but here is a summary of what I did (before): C-x C-c, reply "no" C-x k, with the default being *shell* (even though frame *Process List* was on top and had its title bar highlighted). Reply "yes" to killing the processes. C-x k, wanting to kill *Process List* - see previous descriptions for the problems here. But in the latest test, where I did only the `redirect-*', the default buffer to kill was ALWAYS " *Minibuf-0*". It's not a problem, in the sense that focus is at least in the minibuffer frame and I can therefore choose not to use the default. (In my setup, I automatically have the default inserted in the minibuffer, but I can easily remove it.) > Do you ever want to kill the minibuffer's buffer? No, never. > If not, your function should provide an > appropriate workaround default just as `call-interactively' does. Well OK, I suppose - I can certainly try to do that. But I have never had to do it before. Obviously, if the right thing to do is to work around this hiccup then I can and might try to do that. And as I said: >>> Or as a workaround I can explicitly select the frame of the >>> buffer I want to kill - e.g., click the title bar of frame *shell*. >>> After I do that, that buffer becomes the default value for C-x k. But the point was that the minibuffer buffer was the (current-buffer) here, suggesting to me that the minibuffer frame (and its buffer) was selected. Is that TRT? I didn't think so. I didn't think that just calling `redirect-*' would/should also select the frame and its buffer. That is why I said this: >>> IOW, it seems that not only is the input focus redirected >>> to the minibuffer frame, but also the current buffer is >>> changed to *Minibuf-0*. And if I do `M-: >>> (current-buffer)' I do get *Minibuf-0*. Is it normal for >>> frame-focus redirection to change the current buffer also? >>> That does not seem right to me. None of that has to do with my `C-x k' command, I believe. AFAIK, I do not select the minibuffer frame or buffer. I speculated that perhaps the C code for read-from-minibuffer does, but I don't know that. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 13:48:37 2012 Received: (at 11939) by debbugs.gnu.org; 26 Jul 2012 17:48:37 +0000 Received: from localhost ([127.0.0.1]:41369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuSAu-0002y0-M8 for submit@debbugs.gnu.org; Thu, 26 Jul 2012 13:48:37 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:23461) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuSAt-0002xs-Hz for 11939@debbugs.gnu.org; Thu, 26 Jul 2012 13:48:36 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6QHfg0R017348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2012 17:41:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6QHffcW023598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 17:41:42 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6QHffEm015398; Thu, 26 Jul 2012 12:41:41 -0500 Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jul 2012 10:41:41 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5005354E.6040306@gmx.at><62CF21F0010048E2BC1391192EB943FF@us.oracle.com><5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4! B750709112@us.oracle. com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Thu, 26 Jul 2012 10:41:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> Thread-Index: Ac1rTw0ZFEB+rZtCTC2ahyTW0M4uCAAABUTAAAGK4xA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Do you ever want to kill the minibuffer's buffer? > > No, never. > > > If not, your function should provide an > > appropriate workaround default just as `call-interactively' does. > > Well OK, I suppose - I can certainly try to do that. > > But I have never had to do it before. Obviously, if the > right thing to do is to work around this hiccup then I can and > might try to do that. But I would add that I prefer not to do that, for a couple of reasons. One is that the same general list of buffer candidates and default value are used for multiple commands, not just the command bound to `C-x k'. And while it is true that I never want to kill the minibuffer buffer, that does not mean that I never want to do some other operation using it. Anyway, I'm sure you get the point: the buffer that I would expect to be (current-buffer) here is the buffer in which I invoked `C-x k' (or whatever) - not " *Minibuf-0*. The latter does not make much sense to me. And I think (still, so far) that that is the case because (somehow) the minibuffer frame got _selected_, and did not just have its input focus redirected to it. And I think, a priori, that is not TRT. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 27 02:40:20 2012 Received: (at 11939) by debbugs.gnu.org; 27 Jul 2012 06:40:20 +0000 Received: from localhost ([127.0.0.1]:42696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SueDi-0004YZ-59 for submit@debbugs.gnu.org; Fri, 27 Jul 2012 02:40:19 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:46614) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SueDf-0004YO-8I for 11939@debbugs.gnu.org; Fri, 27 Jul 2012 02:40:17 -0400 Received: (qmail invoked by alias); 27 Jul 2012 06:33:18 -0000 Received: from 62-47-33-200.adsl.highway.telekom.at (EHLO [62.47.33.200]) [62.47.33.200] by mail.gmx.net (mp033) with SMTP; 27 Jul 2012 08:33:18 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18kHHQdZT4kGAl/mBDloeoUBVzoeBZZZ8jOy7uQNz K3nMxEjQSRc/dk Message-ID: <5012362A.7070200@gmx.at> Date: Fri, 27 Jul 2012 08:33:14 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> In-Reply-To: <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> I see. But then where do you see a problem if your function prompts >> with the current buffer for killing? > > In the scenario I described - see my previous descriptions, but here is a > summary of what I did (before): > > C-x C-c, reply "no" > > C-x k, with the default being *shell* (even though frame *Process List* was on > top and had its title bar highlighted). Reply "yes" to killing the processes. > > C-x k, wanting to kill *Process List* - see previous descriptions for the > problems here. > > But in the latest test, where I did only the `redirect-*', the default buffer to > kill was ALWAYS " *Minibuf-0*". It's not a problem, in the sense that focus is > at least in the minibuffer frame and I can therefore choose not to use the > default. (In my setup, I automatically have the default inserted in the > minibuffer, but I can easily remove it.) I don't know what your C-x k does so I can't comment on it. The fact that `call-interactively' calls `other-buffer' when the selected window is the minibuffer window indicates that such a thing may happen and it will happen, for example, when I'm in the minibuffer and do M-:. >> Do you ever want to kill the minibuffer's buffer? > > No, never. > >> If not, your function should provide an >> appropriate workaround default just as `call-interactively' does. > > Well OK, I suppose - I can certainly try to do that. > > But I have never had to do it before. Obviously, if the right thing to do is to > work around this hiccup then I can and might try to do that. And as I said: ... as long as you can't tell me how you got into this hiccup ... >>>> Or as a workaround I can explicitly select the frame of the >>>> buffer I want to kill - e.g., click the title bar of frame *shell*. >>>> After I do that, that buffer becomes the default value for C-x k. > > But the point was that the minibuffer buffer was the (current-buffer) here, > suggesting to me that the minibuffer frame (and its buffer) was selected. > > Is that TRT? I didn't think so. I didn't think that just calling `redirect-*' > would/should also select the frame and its buffer. That is why I said this: Just calling `redirect-*' does not select the frame and its buffer. But `yes-or-no-p' does since otherwise you won't be able to type into the minibuffer - here's the relevant piece in read_minibuf: /* Display this minibuffer in the proper window. */ Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil); Fselect_window (minibuf_window, Qnil); XWINDOW (minibuf_window)->hscroll = 0; >>>> IOW, it seems that not only is the input focus redirected >>>> to the minibuffer frame, but also the current buffer is >>>> changed to *Minibuf-0*. And if I do `M-: >>>> (current-buffer)' I do get *Minibuf-0*. Is it normal for >>>> frame-focus redirection to change the current buffer also? >>>> That does not seem right to me. > > None of that has to do with my `C-x k' command, I believe. AFAIK, I do not > select the minibuffer frame or buffer. I speculated that perhaps the C code for > read-from-minibuffer does, but I don't know that. See above. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 27 02:40:55 2012 Received: (at 11939) by debbugs.gnu.org; 27 Jul 2012 06:40:55 +0000 Received: from localhost ([127.0.0.1]:42699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SueEI-0004ZN-On for submit@debbugs.gnu.org; Fri, 27 Jul 2012 02:40:55 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:45577) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SueEG-0004ZF-Cz for 11939@debbugs.gnu.org; Fri, 27 Jul 2012 02:40:53 -0400 Received: (qmail invoked by alias); 27 Jul 2012 06:33:56 -0000 Received: from 62-47-33-200.adsl.highway.telekom.at (EHLO [62.47.33.200]) [62.47.33.200] by mail.gmx.net (mp037) with SMTP; 27 Jul 2012 08:33:56 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/OqmRUQ0HOKtDG6oCCwajsXvJlfGcwfOTggcLCS/ ocDRxCH0Nsf0iQ Message-ID: <50123650.8020508@gmx.at> Date: Fri, 27 Jul 2012 08:33:52 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4! B750709112@us.oracle. com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > And I think (still, so far) that that is the case because (somehow) the > minibuffer frame got _selected_, and did not just have its input focus > redirected to it. And I think, a priori, that is not TRT. Yes. But as long as we don't know how this happens there's not much we can do about it. Can't you try displaying in the mode-line of each window (1) that window (2) the selected window and (3) the current buffer. So after redisplay we know which window is selected ... martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 28 11:37:02 2012 Received: (at 11939) by debbugs.gnu.org; 28 Jul 2012 15:37:02 +0000 Received: from localhost ([127.0.0.1]:46766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv94f-0005zx-V2 for submit@debbugs.gnu.org; Sat, 28 Jul 2012 11:37:02 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:18896) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv94e-0005zT-2s for 11939@debbugs.gnu.org; Sat, 28 Jul 2012 11:37:00 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6SFTs87032011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jul 2012 15:29:55 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6SFTrjr023108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jul 2012 15:29:54 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6SFTrf1015540; Sat, 28 Jul 2012 10:29:53 -0500 Received: from dradamslap1 (/10.159.164.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 Jul 2012 08:29:53 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Sat, 28 Jul 2012 08:29:46 -0700 Message-ID: <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1rwbcyR7HPUdV0T0u4Sy04w6JOkABCmVfQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <5012362A.7070200@gmx.at> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > But the point was that the minibuffer buffer was the > > (current-buffer) here, suggesting to me that the minibuffer > > frame (and its buffer) was selected. > > > > Is that TRT? I didn't think so. I didn't think that just > > calling `redirect-*' would/should also select the frame and > > its buffer. That is why I said this: > > Just calling `redirect-*' does not select the frame and its > buffer. But `yes-or-no-p' does since otherwise you won't be > able to type into the minibuffer - here's the relevant piece > in read_minibuf: > > /* Display this minibuffer in the proper window. */ > Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil); > Fselect_window (minibuf_window, Qnil); > XWINDOW (minibuf_window)->hscroll = 0; Well, OK. But normally, after the input is read the selected window/frame returns to what it was before the reading. No? IOW, yes, it is normal and necessary for yes/no input to be entered in the minibuffer window, so naturally that window must be selected for the duration of that user input. The problem is (apparently) that the minibuffer buffer remains selected after the reading, i.e., the (current-buffer) is " *Minibuf-0*". Thus, a subsequent command such as `C-x k' sees that buffer as the current one. That has not happened before - it seems to come as a result of redirecting the frame focus, but perhaps that is just a catalyst/revealer. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 28 11:37:13 2012 Received: (at 11939) by debbugs.gnu.org; 28 Jul 2012 15:37:13 +0000 Received: from localhost ([127.0.0.1]:46768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv94q-00060C-Lj for submit@debbugs.gnu.org; Sat, 28 Jul 2012 11:37:12 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:18898) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv94e-0005zV-U5 for 11939@debbugs.gnu.org; Sat, 28 Jul 2012 11:37:01 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6SFTuiq032013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jul 2012 15:29:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6SFTtk3023117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jul 2012 15:29:55 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6SFTtF1018540; Sat, 28 Jul 2012 10:29:55 -0500 Received: from dradamslap1 (/10.159.164.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 Jul 2012 08:29:54 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4! B750709112@us.oracle. com> <50123650.8020 508@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Sat, 28 Jul 2012 08:29:48 -0700 Message-ID: <5F24DB25D9304E9483E00D4800B81E9E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1rwc8JXNmepa9wRridMLEYdgR8DgBCx15w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <50123650.8020508@gmx.at> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > And I think (still, so far) that that is the case because > > (somehow) the minibuffer frame got _selected_, and did not > > just have its input focus redirected to it. And I think, > > a priori, that is not TRT. > > Yes. But as long as we don't know how this happens there's > not much we can do about it. I don't understand. Your other message, sent at the same time as that one, said that you know it is `yes-or-no-p' that does that, and that that is necessary. > Can't you try displaying in the mode-line of each > window (1) that window (2) the selected window and (3) the current > buffer. So after redisplay we know which window is selected ... Can you tell me how to do that? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 28 11:38:58 2012 Received: (at 11939) by debbugs.gnu.org; 28 Jul 2012 15:38:58 +0000 Received: from localhost ([127.0.0.1]:46777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv96X-00062V-3e for submit@debbugs.gnu.org; Sat, 28 Jul 2012 11:38:57 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:19150) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sv96U-00062N-L5 for 11939@debbugs.gnu.org; Sat, 28 Jul 2012 11:38:56 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6SFVnud000416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jul 2012 15:31:50 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6SFVmUq013278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jul 2012 15:31:49 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6SFVmEC019346; Sat, 28 Jul 2012 10:31:48 -0500 Received: from dradamslap1 (/10.159.164.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 Jul 2012 08:31:48 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4! B750709112@us.oracle. com> <50123650.8020 508@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Sat, 28 Jul 2012 08:31:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1rwc8JXNmepa9wRridMLEYdgR8DgBEiyWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <50123650.8020508@gmx.at> X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Martin, Can you tell me where you think we are with this bug? Can we please separate out any other bugs/problems that have been encountered in this thread, such as crashes, and return to the problem of the bug report? I thought we were making progress on that, but it's not clear to me where we are now wrt the problem. Here's my attempt at a summary - but please help me fill things in, with your understanding: You wrote some code which improved things, and I tried various things, the last of which was this: (add-hook 'after-make-frame-functions (lambda (frame) (redirect-frame-focus frame (window-frame (minibuffer-window))))) You mentioned that when you tried redirecting to the minibuffer frame that way you encountered some problems, but you didn't remember what they were. I said that when I instead redirected the frame to itself (which I guess worked for you), it did not solve the focus problem (for me). I said that with the above code another problem is introduced, which is that the current-buffer and selected window are apparently left as " *Minibuf-0*". Do you have a better idea of where things stand wrt this problem? Will you be applying your latest code to Emacs? Where do you think we should go from here, to progress a bit and perhaps finish this? In sum, I would like us to try to refocus on the original problem and see if we can take stock of what we have learned. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 29 10:02:51 2012 Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 14:02:52 +0000 Received: from localhost ([127.0.0.1]:48825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvU55-0004Fo-4l for submit@debbugs.gnu.org; Sun, 29 Jul 2012 10:02:51 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:50052) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SvU52-0004Ff-Oo for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 10:02:49 -0400 Received: (qmail invoked by alias); 29 Jul 2012 13:55:40 -0000 Received: from 62-47-44-164.adsl.highway.telekom.at (EHLO [62.47.44.164]) [62.47.44.164] by mail.gmx.net (mp039) with SMTP; 29 Jul 2012 15:55:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18YQXMPa5MYjWdESznsb0OiumCxqxFyb2YKlNiemT QJ8FysCCO9qORU Message-ID: <501540D0.50900@gmx.at> Date: Sun, 29 Jul 2012 15:55:28 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> In-Reply-To: <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Well, OK. But normally, after the input is read the selected window/frame > returns to what it was before the reading. No? I don't know. read_minibuf does (my remarks appear below the code): /* Choose the minibuffer window and frame, and take action on them. */ choose_minibuf_frame (); record_unwind_protect (choose_minibuf_frame_1, Qnil); I don't understand the last two calls, IMHO one of them seems redundant. record_unwind_protect (Fset_window_configuration, Fcurrent_window_configuration (Qnil)); I don't know which frame is selected here in your case. /* If the minibuffer window is on a different frame, save that frame's configuration too. */ mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window)); if (!EQ (mini_frame, selected_frame)) record_unwind_protect (Fset_window_configuration, Fcurrent_window_configuration (mini_frame)); But this should restore the configuration of your minibuffer frame. I don't have the slightest idea whether and how the selected window is preserved provided it's on another frame. You could try checking via `minibuffer-setup-hook' and `minibuffer-exit-hook' but I'm afraid the latter is executed too early and you're still in the same state of affairs as in the setup hook. Are you stuck in the minibuffer window even when you do `top-level'? > The problem is (apparently) that the minibuffer buffer remains selected after > the reading, i.e., the (current-buffer) is " *Minibuf-0*". Thus, a subsequent > command such as `C-x k' sees that buffer as the current one. That has not > happened before - it seems to come as a result of redirecting the frame focus, > but perhaps that is just a catalyst/revealer. If this were the case, we'd have a bug. But the code doesn't indicate that. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 29 10:03:27 2012 Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 14:03:27 +0000 Received: from localhost ([127.0.0.1]:48829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvU5e-0004H0-1J for submit@debbugs.gnu.org; Sun, 29 Jul 2012 10:03:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:57252) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SvU5b-0004Gt-FV for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 10:03:24 -0400 Received: (qmail invoked by alias); 29 Jul 2012 13:56:14 -0000 Received: from 62-47-44-164.adsl.highway.telekom.at (EHLO [62.47.44.164]) [62.47.44.164] by mail.gmx.net (mp033) with SMTP; 29 Jul 2012 15:56:14 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/LoelUdaPLna4iKm6PBvWv1ZGgdirSZzFDAsNVA2 L26KD7qs3h2jlO Message-ID: <501540F4.3090200@gmx.at> Date: Sun, 29 Jul 2012 15:56:04 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4! B750709112@us.oracle. com> <50123650.8020 508@gmx.at> <5F24DB25D9304E9483E00D4800B81E9E@us.oracle.com> In-Reply-To: <5F24DB25D9304E9483E00D4800B81E9E@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > And I think (still, so far) that that is the case because >> > (somehow) the minibuffer frame got _selected_, and did not >> > just have its input focus redirected to it. And I think, >> > a priori, that is not TRT. >> >> Yes. But as long as we don't know how this happens there's >> not much we can do about it. > > I don't understand. Your other message, sent at the same time as that one, said > that you know it is `yes-or-no-p' that does that, and that that is necessary. I "know that `yes-or-no-p' does that, and that that is necessary" but I do not know whether "it is `yes-or-no-p' that does that". Only you could find out by going through this with the debugger. >> Can't you try displaying in the mode-line of each >> window (1) that window (2) the selected window and (3) the current >> buffer. So after redisplay we know which window is selected ... > > Can you tell me how to do that? No. I forgot that when displaying the modeline, its window is selected and its buffer made current. But the following unnecessarily complex part of my setup displays the window number in the modeline. (defun prettify (size-string pretty-string) "Prettify number by inserting dots." (if (> (length size-string) 3) (prettify (substring size-string 0 -3) (concat "." (substring size-string -3) pretty-string)) (concat size-string pretty-string))) (defface mode-line-numbers '((t :family "Verdana" :weight bold)) "Basic mode line face for selected window." :version "23.1" :group 'mode-line-faces) (let* ((help-echo ;; The multi-line message doesn't work terribly well on the ;; bottom mode line... Better ideas? ;; "\ ;; mouse-1: select window, mouse-2: delete others, mouse-3: delete, ;; drag-mouse-1: resize, C-mouse-2: split horizontally" "mouse-1: select (drag to resize), mouse-3: delete or split") (dashes (propertize "--" 'help-echo help-echo))) (setq-default mode-line-format (list "%e" (propertize " " 'help-echo help-echo) 'mode-line-mule-info 'mode-line-modified (propertize " " 'help-echo help-echo) 'mode-line-buffer-identification (propertize " " 'help-echo help-echo) 'mode-line-position '(vc-mode vc-mode) (propertize " " 'help-echo help-echo) 'mode-line-modes `(which-func-mode ("" which-func-format ,dashes)) `(global-mode-string (,dashes global-mode-string)) (propertize " " 'help-echo help-echo))) (setq-default mode-line-modes (list `(:propertize ("" mode-name) help-echo "mouse-1: major mode menu mouse-3: minor modes menu" mouse-face mode-line-highlight local-map ,mode-line-major-mode-keymap) '("" mode-line-process) `(:propertize ("" minor-mode-alist) mouse-face mode-line-highlight help-echo "mouse-1: minor mode menu mouse-3: minor modes menu" local-map ,mode-line-minor-mode-keymap) (propertize "%n" 'help-echo "mouse-3: widen" 'mouse-face 'mode-line-highlight 'local-map (make-mode-line-mouse-map 'mouse-3 #'mode-line-widen)))) (setq-default mode-line-position '(:eval (let ((help-echo "mouse-1: select (drag to resize), mouse-3: delete")) `(10 ,(propertize (concat " %l / %c / " (propertize (prettify (format "%i" (point)) "") 'face 'mode-line-numbers) (propertize (concat ; WINDOW (replace-regexp-in-string ">" "" (replace-regexp-in-string " on.+" "" (replace-regexp-in-string "#) id 1SvU5x-0004HV-1c for submit@debbugs.gnu.org; Sun, 29 Jul 2012 10:03:45 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:57987) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SvU5v-0004HO-AL for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 10:03:44 -0400 Received: (qmail invoked by alias); 29 Jul 2012 13:56:34 -0000 Received: from 62-47-44-164.adsl.highway.telekom.at (EHLO [62.47.44.164]) [62.47.44.164] by mail.gmx.net (mp002) with SMTP; 29 Jul 2012 15:56:34 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+ec8wMmWGepzz0j0GmByySJsqymNn4baSRzm1OV3 GjFCnJuZgppD9c Message-ID: <50154108.7040404@gmx.at> Date: Sun, 29 Jul 2012 15:56:24 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4! B750709112@us.oracle. com> <50123650.8020 508@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Here's my attempt at a summary - but please help me fill things in, with your > understanding: > > You wrote some code which improved things, and I tried various things, the last > of which was this: > > (add-hook 'after-make-frame-functions > (lambda (frame) > (redirect-frame-focus frame > (window-frame (minibuffer-window))))) > > You mentioned that when you tried redirecting to the minibuffer frame that way > you encountered some problems, but you didn't remember what they were. I said > that when I instead redirected the frame to itself (which I guess worked for > you), it did not solve the focus problem (for me). > > I said that with the above code another problem is introduced, which is that the > current-buffer and selected window are apparently left as " *Minibuf-0*". > > Do you have a better idea of where things stand wrt this problem? IIUC the above is what you wanted to apply for making your code work with versions <= Emacs 24.1. > Will you be > applying your latest code to Emacs? Unless you tell me that you find any problems with it. > Where do you think we should go from here, > to progress a bit and perhaps finish this? > > In sum, I would like us to try to refocus on the original problem and see if we > can take stock of what we have learned. I can't say that I have learned much so far. Most of the focus redirection stuff still remains a mystery to me. Personally, I would never use a separate minibuffer frame for the sole reason that I don't understand how it works. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 29 12:34:23 2012 Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 16:34:23 +0000 Received: from localhost ([127.0.0.1]:48938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvWRj-0007dX-2z for submit@debbugs.gnu.org; Sun, 29 Jul 2012 12:34:23 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:20692) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvWRh-0007dP-2f for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 12:34:21 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6TGR9gr017979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jul 2012 16:27:10 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6TGR8Rj005146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 16:27:09 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6TGR8SU017109; Sun, 29 Jul 2012 11:27:08 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Jul 2012 09:27:07 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> <501540D0.50900@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Sun, 29 Jul 2012 09:26:57 -0700 Message-ID: <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <501540D0.50900@gmx.at> Thread-Index: Ac1tkdhJROt88xAFSbmd1PpEbT7rcQAE/dWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Are you stuck in the minibuffer window even when you do `top-level'? I don't know what you mean by "stuck in the minibuffer window. After the command I am at top level. And I am in no way stuck in a minibuffer window. The problem is that the `current-buffer' is " *Minibuf-0*". That's all. > > The problem is (apparently) that the minibuffer buffer > > remains selected after the reading, i.e., the (current-buffer) > > is " *Minibuf-0*". Thus, a subsequent command such as `C-x k' > > sees that buffer as the current one. That has not > > happened before - it seems to come as a result of redirecting > > the frame focus, but perhaps that is just a catalyst/revealer. > > If this were the case, we'd have a bug. But the code doesn't > indicate that. Not sure what "this" you are referring to: "it seems to come as a result..." or the behavior that "the (current-buffer) is " *Minibuf-0*"." I do not know what the cause is. I was only wondering out loud whether it somehow comes as a result of redirecting the focus. But what is clear is that (current-buffer) is " *Minibuf-0*". From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 29 13:15:37 2012 Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 17:15:37 +0000 Received: from localhost ([127.0.0.1]:48973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvX5d-00007l-3R for submit@debbugs.gnu.org; Sun, 29 Jul 2012 13:15:37 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:46444) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SvX5b-00007d-82 for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 13:15:35 -0400 Received: (qmail invoked by alias); 29 Jul 2012 17:08:25 -0000 Received: from 62-47-39-33.adsl.highway.telekom.at (EHLO [62.47.39.33]) [62.47.39.33] by mail.gmx.net (mp031) with SMTP; 29 Jul 2012 19:08:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19eJcJJPJBePRpqA9VEpgUTgaNlPHlZ3b2DZ+/hWH 0UsJTev6NPFrOP Message-ID: <50156DFE.6090807@gmx.at> Date: Sun, 29 Jul 2012 19:08:14 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> <501540D0.50900@gmx.at> <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> In-Reply-To: <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.3 (/) > After the command I am at top level. And I am in no way stuck in a minibuffer > window. > > The problem is that the `current-buffer' is " *Minibuf-0*". That's all. So you mean you are at top level, the selected window is the minibuffer window, its buffer is current, and you've never seen such behavior. Is that a correct description of what you experience? martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 29 14:08:57 2012 Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 18:08:57 +0000 Received: from localhost ([127.0.0.1]:49049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvXvE-0001JZ-8E for submit@debbugs.gnu.org; Sun, 29 Jul 2012 14:08:56 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:21437) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvXvA-0001JP-0Y for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 14:08:53 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6TI1eEV022597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jul 2012 18:01:41 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6TI1dar019854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 18:01:40 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6TI1dJc015398; Sun, 29 Jul 2012 13:01:39 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Jul 2012 11:01:39 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> <501540D0.50900@gmx.at> <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> <50156DFE.6090807@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Sun, 29 Jul 2012 11:01:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50156DFE.6090807@gmx.at> Thread-Index: Ac1trMbBiJLAQy/TRGm2Cz9tNc+gdQAAflbA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > After the command I am at top level. And I am in no way > > stuck in a minibuffer window. > > > > The problem is that the `current-buffer' is " > > *Minibuf-0*". That's all. > > So you mean you are at top level, the selected window is the > minibuffer window, its buffer is current, and you've never > seen such behavior. Is that a correct description of what you > experience? I think we're both probably getting a bit lost in all of the emails, especially with the lapse of time, different tries of different scenarios, and encountered side issues (e.g. crashes). I apologize for contributing to that. Here's the (current) issue and scenario. It uses my setup (with untweaked oneonone.el but also with the other libraries that I use). The only thing I've done differently than usual is to evaluate this sexp: (add-hook 'after-make-frame-functions (lambda (frame) (redirect-frame-focus frame (window-frame (minibuffer-window))))) I do M-x shell. Then I do C-x C-c. The `yes-or-no-p' prompt about active processes appears in the minibuffer. I type "no" into the minibuffer. So far so good. Things are perfectly normal now, and I am at top level (the minibuffer has exited normally). I then do C-x k. Because my setup automatically inserts the default value (what `M-n' gives), that buffer-name value is inserted in the minibuffer, waiting for me to hit RET to accept it or to edit it and then hit RET. The default buffer name in this case is " *Minibuf-0*". That is what I have never seen before. I.e., without adding that `add-hook' sexp (above), I do not get this behavior. But I am not in any way trapped in the minibuffer. I can edit the buffer name to kill the buffer I want. Or I can hit C-g. And so on. The only problem is that the value of `(current-buffer)' is " *Minibuf-0*" at that point. I know that by testing with `message' etc. That is why I hypothesized that something in that frame focus redirection caused the buffer " *Minibuf-0*" to become selected, i.e., the `current-buffer'. But you corrected me, pointing out that `yes-or-no-p' does that: it selects the minibuffer window/buffer. If I do not do the `add-hook', then I cannot type yes/no to the `yes-or-no-p' prompt, without first manually selecting the minibuffer frame (e.g. by clicking its titlebar). And if I do that then the symptoms are the same as when I use the `add-hook': after typing "no", if I use C-x k then " *Minibuf-0*" is the default buffer to kill. But if (I do not do the `add-hook' and) I do `M-: (yes-or-no-p "Foo? ")' and I answer "no", then `C-x k' uses another buffer (the one selected before the M-:) as the default value. I am not sure why this difference, i.e., why `yes-or-no-p' does not leave " *Minibuf-0*" as the current buffer in this case. But it probably has to do with the execution of command `M-:' - IOW, in that test it is not just `yes-or-no-p' that is involved, but also `M-:'. So perhaps this is only a problem with (because of) `yes-or-no-p'. And perhaps there is nothing that can (or should?) be done about it. It is anyway a minor problem compared to the general problem that this bug report is about: loss of focus to the minibuffer frame. I hope we are now clear about this `C-x k' default-buffer problem. Dunno what can or should be done about it. It seems (to me, so far) to be a problem with `yes-or-no-p' (and perhaps some other functions?): In order to ask its question, `yes-or-no-p' not only redirects input focus to the minibuffer but it also (apparently) selects the minibuffer's buffer. And it apparently leaves that buffer selected, as the `current-buffer'. You know better than I what, if anything could/should be done to correct this. Should `yes-or-no-p' use `with-current-buffer' or something, so that it finishes by selecting again the buffer that was selected when it started? I'm guessing yes, but I know nothing about the code. It seems wrong that it should change the selected buffer to the minibuffer and leave it so changed. The above behavior description holds for all Emacs versions I have. The `add-hook' solves the unfocused minibuffer frame problem for all versions. That means also that for Emacs 24 I do not need to use the `with-temp-buffer-window.el' code you sent. It is sufficient to use the `add-hook'. Dunno whether that helps you decide something for Emacs 24. Given the info above, do you think that the equivalent of that `add-hook' should perhaps be built into Emacs? IOW, is some code correction in order, to do systematically what the `add-hook' workaround accomplishes? From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 29 15:33:37 2012 Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 19:33:37 +0000 Received: from localhost ([127.0.0.1]:49176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvZFB-0003Gr-5o for submit@debbugs.gnu.org; Sun, 29 Jul 2012 15:33:37 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:35722) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvZF8-0003Gi-21 for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 15:33:35 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6TJQKKp030006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jul 2012 19:26:22 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6TJQJ2d011199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 19:26:20 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6TJQJIE002494; Sun, 29 Jul 2012 14:26:19 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Jul 2012 12:26:19 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Sun, 29 Jul 2012 12:26:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac1trMbBiJLAQy/TRGm2Cz9tNc+gdQAAflbAAAJBeOAAAEHMQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) [off-list]: > I have not been using that `add-hook' in my normal use of > Emacs, but I am going to start doing so now, to see if it has > any negative effects. I'll keep you posted if I find any. No sooner did I try than I ran into problems. Just `C-x 4 f some-file' is enough to see that this (the `add-hook' to redirect focus) is not a fix. After `C-x 4 f some-file', the new frame does not have the input focus - the minibuffer frame has it (so `C-f' etc. do the wrong thing). I think this all goes back to the problem of distinguishing a frame that is popped up only for informational purposes, _during a user interaction/dialog_, from a frame that is popped up with the intention of using its buffer (as the `current-buffer'). IOW, the case that we were trying to solve, whether for the popup showing active processes or the popup showing marked files in Dired, is a case where the frame is popped up only to ask a question in the minibuffer. It is only in that case that the input focus should be directed to the minibuffer. How to distinguish that case, I don't know. But it seems like the invariant should be that whenever the minibuffer is being used for input its frame should have the focus. That is the problem that needs solving, I think: how to ensure that all minibuffer interaction takes place (always) with the minibuffer frame having the input focus. I then tried this, instead: (add-hook 'after-make-frame-functions (lambda (frame) (when (active-minibuffer-window) (redirect-frame-focus frame (window-frame (minibuffer-window)))))) But that is no good because the minibuffer is not active quite yet, at the moment the hook takes effect. It is apparently the case that FIRST the new frame is created and THEN the minibuffer is used/activated. In the *shell* scenario, when I hit `C-x C-c' and try to type "no", the `n' invokes `View-search-last-regexp-forward' - I get this: Signaling: (error "No previous View-mode search") signal(error ("No previous View-mode search")) error("No previous View-mode search") view-search(1 nil) View-search-last-regexp-forward(1) call-interactively(View-search-last-regexp-forward) yes-or-no-p("Active processes exist; kill them and exit anyway? ") save-buffers-kill-emacs(nil) call-interactively(save-buffers-kill-emacs) That is with Emacs 20, where buffer *Process List* is in View mode, where `n' is bound to `View-search-last-regexp-forward'. In Emacs 24.1, I don't get the error, but the behavior is similar (the `n' is typed into frame *Process List*, not into the minibuffer frame). I also tried this: (add-hook 'minibuffer-setup-hook (lambda () (unless (eq (selected-frame) (window-frame (minibuffer-window))) (redirect-frame-focus (selected-frame) (window-frame (minibuffer-window)))))) But that had the same effect: the `n' of "no" went to the *Process List* frame. And I added a call to `message' before the `unless', to see what (selected-frame) was. And I was surprised to see that it was in fact the minibuffer frame (so the `unless' became a no-op) So it seems that the minibuffer frame was selected, but did not receive input (did not have the focus). I then got rid of the `unless' guard, and just redirected systematically, in `minibuffer-setup-hook', and I still got the same behavior (the typed `n' went to the *Process List* frame). Clearly, that just redirected the minibuffer frame (the selected frame) to itself, whereas what is needed is to redirect the newly created *Process List* frame's focus to the minibuffer frame. Finally, knowing that the selected frame is the minibuffer frame, but it does not have the focus, I tried this: (add-hook 'after-make-frame-functions (lambda (frame) (when (eq (selected-frame) (window-frame (minibuffer-window))) (redirect-frame-focus frame (window-frame (minibuffer-window)))))) And that solves the problem. IOW, that does just as much good as the systematic redirection (i.e., without the `when') did, but it does not have the drawback that each time a frame is popped up it loses the focust to the minibuffer frame. (The only remaining problem is the other one we discussed, regarding the value of (current-buffer) after the minibuffer is exited, so that a subsequent `C-x k' has " *Minibuf-0*" as the default buffer name.) That's the best thing I've come up with, but perhaps you have a suggestion. `after-make-frame-functions' seems like the right place to do the deed, because it knows about the new frame, which is the one whose focus needs to be redirected. Again, this all seems to underline the need for a notion/mechanism of defining or detecting a user dialog that uses the minibuffer while popping up an informational frame only for the duration of the minibuffer interaction (input). Anyway, I will use that code (the last above) for a while, to see how it goes. Hope this info helps a bit. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 30 05:20:21 2012 Received: (at 11939) by debbugs.gnu.org; 30 Jul 2012 09:20:21 +0000 Received: from localhost ([127.0.0.1]:49975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Svm9E-0000sj-Ln for submit@debbugs.gnu.org; Mon, 30 Jul 2012 05:20:21 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:56049) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Svm9C-0000sb-7i for 11939@debbugs.gnu.org; Mon, 30 Jul 2012 05:20:19 -0400 Received: (qmail invoked by alias); 30 Jul 2012 09:13:04 -0000 Received: from 62-47-32-67.adsl.highway.telekom.at (EHLO [62.47.32.67]) [62.47.32.67] by mail.gmx.net (mp037) with SMTP; 30 Jul 2012 11:13:04 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19C2aVqf05Cyfwv1z4c7QLE3YLX0bI2GLhYB0uCOf 9fju2gcoyDbF7u Message-ID: <50165031.50905@gmx.at> Date: Mon, 30 Jul 2012 11:13:21 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' References: <500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> <501540D0.50900@gmx.at> <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> <50156DFE.6090807@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Here's the (current) issue and scenario. It uses my setup (with untweaked > oneonone.el but also with the other libraries that I use). The only thing I've > done differently than usual is to evaluate this sexp: > > (add-hook 'after-make-frame-functions > (lambda (frame) > (redirect-frame-focus frame > (window-frame (minibuffer-window))))) > > I do M-x shell. > Then I do C-x C-c. > > The `yes-or-no-p' prompt about active processes appears in the minibuffer. I > type "no" into the minibuffer. > > So far so good. Things are perfectly normal now, and I am at top level (the > minibuffer has exited normally). > > I then do C-x k. > > Because my setup automatically inserts the default value (what `M-n' gives), What does M-n do? > that buffer-name value is inserted in the minibuffer, waiting for me to hit RET > to accept it or to edit it and then hit RET. > > The default buffer name in this case is " *Minibuf-0*". That is what I have > never seen before. I.e., without adding that `add-hook' sexp (above), I do not > get this behavior. I understand. Then we have to look at the command M-n is bound to. > But I am not in any way trapped in the minibuffer. I can edit the buffer name > to kill the buffer I want. Or I can hit C-g. And so on. But, apparently, whatever you do, the current buffer is still *Minibuf-0*. > The only problem is that the value of `(current-buffer)' is " *Minibuf-0*" at > that point. I know that by testing with `message' etc. That is why I > hypothesized that something in that frame focus redirection caused the buffer " > *Minibuf-0*" to become selected, i.e., the `current-buffer'. > > But you corrected me, pointing out that `yes-or-no-p' does that: it selects the > minibuffer window/buffer. Let me try to correct this again: `yes-or-no-p' selects the minibuffer window. `redirect-frame-focus' does not select any window. I don't know how this is related to your problem. > If I do not do the `add-hook', then I cannot type yes/no to the `yes-or-no-p' > prompt, without first manually selecting the minibuffer frame (e.g. by clicking > its titlebar). And if I do that then the symptoms are the same as when I use > the `add-hook': after typing "no", if I use C-x k then " *Minibuf-0*" is the > default buffer to kill. ... where C-x k is not bound to `kill-buffer' but to another function ... > But if (I do not do the `add-hook' and) I do `M-: (yes-or-no-p "Foo? ")' and I > answer "no", then `C-x k' uses another buffer (the one selected before the M-:) > as the default value. I am not sure why this difference, i.e., why > `yes-or-no-p' does not leave " *Minibuf-0*" as the current buffer in this case. > But it probably has to do with the execution of command `M-:' - IOW, in that > test it is not just `yes-or-no-p' that is involved, but also `M-:'. `eval-expression' does consider the minibuffer window selected when it's called from within the minibuffer. Doing C-h f and then C-: (selected-window) RET will print the minibuffer window. > So perhaps this is only a problem with (because of) `yes-or-no-p'. And perhaps > there is nothing that can (or should?) be done about it. It is anyway a minor > problem compared to the general problem that this bug report is about: loss of > focus to the minibuffer frame. > > I hope we are now clear about this `C-x k' default-buffer problem. Dunno what > can or should be done about it. It seems (to me, so far) to be a problem with > `yes-or-no-p' (and perhaps some other functions?): > > In order to ask its question, `yes-or-no-p' not only redirects input focus to > the minibuffer but it also (apparently) selects the minibuffer's buffer. And it > apparently leaves that buffer selected, as the `current-buffer'. > > You know better than I what, if anything could/should be done to correct this. > Should `yes-or-no-p' use `with-current-buffer' or something, so that it finishes > by selecting again the buffer that was selected when it started? I'm guessing > yes, but I know nothing about the code. It seems wrong that it should change > the selected buffer to the minibuffer and leave it so changed. The code that does the selection and the restoration is in read_minibuf which `yes-or-no-p' calls. As explained earlier, I don't understand that code well enough in order to tell what to change. > The above behavior description holds for all Emacs versions I have. The > `add-hook' solves the unfocused minibuffer frame problem for all versions. > > That means also that for Emacs 24 I do not need to use the > `with-temp-buffer-window.el' code you sent. It is sufficient to use the > `add-hook'. Dunno whether that helps you decide something for Emacs 24. The code has to work without any additional setup. > Given the info above, do you think that the equivalent of that `add-hook' should > perhaps be built into Emacs? IOW, is some code correction in order, to do > systematically what the `add-hook' workaround accomplishes? I don't know, unfortunately. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 30 05:20:26 2012 Received: (at 11939) by debbugs.gnu.org; 30 Jul 2012 09:20:26 +0000 Received: from localhost ([127.0.0.1]:49978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Svm9K-0000t0-5w for submit@debbugs.gnu.org; Mon, 30 Jul 2012 05:20:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:38099) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Svm9G-0000sq-Ay for 11939@debbugs.gnu.org; Mon, 30 Jul 2012 05:20:24 -0400 Received: (qmail invoked by alias); 30 Jul 2012 09:13:08 -0000 Received: from 62-47-32-67.adsl.highway.telekom.at (EHLO [62.47.32.67]) [62.47.32.67] by mail.gmx.net (mp032) with SMTP; 30 Jul 2012 11:13:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX185AzBcU0E5y5NeqviOhf2DHsv6Y8Jiy9l57wJh3x Tdx6JR8wgjNTHI Message-ID: <50165035.4090401@gmx.at> Date: Mon, 30 Jul 2012 11:13:25 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Just `C-x 4 f some-file' is enough to see that this (the `add-hook' to redirect > focus) is not a fix. After `C-x 4 f some-file', the new frame does not have the > input focus - the minibuffer frame has it (so `C-f' etc. do the wrong thing). > > I think this all goes back to the problem of distinguishing a frame that is > popped up only for informational purposes, _during a user interaction/dialog_, > from a frame that is popped up with the intention of using its buffer (as the > `current-buffer'). Yes. > IOW, the case that we were trying to solve, whether for the popup showing active > processes or the popup showing marked files in Dired, is a case where the frame > is popped up only to ask a question in the minibuffer. It is only in that case > that the input focus should be directed to the minibuffer. > > How to distinguish that case, I don't know. But it seems like the invariant > should be that whenever the minibuffer is being used for input its frame should > have the focus. I don't believe the underlying mechanism for popping up frames ever will have the necessary knowledge to decide. > That is the problem that needs solving, I think: how to ensure that all > minibuffer interaction takes place (always) with the minibuffer frame having the > input focus. > > I then tried this, instead: > > (add-hook 'after-make-frame-functions > (lambda (frame) > (when (active-minibuffer-window) > (redirect-frame-focus frame > (window-frame (minibuffer-window)))))) > > But that is no good because the minibuffer is not active quite yet, at the > moment the hook takes effect. It is apparently the case that FIRST the new > frame is created and THEN the minibuffer is used/activated. Indeed. > I also tried this: > > (add-hook 'minibuffer-setup-hook > (lambda () > (unless (eq (selected-frame) > (window-frame (minibuffer-window))) > (redirect-frame-focus (selected-frame) > (window-frame (minibuffer-window)))))) > > But that had the same effect: the `n' of "no" went to the *Process List* frame. > And I added a call to `message' before the `unless', to see what > (selected-frame) was. And I was surprised to see that it was in fact the > minibuffer frame (so the `unless' became a no-op) So it seems that the > minibuffer frame was selected, but did not receive input (did not have the > focus). Yes. In read_minibuf the Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil); Fselect_window (minibuf_window, Qnil); comes before Frun_hooks (1, &Qminibuffer_setup_hook); > I then got rid of the `unless' guard, and just redirected systematically, in > `minibuffer-setup-hook', and I still got the same behavior (the typed `n' went > to the *Process List* frame). Clearly, that just redirected the minibuffer > frame (the selected frame) to itself, whereas what is needed is to redirect the > newly created *Process List* frame's focus to the minibuffer frame. > > Finally, knowing that the selected frame is the minibuffer frame, but it does > not have the focus, I tried this: > > (add-hook 'after-make-frame-functions > (lambda (frame) > (when (eq (selected-frame) > (window-frame (minibuffer-window))) > (redirect-frame-focus frame > (window-frame (minibuffer-window)))))) > > And that solves the problem. IOW, that does just as much good as the systematic > redirection (i.e., without the `when') did, but it does not have the drawback > that each time a frame is popped up it loses the focust to the minibuffer frame. Using `selected-frame' within `after-make-frame-functions' seems awfully fragile to me. IMHO this can't ever work reliably. > (The only remaining problem is the other one we discussed, regarding the value > of (current-buffer) after the minibuffer is exited, so that a subsequent `C-x k' > has " *Minibuf-0*" as the default buffer name.) > > That's the best thing I've come up with, but perhaps you have a suggestion. > `after-make-frame-functions' seems like the right place to do the deed, because > it knows about the new frame, which is the one whose focus needs to be > redirected. > > Again, this all seems to underline the need for a notion/mechanism of defining > or detecting a user dialog that uses the minibuffer while popping up an > informational frame only for the duration of the minibuffer interaction (input). > > Anyway, I will use that code (the last above) for a while, to see how it goes. > Hope this info helps a bit. Let's see. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 01 12:42:28 2012 Received: (at 11939) by debbugs.gnu.org; 1 Aug 2012 16:42:28 +0000 Received: from localhost ([127.0.0.1]:55032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Swc0B-0007Jn-Qb for submit@debbugs.gnu.org; Wed, 01 Aug 2012 12:42:28 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:24132) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Swc08-0007JZ-FZ for 11939@debbugs.gnu.org; Wed, 01 Aug 2012 12:42:25 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q71GYrBL031726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 16:34:57 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q71GYpUv017771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 16:34:52 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q71GYpi5008643; Wed, 1 Aug 2012 11:34:51 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Aug 2012 09:34:50 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> <501540D0.50900@gmx.at> <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> <50156DFE.6090807@gmx.at> <50165031.50905@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes' Date: Wed, 1 Aug 2012 09:34:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50165031.50905@gmx.at> Thread-Index: Ac1uM4gj6fbjIjzvTAKWsBJ1byGt1gBy9c2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > What does M-n do? M-n is standard Emacs in the minibuffer: it retrieves (inserts) the default value provided to the minibuffer-reading function (e.g. `completing-read'). (And starting with Emacs 23 you can repeat M-n to cycle among multiple default values.) > > The default buffer name in this case is " *Minibuf-0*". > > That is what I have never seen before. I.e., without adding that > > `add-hook' sexp (above), I do not get this behavior. > > I understand. Then we have to look at the command M-n is bound to. It inserts the default value. In this case, the default value is the value of (current-buffer), as I explained. The problem/mistake is that with the `add-hook' the value of (current-buffer) is now buffer " *Minibuf-0*". > > But I am not in any way trapped in the minibuffer. I can > > edit the buffer name to kill the buffer I want. Or I can hit C-g. > > And so on. > > But, apparently, whatever you do, the current buffer is still > *Minibuf-0*. Yes. (current-buffer) should not be *Minibuf-0*. (But (current-buffer) is only the default value, so I can still use `C-x k' here, by ignoring the default.) > > The only problem is that the value of `(current-buffer)' > > is " *Minibuf-0*" at that point. I know that by testing with > > `message' etc. That is why I hypothesized that something in that > > frame focus redirection caused the buffer " *Minibuf-0*" to become > > selected, i.e., the `current-buffer'. > > > > But you corrected me, pointing out that `yes-or-no-p' does > > that: it selects the minibuffer window/buffer. > > Let me try to correct this again: `yes-or-no-p' selects the minibuffer > window. `redirect-frame-focus' does not select any window. I don't > know how this is related to your problem. That is what I understood. > > If I do not do the `add-hook', then I cannot type yes/no > > to the `yes-or-no-p' prompt, without first manually selecting > > the minibuffer frame (e.g. by clicking its titlebar). And if I do > > that then the symptoms are the same as when I use the `add-hook': > > after typing "no", if I use C-x k then " *Minibuf-0*" is the > > default buffer to kill. > > where C-x k is not bound to `kill-buffer' but to another function Correct. Same scenario, still. > > But if (I do not do the `add-hook' and) I do `M-: > > (yes-or-no-p "Foo? ")' and I answer "no", then `C-x k' uses > > another buffer (the one selected before the M-:) as the default > > value. I am not sure why this difference, i.e., why > > `yes-or-no-p' does not leave " *Minibuf-0*" as the current > > buffer in this case. But it probably has to do with the > > execution of command `M-:' - IOW, in that test it is not just > > `yes-or-no-p' that is involved, but also `M-:'. > > `eval-expression' does consider the minibuffer window selected when > it's called from within the minibuffer. Doing C-h f and then C-: > (selected-window) RET will print the minibuffer window. Right (but M-:, not C-:). > > You know better than I what, if anything could/should be > > done to correct this. Should `yes-or-no-p' use > > `with-current-buffer' or something, so that it finishes > > by selecting again the buffer that was selected when it > > started? I'm guessing yes, but I know nothing about the code. > > It seems wrong that it should change the selected buffer to the > > minibuffer and leave it so changed. > > The code that does the selection and the restoration is in > read_minibuf which `yes-or-no-p' calls. As explained earlier, I don't > understand that code well enough in order to tell what to change. OK. I, even less, obviously. But at any rate, this wrong-buffer problem is minor. I don't want it to sidetrack us too much. The bigger issue is to have code somehow DTRT so that minibuffer interaction that is coupled with the popup of an informational-only window/frame, keeps the focus in the minibuffer frame. IOW, come up with some construct that lets code identify a particular minibuffer interaction as one that should keep the focus in the minibuffer frame. "Keep" here might mean redirect to the minibuffer if something outside Emacs and outside the user moves the focus away from it. And that "outside Emacs and outside the user" would be key, if we could in fact detect it. IOW, Emacs code can only say that some interaction should keep the focus in the minibuffer frame (or not, depending on what's intended). Emacs cannot prevent MS Windows or whatever from changing the focus. And we would want the user to be able to change the focus explicitly (during the minibuffer interaction), of course. > > The above behavior description holds for all Emacs versions I have. > > The `add-hook' solves the unfocused minibuffer frame problem > > for all versions. Again, I was wrong about that (e.g. *Backtrace* case). There are some cases where the minibuffer is active and a frame is popped that is not merely informational but should in fact receive the input focus. > > That means also that for Emacs 24 I do not need to use the > > `with-temp-buffer-window.el' code you sent. It is sufficient to > > use the `add-hook'. Dunno whether that helps you decide something > > for Emacs 24. > > The code has to work without any additional setup. Of course. I meant only that perhaps the equivalent of what I did in the hook might be something to do in general. I'm now backtracking on that because doing that systematically is not the panacea that I thought it might be. > > Given the info above, do you think that the equivalent of > > that `add-hook' should perhaps be built into Emacs? IOW, is some > > code correction in order, to do systematically what the `add-hook' > > workaround accomplishes? > > I don't know, unfortunately. The answer is no, because I said "systematically", and that is not TRT (e.g. *Backtrace*). From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 01 12:42:29 2012 Received: (at 11939) by debbugs.gnu.org; 1 Aug 2012 16:42:29 +0000 Received: from localhost ([127.0.0.1]:55034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Swc0C-0007Jq-Dh for submit@debbugs.gnu.org; Wed, 01 Aug 2012 12:42:29 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:24131) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Swc08-0007JY-FY for 11939@debbugs.gnu.org; Wed, 01 Aug 2012 12:42:26 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q71GYrAv031722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 16:34:57 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q71GYpn5017770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 16:34:52 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q71GYn9i008633; Wed, 1 Aug 2012 11:34:49 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Aug 2012 09:34:48 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org><83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Wed, 1 Aug 2012 09:34:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50165035.4090401@gmx.at> Thread-Index: Ac1uM4u2CWNY1KyITwqj/OY2hGWcqQByKAWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > I think this all goes back to the problem of > > distinguishing a frame that is popped up only for > > informational purposes, _during a user interaction/dialog_, > > from a frame that is popped up with the intention of using > > its buffer (as the `current-buffer'). > > Yes. > > > IOW, the case that we were trying to solve, whether for > > the popup showing active processes or the popup showing > > marked files in Dired, is a case where the frame > > is popped up only to ask a question in the minibuffer. It > > is only in that case that the input focus should be > > directed to the minibuffer. > > > > How to distinguish that case, I don't know. But it seems > > like the invariant should be that whenever the minibuffer > > is being used for input its frame should have the focus. > > I don't believe the underlying mechanism for popping up > frames ever will have the necessary knowledge to decide. Agreed. (I almost want to say "Of course", but I did pose the question.) My contention from the beginning (i.e., before this thread, in other discussions) is that we need an explicit notion of a minibuffer dialog that should keep the focus in the minibuffer, so that code can ensure that popped up frames do not grab the focus away from the minibuffer during the dialog. Or if they do, other than via Emacs code or a user action - e.g. via MS Windows, then they are properly redirected back. In terms of implementation it could perhaps be a `with-*' encapsulation. A given code context DOES know when it is using a popup window (which could thus be a popup frame) only to provide information while asking a minibuffer question, and it can wrap the minibuffer interaction and frame creation in such an encapsulation. The encapsulation would redirect any new frames created to the minibuffer for the duration. But it would need to allow Emacs code within it the possibility of redirecting the focus (even using a recursive minibuffer invocation that is, itself, not so encapsulated?). And it would of course need to allow the user to explicitly change the focus. IOW, it would handle new informational frames the way a standalong *Completions* frame is handled: when it is displayed its focus is redirected to the minibuffer frame, but that does not prevent Emacs code or the user from switching the focus to it during minibuffer activity. See the code I sent for my *Completions* frame for an example. It does this when it displays *Completions* (the selected-frame): (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame) > > That is the problem that needs solving, I think: how to > > ensure that all minibuffer interaction takes place (always) > > with the minibuffer frame having the > > input focus. No, I was wrong about that "(always)" - see below. > > I also tried this: > > > > (add-hook 'minibuffer-setup-hook > > (lambda () > > (unless (eq (selected-frame) > > (window-frame (minibuffer-window))) > > (redirect-frame-focus (selected-frame) > > (window-frame (minibuffer-window)))))) > > > > But that had the same effect: the `n' of "no" went to the > > *Process List* frame. And I added a call to `message' > > before the `unless', to see what (selected-frame) was. > > And I was surprised to see that it was in fact the > > minibuffer frame (so the `unless' became a no-op) So it > > seems that the minibuffer frame was selected, but did not > > receive input (did not have the focus). > > Yes. In read_minibuf the > > Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil); > Fselect_window (minibuf_window, Qnil); > > comes before > > Frun_hooks (1, &Qminibuffer_setup_hook); > > > Finally, knowing that the selected frame is the minibuffer > > frame, but it does not have the focus, I tried this: > > > > (add-hook 'after-make-frame-functions > > (lambda (frame) > > (when (eq (selected-frame) > > (window-frame (minibuffer-window))) > > (redirect-frame-focus frame > > (window-frame (minibuffer-window)))))) > > > > And that solves the problem. IOW, that does just as much > > good as the systematic redirection (i.e., without the > > `when') did, but it does not have the drawback > > that each time a frame is popped up it loses the focus to > > the minibuffer frame. > > Using `selected-frame' within `after-make-frame-functions' > seems awfully fragile to me. IMHO this can't ever work reliably. I cannot speak to that; you're the expert here. But do you have a counter-example, just for the sake of concreteness? (Not important, just wondering.) > > (The only remaining problem is the other one we discussed, > > regarding the value of (current-buffer) after the > > minibuffer is exited, so that a subsequent `C-x k' > > has " *Minibuf-0*" as the default buffer name.) > > > > That's the best thing I've come up with, but perhaps you > > have a suggestion. `after-make-frame-functions' seems > > like the right place to do the deed, because it knows > > about the new frame, which is the one whose focus needs > > to be redirected. I want to say "ONLY IT knows..." (among existing hooks), but I am not sure of that. IOW, of the hooks I am aware of, this one seems the most pertinent here. > > Again, this all seems to underline the need for a > > notion/mechanism of defining or detecting a user dialog I think you are probably right that "detecting" might be a pipe dream. What I really have had in mind is mentioned above: the code would encapsulate a minibuffer reading that might pop up an informational window, redirecting focus for any new frames to the minibuffer. > > that uses the minibuffer while popping up an informational > > frame only for the duration of the minibuffer interaction > > (input). The important point here is "informational...only". And this is where I need to mention an example of why it is not a solution to do this redirection systematically, testing only (when (eq (selected-frame) (window-frame (minibuffer-window))). A case in point is the debugger. In my setup *Backtrace* pops up in a special-display frame. It is not the case that this buffer is for information only. It is truly necessary that *Backtrace* receive the focus. So this is a good case where my redirection "fix" does not do the right thing. > > Anyway, I will use that code (the last above) for a while, > > to see how it goes. See previous. I was mistaken in supposing that doing this systematically would DTRT. There are clearly some cases where a frame is popped up during minibuffer input, and that frame is NOT only for informational purposes but should in fact receive the input focus. It is only the code that invokes reading from the minibuffer and pops up the other window/frame that can know whether the focus should be in that window/frame or in the minibuffer. But here's the thing: in the case of windows instead of frames, Emacs DTRT, no? Emacs distinguishes the case of window *Process List* from window *Backtrace*, giving the focus to the latter and not to the former. Why can't we make Emacs DTRT for frames, just as it does for windows? I know that MS Windows altering the focus throws a monkey wrench into the mix, but surely we can find some way to KEEP the focus (i.e. re-focus if necessary) where Emacs put it (correctly). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 03 06:48:34 2012 Received: (at 11939) by debbugs.gnu.org; 3 Aug 2012 10:48:34 +0000 Received: from localhost ([127.0.0.1]:58350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxFQn-0003sK-EK for submit@debbugs.gnu.org; Fri, 03 Aug 2012 06:48:34 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:36166) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SxFQi-0003sA-Re for 11939@debbugs.gnu.org; Fri, 03 Aug 2012 06:48:31 -0400 Received: (qmail invoked by alias); 03 Aug 2012 10:40:51 -0000 Received: from 62-47-42-92.adsl.highway.telekom.at (EHLO [62.47.42.92]) [62.47.42.92] by mail.gmx.net (mp029) with SMTP; 03 Aug 2012 12:40:51 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19WqcwzbkxWdWquI6+XO8S0MeimKthBMVRXk4ytUz dz4949WcFdw/2Z Message-ID: <501BAAB0.1020807@gmx.at> Date: Fri, 03 Aug 2012 12:40:48 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > My contention from the beginning (i.e., before this thread, in other > discussions) is that we need an explicit notion of a minibuffer dialog that > should keep the focus in the minibuffer, so that code can ensure that popped up > frames do not grab the focus away from the minibuffer during the dialog. Or if > they do, other than via Emacs code or a user action - e.g. via MS Windows, then > they are properly redirected back. > > In terms of implementation it could perhaps be a `with-*' > encapsulation. A given code context DOES know when it is using a popup window > (which could thus be a popup frame) only to provide information while asking a > minibuffer question, and it can wrap the minibuffer interaction and frame > creation in such an encapsulation. > > The encapsulation would redirect any new frames created to the minibuffer for > the duration. But it would need to allow Emacs code within it the possibility > of redirecting the focus (even using a recursive minibuffer invocation that is, > itself, not so encapsulated?). And it would of course need to allow the user to > explicitly change the focus. > > IOW, it would handle new informational frames the way a standalong *Completions* > frame is handled: when it is displayed its focus is redirected to the minibuffer > frame, but that does not prevent Emacs code or the user from switching the focus > to it during minibuffer activity. > > See the code I sent for my *Completions* frame for an example. It does this > when it displays *Completions* (the selected-frame): > (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame) What you request here is trivial. read_minibuf has this statement if (!EQ (mini_frame, selected_frame)) Fredirect_frame_focus (selected_frame, mini_frame); so if the new frame is already selected when this statement is executed, reading from the minibuffer works out of the box as in my `with-temp-buffer-window.el' and your *Completions* code examples. The problem happens in the following scenario: (1) The application requests (implicitly) to make a new frame. (2) The application ask to read from the minibuffer with some old frame selected. In this case the statement above does not redirect focus because either the old frame is the minibuffer frame or the old frame's focus is already redirected to the minibuffer frame. (3) Emacs eventually selects the new frame in `handle-switch-frame'. After that, the new frame gets the keystrokes for reading from the minibuffer but Emacs won't find a redirection in kbd_buffer_get_event. >> > Finally, knowing that the selected frame is the minibuffer >> > frame, but it does not have the focus, I tried this: >> > >> > (add-hook 'after-make-frame-functions >> > (lambda (frame) >> > (when (eq (selected-frame) >> > (window-frame (minibuffer-window))) >> > (redirect-frame-focus frame >> > (window-frame (minibuffer-window)))))) >> > >> > And that solves the problem. IOW, that does just as much >> > good as the systematic redirection (i.e., without the >> > `when') did, but it does not have the drawback >> > that each time a frame is popped up it loses the focus to >> > the minibuffer frame. >> >> Using `selected-frame' within `after-make-frame-functions' >> seems awfully fragile to me. IMHO this can't ever work reliably. > > I cannot speak to that; you're the expert here. But do you have a > counter-example, just for the sake of concreteness? (Not important, just > wondering.) No and I am no expert here. In any case the idea of doing >> > (when (eq (selected-frame) >> > (window-frame (minibuffer-window))) means that when you pop up a new frame when a non-minibuffer frame is selected you never redirect, while you always redirect when the minibuffer frame is selected. This conditioning cannot always work correctly IMHO. >> > That's the best thing I've come up with, but perhaps you >> > have a suggestion. `after-make-frame-functions' seems >> > like the right place to do the deed, because it knows >> > about the new frame, which is the one whose focus needs >> > to be redirected. > > I want to say "ONLY IT knows..." (among existing hooks), but I am not sure of > that. IOW, of the hooks I am aware of, this one seems the most pertinent here. It knows that a new frame will be constructed. But it does not know whether focus shall be redirected. >> > Again, this all seems to underline the need for a >> > notion/mechanism of defining or detecting a user dialog > > I think you are probably right that "detecting" might be a pipe dream. What I > really have had in mind is mentioned above: the code would encapsulate a > minibuffer reading that might pop up an informational window, redirecting focus > for any new frames to the minibuffer. And what you have in mind here should be distinguishable from other things that pop up frames but do not want the redirection. >> > that uses the minibuffer while popping up an informational >> > frame only for the duration of the minibuffer interaction >> > (input). > > The important point here is "informational...only". > > And this is where I need to mention an example of why it is not a solution to do > this redirection systematically, testing only > (when (eq (selected-frame) (window-frame (minibuffer-window))). > > A case in point is the debugger. In my setup *Backtrace* pops up in a > special-display frame. It is not the case that this buffer is for information > only. It is truly necessary that *Backtrace* receive the focus. Is it? I never gave it a thought. But I perfectly understand that when *Backtrace* pops up you don't want to redirect focus to the minibuffer frame. > So this is a > good case where my redirection "fix" does not do the right thing. If you hardwire redirection in `after-make-frame-functions', you get bad results in the case where the redirection is not wanted. What you want is some clairvoyance in step (1) of my description above whether step (2) will be performed. `with-temp-buffer-window' avoids that by asking the `yes-or-no-p' question in the new frame. Older application don't and that's our trouble. >> > Anyway, I will use that code (the last above) for a while, >> > to see how it goes. > > See previous. I was mistaken in supposing that doing this systematically would > DTRT. There are clearly some cases where a frame is popped up during minibuffer > input, and that frame is NOT only for informational purposes but should in fact > receive the input focus. > > It is only the code that invokes reading from the minibuffer and pops up the > other window/frame that can know whether the focus should be in that > window/frame or in the minibuffer. It's not that simple. The invoking code doesn't care about focus and in particular not about some frame whose eventually popping up will cause problems. It expects the reading from the minibuffer mechanism DTRT. > But here's the thing: in the case of windows instead of frames, Emacs DTRT, no? > Emacs distinguishes the case of window *Process List* from window *Backtrace*, > giving the focus to the latter and not to the former. Why can't we make Emacs > DTRT for frames, just as it does for windows? For windows on the same frame we can differ between `display-buffer' and `pop-to-buffer'. For windows on different frames we have the complication that the `handle-switch-frame' event triggered by the OS causes Emacs to select that frame, that is, implicitly replace `display-buffer' by `pop-to-buffer'. > I know that MS Windows altering the focus throws a monkey wrench into the mix, > but surely we can find some way to KEEP the focus (i.e. re-focus if necessary) > where Emacs put it (correctly). As far as old code is concerned you probably are overly optimistic. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 03 12:54:44 2012 Received: (at 11939) by debbugs.gnu.org; 3 Aug 2012 16:54:44 +0000 Received: from localhost ([127.0.0.1]:59673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxL99-0005hn-Hp for submit@debbugs.gnu.org; Fri, 03 Aug 2012 12:54:44 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:27652) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxL95-0005ha-8L for 11939@debbugs.gnu.org; Fri, 03 Aug 2012 12:54:41 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q73Gl0sU029462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Aug 2012 16:47:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q73GkxdJ008666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 16:47:00 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q73GkwKe031455; Fri, 3 Aug 2012 11:46:58 -0500 Received: from dradamslap1 (/10.159.171.30) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Aug 2012 09:46:58 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Fri, 3 Aug 2012 09:46:53 -0700 Message-ID: <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1xZHUqYzw1+y7KTxmQqSUc3/iQOwAH2Mhw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <501BAAB0.1020807@gmx.at> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > The problem happens in the following scenario: > > (1) The application requests (implicitly) to make a new frame. > > (2) The application ask to read from the minibuffer with some > old frame selected. In this case the statement above does not > redirect focus because either the old frame is the minibuffer > frame or the old frame's focus is already redirected to the > minibuffer frame. > > (3) Emacs eventually selects the new frame in `handle-switch-frame'. > > After that, the new frame gets the keystrokes for reading from the > minibuffer but Emacs won't find a redirection in kbd_buffer_get_event. Agreed; that is what we have been discussing. > the idea of doing > (when (eq (selected-frame) > (window-frame (minibuffer-window))) > > means that when you pop up a new frame when a non-minibuffer frame is > selected you never redirect, while you always redirect when the > minibuffer frame is selected. This conditioning cannot always work > correctly IMHO. Which is what I said in my last message. It must not be done systematically. I gave the counter-example of a *Backtrace* frame. It is only the code that is calling for such a user dialog that knows that that is what is being called for. By "such a user dialog", again, I mean (a) the display of a buffer for information only, i.e., one that does not need the input focus, and (b) request of user input with the previous buffer remaining current and the minibuffer having the input focus. That is the use case that is problematic. It is the case where the above systematic "fix" is inappropriate. There might be other such use cases, but it is the only one I have encountered. And I have encountered it in several different places (e.g., Dired *Marked Files* popup, *Process List* popup). My suggestion is, again, that we try to come up with a construct that covers this use case, and then use it in the appropriate places: places where we do (a) + (b). On the other hand, if you know of a way to _detect_ such an intention on the part of the developer, i.e., somehow _detect_ whether the displayed buffer should have input focus, then I'm all ears. I don't expect that to be possible, which is why I propose that the developer make the intention explicit by using a new construct (e.g. a macro) that takes care of this. The construct would display the informational buffer and redirect its input focus to a standalone minibuffer, if there is one. If there is no standalone minibuffer frame, then that part could be a no-op, AFAICT. Something like this: (with-unfocused-buffer-displayed BUFFER &body BODY) where BUFFER is displayed for information only, and where BODY would include the call(s) that read from the minibuffer. The current buffer would remain what it was beforehand, and _if_ BUFFER gets displayed in its own frame and _if_ there is a standalone minibuffer frame, _then_ the focus for BUFFER's frame gets automatically redirected to the minibuffer frame. If those conditions do not hold then there is no special handling needed - the construct can essentially be a no-op in that case (AFAICT). How something like this would be implemented I'm not sure. When the redirection would need to take place, to DTRT, I'm not sure. Perhaps it would need to be done more than once. But an important further requirement is that nothing should prevent Emacs code in BODY or called from within BODY from switching the input focus to BUFFER's frame. Likewise, nothing should prevent the user from explicitly switching the focus to BUFFER's frame. The only switching of focus to BUFFER's frame that this construct would be trying to prevent would be something that comes from neither a user action nor the Emacs code - in particular, MS Windows auto-focussing a newly created frame. Again, I don't know the "how". But (so far) I'm convinced that this has to be an explicit Emacs construct: there needs to be some way for a Lisp programmer to communicate the intention that BUFFER is not intended to have the input focus during BODY (unless that is done by the user or by code within BODY). I do not expect that the problematic use case we've been discussing can be detected and dealt with correctly in an automatic way. If the programmer intention cannot be made explicit then there is no way to know what TRT is. It's problematic enough even with the intention communicated, in the sense that we need to allow users and Emacs code to give focus to BUFFER's frame if they want to. IOW, even if we _know_ that initially BUFFER's frame should not be focused, it is hard enough to prevent or undo focusing by MS Windows while still allowing users and Emacs to focus BUFFER. > >> > That's the best thing I've come up with, but perhaps you > >> > have a suggestion. `after-make-frame-functions' seems > >> > like the right place to do the deed, because it knows > >> > about the new frame, which is the one whose focus needs > >> > to be redirected. > > > > I want to say "ONLY IT knows..." (among existing hooks), but I am not > > sure of that. IOW, of the hooks I am aware of, this one seems the > > most pertinent here. > > It knows that a new frame will be constructed. But it does not know > whether focus shall be redirected. That's the point of providing programmers with a construct to express that intention explicitly: "This buffer's frame, if it is displayed in its own frame, should not receive the focus." > >> > Again, this all seems to underline the need for a > >> > notion/mechanism of defining or detecting a user dialog > > > > I think you are probably right that "detecting" might be a > > pipe dream. What I really have had in mind is mentioned above: > > the code would encapsulate a minibuffer reading that might > > pop up an informational window, By "might pop up" I meant that _if_ informational BUFFER is popped up in its own frame, _then_ the intention is that that frame not receive the input focus. > > redirecting focus for any new frames to the minibuffer. > > And what you have in mind here should be distinguishable from other > things that pop up frames but do not want the redirection. Not sure I follow you. Are you referring to the equivalent of possibly nested `with-unfocused-buffer-displayed' calls? Here's the thing. I don't know whether we can come up with something that is 100% reliable. But the important thing, I think, is to have _some_ programmatic translation of the programmer intention that this BUFFER be shown without giving it the input focus. Today there is no way for a programmer to indicate that. S?he might not _expect_ that the focus would be grabbed away from a minibuffer frame and given to a new frame, but that lack of expectation today is mainly based on inexperience with a standalone minibuffer and MS Windows. What's needed is some way to reinforce the programmer's natural expectation that the user can in fact type input into the minibuffer even when the informational buffer gets displayed. No one would naturally expect that not to be the case, but it can be the case, unfortunately. So the idea is to somehow support the natural expectation and take away the possibility (or reduce the probability) of MS Windows interfering with what should be a simple user dialog. > >> > that uses the minibuffer while popping up an informational > >> > frame only for the duration of the minibuffer interaction > >> > (input). > > > > The important point here is "informational...only". > > > > And this is where I need to mention an example of why it > > is not a solution to do this redirection systematically, testing only > > (when (eq (selected-frame) (window-frame (minibuffer-window))). > > > > A case in point is the debugger. In my setup *Backtrace* > > pops up in a special-display frame. It is not the case that this > > buffer is for information only. It is truly necessary that > > *Backtrace* receive the focus. > > Is it? I never gave it a thought. Yes, it seems to be necessary. The proof being that when I applied my partly misguided "fix" systematically the *Backtrace* frame lost the focus to the minibuffer frame and I could not use it. I had to click the *Backtrace* frame to give it back the focus. > But I perfectly understand that when *Backtrace* pops up you > don't want to redirect focus to the minibuffer frame. Correct. *Backtrace* is not popped up for info only. It is popped up for interacting with the user. It is supposed to have the input focus, even if it is popped during a minibuffer interaction. Note that this is not really an example of what I meant above by Emacs code within BODY being able to switch focus to BUFFER, because *Backtrace* would not be invoked using `with-unfocused-buffer-displayed'. It is not the intention that it be displayed for info only. But it is an example of why systematically redirecting the focus to the minibuffer frame from any new frame that pops up when the minibuffer is active is not TRT. > > So this is a good case where my redirection "fix" does not do > > the right thing. > > If you hardwire redirection in `after-make-frame-functions', > you get bad results in the case where the redirection is not wanted. Correct. That is what I was saying too. Systematic or hard-wire is not appropriate. The first lesson (for me) was learning that it can only be appropriate when the minibuffer is active. The second lesson was that even when the minibuffer is active it might not be appropriate. In the end, it is only the programmer who knows whether some buffer that is popped up should be denied the input focus. > What you want is some clairvoyance in step (1) of my description > above whether step (2) will be performed. No, I don't think so. I don't believe in such clairvoyance (but I'm open to being convinced). Instead, I believe in the programmer stating that the buffer is not intended to have the focus. (But that nothing should prevent Emacs or the user from giving it the focus at some point.) > `with-temp-buffer-window' avoids that by asking the `yes-or-no-p' > question in the new frame. The issue at stake is the case of a standalone minibuffer. I don't see any problem if there is no standalone minibuffer frame. With a standalone minibuffer frame, the proper behavior is for the minibuffer frame to be used for all minibuffer activity. Anything else is less than desirable, even if it might be acceptable if no better solution could be found in some case. A user of a standalone minibuffer looks there for all echo-area output and all minibuffer input. That is one of the reasons for using a standalone minibuffer: a single place where all Q & A with the user takes place. Well, nearly all. Yes, there are some times where things like `read-event' are used instead of the minibuffer. But let's not get pedantic; this is about use of the minibuffer and echo area. A standalone minibuffer offers the advantage of always looking to the same place on the screen for user I/O. > Older application don't and that's our trouble. That's one problem. Admittedly, that can be looked at as a nice-to-have, and I might be the only person who cares much about that. The other potential trouble is the need to show an informational buffer that does not necessarily correspond to what you have defined for `with-temp-buffer-window'. To be clear, I do not know whether such a need exists much in practice. But it looks to me like your macro and the related code you sent make additional assumptions about the buffer that is popped up that constrain it more than what I was describing abstractly for the hypothetical `with-unfocused-buffer-displayed'. The buffer in the case of `with-temp-buffer-window' starts out from scratch (it must be empty), etc. In a nutshell, your construct assumes that the buffer itself is temporary, whereas the only real need for our problematic use case is that the buffer's _display_, in a separate frame, be temporary. IOW, I think your solution is more constraining/limited and doesn't really address the general problem, which is that of displaying _any_ buffer for only informational use (at least initially, allowing for user/code to intentionally switch focus to it). And AFAIK the problem we are trying to solve occurs only when such a buffer appears in its own frame. Your solution certainly helps for things like *Process List* and *Marked Files*. But the characterization of the problem is, logically, in terms of a buffer that is displayed temporarily during a minibuffer dialog, in its own frame, and whose frame should not have the input focus in that context. Am I wrong about that? Don't get me wrong. I think your code (the little that I've tried using it) is a definite improvement for the problem cases we've actually encountered, which are in fact not only temporary displays of a buffer but also displays of a temporary buffer. I'm just saying that I think the problem of MS Windows giving the focus to a new frame that gets popped during a minibuffer interaction, where that new frame should not have the focus, i.e., where its buffer is shown only for information, is more general than the show-a-temporary-buffer case you have treated. At least that's what I think so far. You'll tell me if I'm wrong. > > It is only the code that invokes reading from the minibuffer > > and pops up the other window/frame that can know whether the > > focus should be in that window/frame or in the minibuffer. > > It's not that simple. The invoking code doesn't care about focus It does care. Maybe what you mean is that it does not expect the focus to be messed with by MS Windows. Typically, such code simply does not expect (take into account) a scenario where the user (a) has a standalone minibuffer frame, (b) has the buffer in question be popped up in its own frame, and (c) is on MS Windows, which steals the input focus and gives it to the new frame. But the code does expect the minibuffer to have the focus, and it knows that the buffer is shown only for informational purposes, i.e., the buffer does not need (and should not have) the input focus. The code does not, today, explicitly express that intention/care, because outside of the problematic case of (a), (b), and (c), which today is not that common, there is no need to express and handle that intention. IOW it cares, but its cares are already taken care of automatically in most cases. > and in particular not about some frame whose eventually popping > up will cause problems. It expects the reading from the minibuffer > mechanism DTRT. Precisely. And except for the problematic case, there has never been any need for the programmer to make clear the fact (intention) that the buffer is informational only. You have encapsulated precisely that intention in your code. But you have gone beyond that and expressed the additional intention that the buffer be temporary. That's fine, but it is less general: there are (at least logically) problematic cases that it does not solve, namely, popping up an existing, non-temporary buffer temporarily during a minibuffer query of the user. > > But here's the thing: in the case of windows instead of > > frames, Emacs DTRT, no? Emacs distinguishes the case of > > window *Process List* from window *Backtrace*, > > giving the focus to the latter and not to the former. Why > > can't we make Emacs DTRT for frames, just as it does for windows? And your code in fact does make the distinction between *Process List* and *Backtrace*, which proves my point here. But your code makes the distinction based on *Process List* being a temporary buffer (which it is), and not on it being a buffer that is displayed temporarily in its own frame. The latter distinction is I think the right one, and which would be good to handle. That is where MS Windows's automatic focusing leads to a problem. The problematic case is (a) standalone minibuffer (b) popped-up buffer in its own frame, (c) that frame being new, and (d) the OS giving the new frame the input focus. > For windows on the same frame we can differ between > `display-buffer' and `pop-to-buffer'. For windows on different > frames we have the complication that the `handle-switch-frame' > event triggered by the OS causes Emacs to select that frame, > that is, implicitly replace `display-buffer' by `pop-to-buffer'. Yes, that is one way to put it. > > I know that MS Windows altering the focus throws a monkey > > wrench into the mix, but surely we can find some way to KEEP > > the focus (i.e. re-focus if necessary) where Emacs put it > > (correctly). > > As far as old code is concerned you probably are overly optimistic. OK, let's say that that is a nice-to-have, and move on. The first step is your code, which handles a subset of the problematic cases for new Emacs releases. Very good. The second step, I think, would be something similar, but not limited to temporary buffers. Some way for a programmer to express the intention of displaying a buffer (temporary or not) only for informational purposes during a minibuffer interaction. And I think that for that more general case, there is a problem to be handled only when (a) there is a standalone minibuffer frame, (b) the buffer is popped up in its own frame. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 03 13:08:06 2012 Received: (at 11939) by debbugs.gnu.org; 3 Aug 2012 17:08:06 +0000 Received: from localhost ([127.0.0.1]:59687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxLM4-00060n-Qp for submit@debbugs.gnu.org; Fri, 03 Aug 2012 13:08:05 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:36080) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxLM1-00060N-Mi for 11939@debbugs.gnu.org; Fri, 03 Aug 2012 13:08:02 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q73H0MPY014598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Aug 2012 17:00:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q73H0LB3007573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 17:00:21 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q73H0K1S013869; Fri, 3 Aug 2012 12:00:20 -0500 Received: from dradamslap1 (/10.159.171.30) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Aug 2012 10:00:20 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' Date: Fri, 3 Aug 2012 10:00:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1xZHUqYzw1+y7KTxmQqSUc3/iQOwAH2MhwAAUqxdA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Martin, I tried loading your code in Emacs 24.1 from my .emacs. Please remind me - was it supposed to work with Emacs 24.1 or just with later builds? Anyway, with 24.1 I immediately ran into this problem: `q' in *Help* did not remove the frame. It just substituted the previously current buffer in that frame. IOW, the *Help* frame is apparently no longer special-display as it should be. HTH. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 04 09:52:51 2012 Received: (at 11939) by debbugs.gnu.org; 4 Aug 2012 13:52:51 +0000 Received: from localhost ([127.0.0.1]:60995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sxemf-00028I-TK for submit@debbugs.gnu.org; Sat, 04 Aug 2012 09:52:51 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:54262) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sxemb-000287-84 for 11939@debbugs.gnu.org; Sat, 04 Aug 2012 09:52:47 -0400 Received: (qmail invoked by alias); 04 Aug 2012 13:45:01 -0000 Received: from 62-47-50-137.adsl.highway.telekom.at (EHLO [62.47.50.137]) [62.47.50.137] by mail.gmx.net (mp004) with SMTP; 04 Aug 2012 15:45:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/yZGFVoEjybOENaggTF8HKCOm46culJLpEAQg2Gi YMFuS2YVUdibh8 Message-ID: <501D2755.3030500@gmx.at> Date: Sat, 04 Aug 2012 15:44:53 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> In-Reply-To: <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > It is only the code that is calling for such a user dialog that knows that that > is what is being called for. By "such a user dialog", again, I mean (a) the > display of a buffer for information only, i.e., one that does not need the input > focus, and (b) request of user input with the previous buffer remaining current > and the minibuffer having the input focus. > > That is the use case that is problematic. It is the case where the above > systematic "fix" is inappropriate. There might be other such use cases, but it > is the only one I have encountered. And I have encountered it in several > different places (e.g., Dired *Marked Files* popup, *Process List* popup). > > My suggestion is, again, that we try to come up with a construct that covers > this use case, and then use it in the appropriate places: places where we do (a) > + (b). Users who want to pop up a frame with a minibuffer almost certainly want to supply their input right in the frame where the informational buffer is displayed. So there is a use case where the informational buffer must be made current. Also, when the new frame is popped up and `handle-switch-frame' switches to it, the informational buffer is made current anyway. So we'll have a hard time preserving the "with the previous buffer remaining current" requirement throughout the dialog. > On the other hand, if you know of a way to _detect_ such an intention on the > part of the developer, i.e., somehow _detect_ whether the displayed buffer > should have input focus, then I'm all ears. You know that buffers don't have input focus - only frames do, so please keep this distinction alive here. I think we agree that developers leave it to us users to decide whether the buffer is shown in a new or an existing frame. For a use case where the frame of the displayed buffer should have input focus see the `pop-up-frames' non-nil case. > I don't expect that to be possible, which is why I propose that the developer > make the intention explicit by using a new construct (e.g. a macro) that takes > care of this. > > The construct would display the informational buffer and redirect its input > focus to a standalone minibuffer, if there is one. If there is no standalone > minibuffer frame, then that part could be a no-op, AFAICT. We would at least have to make this optional. Users might want to prefer standalone buffers for most of their input but prefer answering the dialogs we talk about here in a minibuffer frame with the list of files being displayed in the same frame. The new option, let's call it `always-redirect-input-to-standalone-minibuffer-frame', if non-nil, could be used by your construct. > Something like this: > > (with-unfocused-buffer-displayed BUFFER &body BODY) > > where BUFFER is displayed for information only, and where BODY would include the > call(s) that read from the minibuffer. > > The current buffer would remain what it was beforehand, and _if_ BUFFER gets > displayed in its own frame and _if_ there is a standalone minibuffer frame, > _then_ the focus for BUFFER's frame gets automatically redirected to the > minibuffer frame. In my experience, this requirement is met if the construct requests input with BUFFER's window temporarily selected and BUFFER temporarily current. Or am I missing something? > If those conditions do not hold then there is no special > handling needed - the construct can essentially be a no-op in that case > (AFAICT). > > How something like this would be implemented I'm not sure. When the redirection > would need to take place, to DTRT, I'm not sure. Perhaps it would need to be > done more than once. > > But an important further requirement is that nothing should prevent Emacs code > in BODY or called from within BODY from switching the input focus to BUFFER's > frame. I don't understand what BODY should contain. Would this macro be responsible for displaying BUFFER? > Likewise, nothing should prevent the user from explicitly switching the > focus to BUFFER's frame. This is part of the `yes-or-no-p' dialog, nothing within the scope of the construct you propose. > The only switching of focus to BUFFER's frame that this construct would be > trying to prevent would be something that comes from neither a user action nor > the Emacs code - in particular, MS Windows auto-focussing a newly created frame. And the only way of "trying to prevent" I can think of is to redirect focus by requesting input from BUFFER's frame. > Again, I don't know the "how". But (so far) I'm convinced that this has to be > an explicit Emacs construct: there needs to be some way for a Lisp programmer to > communicate the intention that BUFFER is not intended to have the input focus ... BUFFER's frame ... > during BODY (unless that is done by the user or by code within BODY). ... during the subsequent reading from the minibuffer. BODY has terminated long ago at that time I suppose. > I do not expect that the problematic use case we've been discussing can be > detected and dealt with correctly in an automatic way. If the programmer > intention Who is the programmer here? > cannot be made explicit then there is no way to know what TRT is. First we have to separate application from user in a clear way. > It's problematic enough even with the intention communicated, in the sense that > we need to allow users and Emacs code to give focus to BUFFER's frame if they > want to. IOW, even if we _know_ that initially BUFFER's frame should not be > focused, it is hard enough to prevent or undo focusing by MS Windows while still > allowing users and Emacs to focus BUFFER. Yes. > That's the point of providing programmers with a construct to express that > intention explicitly: "This buffer's frame, if it is displayed in its own frame, > should not receive the focus." Let's be realistic, programmers won't care. We can only provide a construct that's convenient enough and has been tested in a few model cases like the ones we know of. > By "might pop up" I meant that _if_ informational BUFFER is popped up in its own minibuffer-less > frame, _then_ the intention is that that frame not receive the input focus. > >> > redirecting focus for any new frames to the minibuffer. >> >> And what you have in mind here should be distinguishable from other >> things that pop up frames but do not want the redirection. > > Not sure I follow you. Are you referring to the equivalent of possibly nested > `with-unfocused-buffer-displayed' calls? I refer to the case where a minibuffer-equipped frame is popped up. > Here's the thing. I don't know whether we can come up with something that is > 100% reliable. But the important thing, I think, is to have _some_ programmatic > translation of the programmer intention that this BUFFER be shown without giving > it the input focus. > > Today there is no way for a programmer to indicate that. S?he might not > _expect_ that the focus would be grabbed away from a minibuffer frame and given > to a new frame, but that lack of expectation today is mainly based on > inexperience with a standalone minibuffer and MS Windows. > > What's needed is some way to reinforce the programmer's natural expectation that > the user can in fact type input into the minibuffer even when the informational > buffer gets displayed. > > No one would naturally expect that not to be the case, but it can be the case, > unfortunately. So the idea is to somehow support the natural expectation and > take away the possibility (or reduce the probability) of MS Windows interfering > with what should be a simple user dialog. OK. If you think that the way with-temp-buffer-window.el handles it is not enough, tell me what you would do instead. >> What you want is some clairvoyance in step (1) of my description >> above whether step (2) will be performed. > > No, I don't think so. I don't believe in such clairvoyance (but I'm open to > being convinced). Instead, I believe in the programmer stating that the buffer > is not intended to have the focus. (But that nothing should prevent Emacs or > the user from giving it the focus at some point.) Why don't you code the macro you have in mind so we can discuss it? >> `with-temp-buffer-window' avoids that by asking the `yes-or-no-p' >> question in the new frame. > > The issue at stake is the case of a standalone minibuffer. I don't see any > problem if there is no standalone minibuffer frame. > > With a standalone minibuffer frame, the proper behavior is for the minibuffer > frame to be used for all minibuffer activity. Anything else is less than > desirable, even if it might be acceptable if no better solution could be found > in some case. > > A user of a standalone minibuffer looks there for all echo-area output and all > minibuffer input. That is one of the reasons for using a standalone minibuffer: > a single place where all Q & A with the user takes place. > > Well, nearly all. Yes, there are some times where things like `read-event' are > used instead of the minibuffer. But let's not get pedantic; this is about use > of the minibuffer and echo area. A standalone minibuffer offers the advantage > of always looking to the same place on the screen for user I/O. So let's use an option like `always-redirect-input-to-standalone-minibuffer-frame' and you propose a macro that does what you mean based on that option (I'm afraid I do not understand well what you think that macro's BODY should do). > The other potential trouble is the need to show an informational buffer that > does not necessarily correspond to what you have defined for > `with-temp-buffer-window'. So you think it's too restrictive? > To be clear, I do not know whether such a need exists much in practice. But it > looks to me like your macro and the related code you sent make additional > assumptions about the buffer that is popped up that constrain it more than what > I was describing abstractly for the hypothetical > `with-unfocused-buffer-displayed'. It's a substitute for `with-output-to-temp-buffer' with an additional function that can be used to replace the return value of the former. > The buffer in the case of `with-temp-buffer-window' starts out from scratch (it > must be empty), etc. In a nutshell, your construct assumes that the buffer > itself is temporary, whereas the only real need for our problematic use case is > that the buffer's _display_, in a separate frame, be temporary. The buffer need not be temporary. But in order for quitting to get rid of the frame, the buffer must be killed. > IOW, I think your solution is more constraining/limited and doesn't really > address the general problem, which is that of displaying _any_ buffer for only > informational use (at least initially, allowing for user/code to intentionally > switch focus to it). And AFAIK the problem we are trying to solve occurs only > when such a buffer appears in its own frame. > > Your solution certainly helps for things like *Process List* and *Marked Files*. > But the characterization of the problem is, logically, in terms of a buffer that > is displayed temporarily during a minibuffer dialog, in its own frame, and whose > frame should not have the input focus in that context. > > Am I wrong about that? If you came up with a macro that (approximately) does what you want/need, I probably could answer that question. > Don't get me wrong. I think your code (the little that I've tried using it) is > a definite improvement for the problem cases we've actually encountered, which > are in fact not only temporary displays of a buffer but also displays of a > temporary buffer. > > I'm just saying that I think the problem of MS Windows giving the focus to a new > frame that gets popped during a minibuffer interaction, where that new frame > should not have the focus, i.e., where its buffer is shown only for information, > is more general than the show-a-temporary-buffer case you have treated. > > At least that's what I think so far. You'll tell me if I'm wrong. You might be right. >> It's not that simple. The invoking code doesn't care about focus > > It does care. Maybe what you mean is that it does not expect the focus to be > messed with by MS Windows. The invoking code does not care. It expects `display-buffer' and `yes-or-no-p' to take care of this. > Typically, such code simply does not expect (take into account) a scenario where > the user (a) has a standalone minibuffer frame, (b) has the buffer in question > be popped up in its own frame, and (c) is on MS Windows, which steals the input > focus and gives it to the new frame. > > But the code does expect the minibuffer to have the focus, and it knows that the > buffer is shown only for informational purposes, i.e., the buffer does not need > (and should not have) the input focus. Once more - the code expects the underlying mechanism to handle that. > The code does not, today, explicitly express that intention/care, because > outside of the problematic case of (a), (b), and (c), which today is not that > common, there is no need to express and handle that intention. IOW it cares, > but its cares are already taken care of automatically in most cases. > >> and in particular not about some frame whose eventually popping >> up will cause problems. It expects the reading from the minibuffer >> mechanism DTRT. > > Precisely. And except for the problematic case, there has never been any need > for the programmer to make clear the fact (intention) that the buffer is > informational only. > > You have encapsulated precisely that intention in your code. But you have gone > beyond that and expressed the additional intention that the buffer be temporary. So write a `with-buffer-window' doing things in a non-temporary fashion. The problem is that removing the frame without killing the buffer will be impossible unless we provide yet another option. > And your code in fact does make the distinction between *Process List* and > *Backtrace*, which proves my point here. But your code makes the distinction > based on *Process List* being a temporary buffer (which it is), and not on it > being a buffer that is displayed temporarily in its own frame. > > The latter distinction is I think the right one, and which would be good to > handle. That is where MS Windows's automatic focusing leads to a problem. > > The problematic case is (a) standalone minibuffer (b) popped-up buffer in its > own frame, (c) that frame being new, and (d) the OS giving the new frame the > input focus. You still have to tell me how to remove that frame when you're done. > The second step, I think, would be something similar, but not limited to > temporary buffers. Some way for a programmer to express the intention of > displaying a buffer (temporary or not) only for informational purposes during a > minibuffer interaction. > > And I think that for that more general case, there is a problem to be handled > only when (a) there is a standalone minibuffer frame, (b) the buffer is popped > up in its own frame. Write the macro and we'll see further. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 04 09:52:54 2012 Received: (at 11939) by debbugs.gnu.org; 4 Aug 2012 13:52:54 +0000 Received: from localhost ([127.0.0.1]:60998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sxemk-00028X-8j for submit@debbugs.gnu.org; Sat, 04 Aug 2012 09:52:54 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:46729) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sxemh-00028O-NE for 11939@debbugs.gnu.org; Sat, 04 Aug 2012 09:52:52 -0400 Received: (qmail invoked by alias); 04 Aug 2012 13:45:09 -0000 Received: from 62-47-50-137.adsl.highway.telekom.at (EHLO [62.47.50.137]) [62.47.50.137] by mail.gmx.net (mp002) with SMTP; 04 Aug 2012 15:45:09 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/guIU4SC7gcNPbs8VP2RD5ABw+IeMO1bMSGZoSWq LO6m3ZdyB2bLrF Message-ID: <501D275D.3000701@gmx.at> Date: Sat, 04 Aug 2012 15:45:01 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' References: <838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I tried loading your code in Emacs 24.1 from my .emacs. > > Please remind me - was it supposed to work with Emacs 24.1 or just with later > builds? At least with Emacs 24.1 but it should work with earlier versions too. > Anyway, with 24.1 I immediately ran into this problem: `q' in *Help* did not > remove the frame. It just substituted the previously current buffer in that > frame. Do you mean the frame did show another buffer before? Anyway, that's a different issue. The code is supposed only for testing with the three functions `recover-file', `save-buffers-kill-emacs' and `dired-mark-pop-up'. It's possible that some of my changes also affect quitting *Help* windows and the like. Tell me the value of the *Help* window's `quit-restore' parameter. > IOW, the *Help* frame is apparently no longer special-display as it should be. It still is and should call `frame-auto-hide-function'. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 05 18:40:15 2012 Received: (at 11939) by debbugs.gnu.org; 5 Aug 2012 22:40:15 +0000 Received: from localhost ([127.0.0.1]:36003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sy9Uc-0008Ds-K3 for submit@debbugs.gnu.org; Sun, 05 Aug 2012 18:40:15 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:24336) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sy9Ub-0008Dk-8s for 11939@debbugs.gnu.org; Sun, 05 Aug 2012 18:40:14 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q75MWK1Y009723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Aug 2012 22:32:21 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q75MWJDj002481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Aug 2012 22:32:20 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q75MWJrx001234; Sun, 5 Aug 2012 17:32:19 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Aug 2012 15:32:18 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> <501D275D.3000701@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' Date: Sun, 5 Aug 2012 15:32:06 -0700 Message-ID: <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <501D275D.3000701@gmx.at> Thread-Index: Ac1yR14QJTGTfKbQTkqzGnCfQxHC6wBEOX2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Anyway, with 24.1 I immediately ran into this problem: `q' > > in *Help* did not remove the frame. It just substituted the > > previously current buffer in that frame. > > Do you mean the frame did show another buffer before? No, never. What it substituted in the *Help* frame was a buffer that was previously selected elsewhere (it was never displayed in the *Help* frame). > Anyway, that's a different issue. Yes, I imagine so. But I thought you might like to know about it. Without loading your code I do not have that problem: buffer *Help* is never replaced in its frame by any other buffer. It is a special-display buffer. > The code is supposed only for testing with the three > functions `recover-file', `save-buffers-kill-emacs' and > `dired-mark-pop-up'. It's possible that some of my changes > also affect quitting *Help* windows and the like. > Tell me the value of the *Help* > window's `quit-restore' parameter. Before loading your code there is no such parameter present. Likewise after loading it: no such parameter. This is the code that defines the *Help* frame parameters: (add-to-list 'special-display-buffer-names (list "*Help*" '1on1-display-*Help*-frame (list (cons 'background-color 1on1-help-frame-background) (cons 'mouse-color 1on1-help-frame-mouse+cursor-color) (cons 'cursor-color 1on1-help-frame-mouse+cursor-color) '(height . 40)))) > > IOW, the *Help* frame is apparently no longer > > special-display as it should be. > > It still is and should call `frame-auto-hide-function'. No idea what that means. It clearly does not behave like a special-display frame: its frame is not dedicated. FWIW, (special-display-p "*Help*") returns this: (1on1-display-*Help*-frame ((background-color . "Thistle") (mouse-color . "Blue Violet") (cursor-color . "Blue Violet") (height . 40))) From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 05 19:19:06 2012 Received: (at 11939) by debbugs.gnu.org; 5 Aug 2012 23:19:06 +0000 Received: from localhost ([127.0.0.1]:36045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyA6D-0000f5-4a for submit@debbugs.gnu.org; Sun, 05 Aug 2012 19:19:05 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:30682) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyA6A-0000en-1T for 11939@debbugs.gnu.org; Sun, 05 Aug 2012 19:19:02 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q75NBBB4025123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Aug 2012 23:11:12 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q75NBAtp003337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Aug 2012 23:11:11 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q75NBAnr015968; Sun, 5 Aug 2012 18:11:10 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Aug 2012 16:11:10 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' Date: Sun, 5 Aug 2012 16:10:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> Thread-Index: Ac1yR14QJTGTfKbQTkqzGnCfQxHC6wBEOX2QAAGvRRA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Anyway, that's a different issue. > > Yes, I imagine so. But I thought you might like to know > about it. Without loading your code I do not have that > problem: buffer *Help* is never replaced in its frame by > any other buffer. It is a special-display buffer. In case it helps you in investigating that (other) bug: This problem is not specific to *Help*. After I load your code all special-display is broken. It does not matter how the purported special-display frame is created (e.g. by matching `special-display-regexps' or using a special-display function as in the case of *Help*). Buffers that without your code are special-display, hence are in dedicated frames, no longer have dedicated frames after loading your code. HTH. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 05 21:19:56 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 01:19:56 +0000 Received: from localhost ([127.0.0.1]:36210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyBz8-0003Q7-2K for submit@debbugs.gnu.org; Sun, 05 Aug 2012 21:19:56 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:28518) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyBz2-0003Px-Pd for 11939@debbugs.gnu.org; Sun, 05 Aug 2012 21:19:52 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q761Btip014769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 01:11:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q761Bto5029261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 01:11:55 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q761BtjV002112; Sun, 5 Aug 2012 20:11:55 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Aug 2012 18:11:54 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Sun, 5 Aug 2012 18:11:39 -0700 Message-ID: <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <501D2755.3030500@gmx.at> Thread-Index: Ac1yR1sVLZKptYgsTRSHmY1foYk0bgBEwFIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Users who want to pop up a frame with a minibuffer almost > certainly want to supply their input right in the frame where the > informational buffer is displayed. So there is a use case where > the informational buffer must be made current. Again, AFAIK there is no problem if the user does not use a standalone minibuffer. A user with a standalone minibuffer is the problematic use case, and the only one I am really concerned about. AFAIK, whatever exists already is, I assume, OK for other use cases. So what you say here about such use cases ("users who want to pop up a frame with a minibuffer") is irrelevant to the discussion, or at least to my part of it. If you think there is also a problem for such cases, fine, but I cannot speak to that. I am interested in the case that I reported, i.e., for users with a standalone minibuffer frame. > Also, when the new frame is popped up and > `handle-switch-frame' switches to it, the informational buffer is made > current anyway. So we'll have a hard time preserving the "with the > previous buffer remaining current" requirement throughout the dialog. Which is why I have been saying that it will need to be about restoring focus to the minibuffer, rather than preventing focus from leaving it. We've already been around this barn a couple times now, no? MS Windows presumably takes the focus away, and there is apparently nothing we can do to prevent that. So what's needed is to try to put the focus back where it belongs, if that happens. > > On the other hand, if you know of a way to _detect_ such > > an intention on the part of the developer, i.e., somehow _detect_ > > whether the displayed buffer should have input focus, then > > I'm all ears. > > ... I think we agree that developers leave it to us users to decide > whether the buffer is shown in a new or an existing frame. Yes, but I don't see how that is relevant here. The point is that a developer would have some way to indicate the _intention_ that the minibuffer retain the focus. Where and how the informational buffer is displayed should be taken into consideration in _defining_ the macro or whatever that developers would use. But the developer would not be concerned with where or how the buffer is displayed. All the developer would need to communicate is the intention that the minibuffer have the focus. > For a use case where the frame of the displayed > buffer should have input focus see the `pop-up-frames' non-nil case. Dunno what that means. That seems irrelevant here. In particular, I use that case (non-nil p-u-f), and I can tell you that there are cases (e.g. *Backtrace*) where the buffer that is popped up in its own frame should have the input focus, and there are cases (e.g. *Process List*) where it should not. > > I don't expect that to be possible, which is why I propose > > that the developer make the intention explicit by using a new > > construct (e.g. a macro) that takes care of this. > > > > The construct would display the informational buffer and > > redirect its input focus to a standalone minibuffer, if > > there is one. If there is no standalone minibuffer frame, > > then that part could be a no-op, AFAICT. > > We would at least have to make this optional. Users might want to > prefer standalone buffers for most of their input I really do not follow you, sorry. Are you talking about minibuffer input? I am talking _only_ about the case of users who have a standalone minibuffer frame. That is the problematic case that we have (I think) been discussing from the beginning. > but prefer answering the dialogs we talk about here in a minibuffer > frame with the list of files being displayed in the same frame. Sorry, I am quite lost. What "list of files"? Here's a wild guess (ignore, if it is wrong and does not save us time): You are introducing something new, which is the possibility that a user with a standalone minibuffer frame might, in some situations, NOT want minibuffer input and echo-area messages to take place in the standalone minibuffer frame. Is that it? If so, I would respectfully request that we drop that like a hot potato. There is zero request for such a feature AFAIK. I know of no such user - do you? If you are interested in that and convinced that there is demand for it, you can always pursue it as an option after this bug gets fixed. I have no objection to the creation of such a new feature, but let's first solve the problem encountered. > The new option, let's call it > `always-redirect-input-to-standalone-minibuffer-frame', if non-nil, > could be used by your construct. No, please. What I am describing is not about _always_ redirecting input focus to a standalone minibuffer frame. The *Backtrace* example speaks to why that is not appropriate. It is about redirecting (retaining/restoring, really) input focus to that frame ONLY for _minibuffer_ input. In sum, it is about respecting the standalone minibuffer. If a user creates a standalone minibuffer frame then s?he does not want other minibuffers created on other frames. > > Something like this: > > (with-unfocused-buffer-displayed BUFFER &body BODY) > > > > where BUFFER is displayed for information only, and where > > BODY would include the call(s) that read from the minibuffer. > > > > The current buffer would remain what it was beforehand, > > and _if_ BUFFER gets displayed in its own frame and _if_ > > there is a standalone minibuffer frame, _then_ the focus > > for BUFFER's frame gets automatically redirected to the > > minibuffer frame. > > In my experience, this requirement is met if the construct requests > input with BUFFER's window temporarily selected and BUFFER > temporarily current. Or am I missing something? Sorry, I don't know what that means. Perhaps give an example of what you mean by temporarily selected and current? > > If those conditions do not hold then there is no special > > handling needed - the construct can essentially be a no-op > > in that case (AFAICT). > > > > How something like this would be implemented I'm not sure. > > When the redirection would need to take place, to DTRT, > > I'm not sure. Perhaps it would need to be done more than once. > > > > But an important further requirement is that nothing > > should prevent Emacs code in BODY or called from within > > BODY from switching the input focus to BUFFER's frame. > > I don't understand what BODY should contain. Would this macro be > responsible for displaying BUFFER? No, not as I was conceiving it. I suppose that would be a possibility, but I expect it is better to keep buffer display out of it. That's why I said things like "_if_ BUFFER gets displayed in its own frame". What I had in mind was that the macro would be responsible only for making sure that minibuffer input gets (re-)directed to the minibuffer frame. And that goes for any code in BODY, including code that might pop up BUFFER. IOW, display of BUFFER would come (if it came) from BODY. But again, I'm just thinking out loud. And it's probable that you see things that I do not. > > Likewise, nothing should prevent the user from explicitly > > switching the focus to BUFFER's frame. > > This is part of the `yes-or-no-p' dialog, nothing within the scope > of the construct you propose. Can you elaborate? I don't follow. All that I am saying is that we try to provide some kind of a construct that says: 1. Evaluate BODY. 2. But while doing that, _if_ BUFFER gets displayed, then ensure that its minibufer input (if the minibuffer is used) is directed to the standalone minibuffer frame. IOW, the use of this construct distinguishes the *Process List* case from the *Backtrace* case: The construct would be used for display of *Process List*, since we do not want that buffer to get the input focus. The construct would not be used for the *Backtrace* case. But I'm open to other suggestions. > > The only switching of focus to BUFFER's frame that this > > construct would be trying to prevent would be something > > that comes from neither a user action nor > > the Emacs code - in particular, MS Windows auto-focussing > > a newly created frame. > > And the only way of "trying to prevent" I can think of is to > redirect focus by requesting input from BUFFER's frame. That's not a solution at all. Again, we're talking about minibuffer input, i.e., input with the minibuffer active, and input that is intended to be read in the minibuffer. The aim is to get the focus moved to the minibuffer frame. I am not looking for the creation of minibuffers on other frames. I am looking for a fix to the problem that the minibuffer frame is not getting (or retaining?) the focus it needs when minibuffer input is called for. > > Again, I don't know the "how". But (so far) I'm convinced > > that this has to be an explicit Emacs construct: there needs > > to be some way for a Lisp programmer to communicate the > > intention that BUFFER is not intended to have the input focus > > ... BUFFER's frame ... Yes. > > during BODY (unless that is done by the user or by code > > within BODY). > > ... during the subsequent reading from the minibuffer. BODY has > terminated long ago at that time I suppose. No. Again, during reading from the minibuffer it is quite possible for a user to interact with other buffers and their frames. I gave the example of *Completions*. The user can hit a key or use the mouse to change the input focus temporarily to another frame - any frame. When the user does that s?he is executing code within BODY. It is code that reads from the minibuffer, but also code that implements any commands bound to keys or mouse actions that the user uses during that minibuffer dialog. That's all I meant. > > I do not expect that the problematic use case we've been > > discussing can be detected and dealt with correctly in an > > automatic way. If the programmer intention > > Who is the programmer here? The person who writes the code that reads from the minibuffer, code that might or might not be wrapped in the new macro, i.e., that might or might not want to stipulate that BUFFER is not to receive the input focus. > > cannot be made explicit then there is no way to know what TRT is. > > First we have to separate application from user in a clear way. (?) > > It's problematic enough even with the intention > > communicated, in the sense that we need to allow users > > and Emacs code to give focus to BUFFER's frame if they > > want to. IOW, even if we _know_ that initially BUFFER's > > frame should not be focused, it is hard enough to > > prevent or undo focusing by MS Windows while still > > allowing users and Emacs to focus BUFFER. > > Yes. > > > That's the point of providing programmers with a construct > > to express that intention explicitly: "This buffer's frame, > > if it is displayed in its own frame, should not receive > > the focus." > > Let's be realistic, programmers won't care. As one programmer, I care. But I agree that it will be difficult to get programmers to be sensitive to the possibility that some users have a standalone minibuffer and some OS's might steal focus and give it to new frames that are popped up. This is nothing new - Emacs developers tend not to even consider the non-nil `pop-up-frames' case (or its Emacs 24+ equivalent) when they implement a new feature. For a poster-child example, see bug #12139. But if things start to work better, more seamlessly, for Emacs with frames and a standalone minibuffer, then maybe more users will opt for that. And that will perhaps mean that more programmers will naturally think to test such use cases as well. I can only continue to hope. > We can only provide a construct that's convenient enough > and has been tested in a few model cases like the ones > we know of. Agreed. My description is vague not because I want the moon but because I don't know what the implementation might look like. If I get something that is better I'll be happy, even if it is not perfect. > > By "might pop up" I meant that _if_ informational BUFFER > > is popped up in its own > > minibuffer-less Of course. We are only talking about the case where there is a standalone minibuffer frame. That is THE minibuffer - THE place where users look for input queries and output messages. All other frames are minibuffer-less. Or they should be. Not being able to use the standalone minibuffer in some context, and having to use another minibuffer somewhere else, would be a degraded mode, just a workaround. Better than nothing, perhaps (perhaps), but it does not respect the standalone minibuffer or the user who called for it. > > frame, _then_ the intention is that that frame not receive > > the input focus. > > > >> > redirecting focus for any new frames to the minibuffer. > >> > >> And what you have in mind here should be distinguishable > >> from other things that pop up frames but do not want > >> the redirection. > > > > Not sure I follow you. Are you referring to the > > equivalent of possibly nested > > `with-unfocused-buffer-displayed' calls? > > I refer to the case where a minibuffer-equipped frame is popped up. I'd rather you didn't. Let's not bring in new things. The problem is that the minibuffer is not getting the focus it needs. There is no request for some additional, proxy minibuffer to appear somewhere else. That's not TRT. You have a perfectly good, brand new car that runs fine. You can drive it everywhere except that there is one bridge that is broken near your home. You just cannot get home by car using that bridge. What is offered as help is for you to wait at the washed-out bridge for a helicopter that comes once a day and can take you across the river. That's a temporary workaround, and it might be welcome, but it is not a real solution. The solution that is needed is for the bridge to be fixed. > > Here's the thing. I don't know whether we can come up > > with something that is 100% reliable. But the important > > thing, I think, is to have _some_ programmatic > > translation of the programmer intention that this BUFFER > > be shown without giving it the input focus. > > > > Today there is no way for a programmer to indicate that. > > S?he might not _expect_ that the focus would be grabbed > > away from a minibuffer frame and given to a new frame, > > but that lack of expectation today is mainly based on > > inexperience with a standalone minibuffer and MS Windows. > > > > What's needed is some way to reinforce the programmer's > > natural expectation that the user can in fact type input > > into the minibuffer even when the informational > > buffer gets displayed. > > > > No one would naturally expect that not to be the case, > > but it can be the case, unfortunately. So the idea is > > to somehow support the natural expectation and take away > > the possibility (or reduce the probability) of > > MS Windows interfering with what should be a simple user > > dialog. > > OK. If you think that the way with-temp-buffer-window.el > handles it is not enough, tell me what you would do instead. I don't know. The only problems I am aware of for `w-t-b-w.el' are these: 1. Loss of special-displayness (a separate problem, but important if we're talking about `w-t-b-w.el' as it stands now). 2. The fact that it limits itself to display of temporary buffers, whereas the actual problem has to do with the temporary display of buffers. Unless I'm missing something, it does not have the problem (from my point of view) that the frame popped up has its own minibuffer. And that's good. I mention this because you keep mentioning that as a possibility. I'm glad that `w-t-b-w.el' does not make that happen. When I use `w-t-b-w.el' with the *Process List* thing it correctly prompts for the answer in the minibuffer frame. Dunno whether that is just because that is a `yes-or-no-p' thing or whether the problem does not exist in general. After the special-display bug is fixed I'll try to use `w-t-b-w.el' more, to see. Anyway, if `w-t-b-w.el' has no other problems than #2, and if #1 is fixed, then I can certainly live with it. And I will appreciate it! Ideally I would like something that I can also use with other Emacs versions, but as I said, that's just a nice-to-have. So I would say that if anything I've said suggests to you that you might be able to improve `w-t-b-w.el' so that it handles an arbitrary buffer and not just a temporary buffer, that would be great. If not, then let's at least get `w-t-b-w.el' into Emacs (after fixing the special-display bug). That will be a big improvement and much appreciated, by me at least. Can you fix the special-display bug, so that I will be able to use `w-t-b-w.el' more, to let you know if I encounter other problems? And as far as you know, is the fact that the minibuffer frame is still used (as it should be) due only to the fact that `yes-or-no-p' is used, or can I expect that the minibuffer frame will be used in general? > >> What you want is some clairvoyance in step (1) of my description > >> above whether step (2) will be performed. > > > > No, I don't think so. I don't believe in such > > clairvoyance (but I'm open to being convinced). > > Instead, I believe in the programmer stating that the > > buffer is not intended to have the focus. (But that > > nothing should prevent Emacs or the user from giving > > it the focus at some point.) > > Why don't you code the macro you have in mind so we can discuss it? I'm afraid I cannot help here. > >> `with-temp-buffer-window' avoids that by asking the > >> `yes-or-no-p' question in the new frame. Dunno why I (or was it you?) said that. I see the question in the minibuffer frame, not the new frame. Which is TRT. > > The issue at stake is the case of a standalone minibuffer. > > I don't see any problem if there is no standalone > > minibuffer frame. > > > > With a standalone minibuffer frame, the proper behavior > > is for the minibuffer frame to be used for all minibuffer > > activity. Anything else is less than desirable, even if > > it might be acceptable if no better solution could be > > found in some case. > > > > A user of a standalone minibuffer looks there for all > > echo-area output and all minibuffer input. That is one > > of the reasons for using a standalone minibuffer: > > a single place where all Q & A with the user takes place. > > > > Well, nearly all. Yes, there are some times where things > > like `read-event' are used instead of the minibuffer. > > But let's not get pedantic; this is about use of the > > minibuffer and echo area. A standalone minibuffer > > offers the advantage of always looking to the same place > > on the screen for user I/O. > > So let's use an option like > `always-redirect-input-to-standalone-minibuffer-frame' > and you propose a macro that does what you mean I'm afraid I cannot come up with the macro. I was hoping that my description of what would be good might inspire you. ;-) > based on that option (I'm afraid I do not > understand well what you think that macro's BODY should do). I know I was vague, but I do not know what needs to be done in terms of implementation. If my description, including above, doesn't help, forget about this enhancement. > > The other potential trouble is the need to show an > > informational buffer that does not necessarily correspond > > to what you have defined for `with-temp-buffer-window'. > > So you think it's too restrictive? Yes, it is more restrictive than the actual problem encountered. As I said, it might suffice in practice, but there is nothing in the problem description that requires that the buffer itself be temporary. Yes, *Process List* and *Marked Files* are temporary. But there is no reason to suppose that we will never want to temporarily display some non-temporary buffer without giving it the input focus. > > To be clear, I do not know whether such a need exists much > > in practice. But it looks to me like your macro and the > > related code you sent make additional assumptions about > > the buffer that is popped up that constrain it more than > > what I was describing abstractly for the hypothetical > > `with-unfocused-buffer-displayed'. > > It's a substitute for `with-output-to-temp-buffer' with an > additional function that can be used to replace the return > value of the former. That's great. I have no objection to it. I was just saying that it corresponds to a set of use cases that is a subset of the use cases where the input-focus switch (by MS Windows) will present a problem. > > The buffer in the case of `with-temp-buffer-window' starts > > out from scratch (it must be empty), etc. In a nutshell, > > your construct assumes that the buffer itself is temporary, > > whereas the only real need for our problematic use case is > > that the buffer's _display_, in a separate frame, be temporary. > > The buffer need not be temporary. But in order for quitting > to get rid of the frame, the buffer must be killed. In that, it is temporary. Also in the fact (IIUC) that it is empty/emptied to start with. > > IOW, I think your solution is more constraining/limited > > and doesn't really address the general problem, which > > is that of displaying _any_ buffer for only > > informational use (at least initially, allowing for > > user/code to intentionally switch focus to it). And > > AFAIK the problem we are trying to solve occurs only > > when such a buffer appears in its own frame. > > > > Your solution certainly helps for things like *Process > > List* and *Marked Files*. But the characterization of > > the problem is, logically, in terms of a buffer that > > is displayed temporarily during a minibuffer dialog, in > > its own frame, and whose frame should not have the input > > focus in that context. > > > > Am I wrong about that? > > If you came up with a macro that (approximately) does what you > want/need, I probably could answer that question. > > > Don't get me wrong. I think your code (the little that > > I've tried using it) is a definite improvement for the > > problem cases we've actually encountered, which > > are in fact not only temporary displays of a buffer but > > also displays of a temporary buffer. > > > > I'm just saying that I think the problem of MS Windows > > giving the focus to a new frame that gets popped during > > a minibuffer interaction, where that new frame should > > not have the focus, i.e., where its buffer is shown > > only for information, is more general than the > > show-a-temporary-buffer case you have treated. > > > > At least that's what I think so far. You'll tell me if I'm > > wrong. > > You might be right. Let's move one step at a time. I can't really help with coming up with the macro that I imagine vaguely. And you are having difficulty seeing what I'm getting at, which might well be an indication that I am mixed up a bit. Why don't you try to fix the special-display bug in your code, and then I'll use it a bit more to see if I encounter other problems. If not, then it would be good if you added it to Emacs. After that, we can always discuss any further enhancements or other improvements, in a different thread or off list. I think that most of what I've tried to say you understand, so if in the future you do see a possibility of generalizing the fix etc. then you might want to do so. I cannot really expect more than to make myself understood so that you can keep the wish in mind. > >> It's not that simple. The invoking code doesn't care about focus > > > > It does care. Maybe what you mean is that it does not > > expect the focus to be messed with by MS Windows. > > The invoking code does not care. It expects `display-buffer' and > `yes-or-no-p' to take care of this. In the general case it is not `yes-or-no-p'. But OK, I think we are saying the same thing, using different words. > > Typically, such code simply does not expect (take into > > account) a scenario where the user (a) has a standalone > > minibuffer frame, (b) has the buffer in question > > be popped up in its own frame, and (c) is on MS Windows, > > which steals the input focus and gives it to the new frame. > > > > But the code does expect the minibuffer to have the focus, > > and it knows that the buffer is shown only for informational > > purposes, i.e., the buffer does not need > > (and should not have) the input focus. > > Once more - the code expects the underlying mechanism to handle that. If you agree with the last paragraph I wrote, then fine. I think we are saying the same thing. I certainly agree that the invoking code should not have to care about setting/changing focus. By "it cares" I meant only that it cares that the minibuffer have the focus - it expects that. It does not care/want to have to manage the focus itself. It "expects the underlying mechanism to handle that." The code's intention that the minibuffer receive the input is not something that programmers should have to express. But I see no way around that if MS Windows gets in the middle and moves the focus around. But if you can make sure that there is no need to express such an intention in the code explicitly, so much the better. I was expecting that such expression would enable us to DTRT wrt focus redirection, e.g. to distinguish the *Process List* case from the *Backtrace* case. But if that's not necessary, good. > > The code does not, today, explicitly express that > > intention/care, because outside of the problematic case > > of (a), (b), and (c), which today is not that common, > > there is no need to express and handle that intention. > > IOW it cares, but its cares are already taken care of > > automatically in most cases. > > > >> and in particular not about some frame whose eventually > >> popping up will cause problems. It expects the reading > >> from the minibuffer mechanism DTRT. > > > > Precisely. And except for the problematic case, there has > > never been any need for the programmer to make clear the > > fact (intention) that the buffer is informational only. > > > > You have encapsulated precisely that intention in your > > code. But you have gone beyond that and expressed the > > additional intention that the buffer be temporary. > > So write a `with-buffer-window' doing things in a > non-temporary fashion. See above. > The problem is that removing the frame without killing > the buffer will be impossible unless we provide yet another > option. Maybe it's good that we talk about this more general case later. I don't want the ideal to become the enemy of the good. I would like to see your current solution applied to Emacs before we get too far afield. > > And your code in fact does make the distinction between > > *Process List* and *Backtrace*, which proves my point here. > > But your code makes the distinction based on *Process List* > > being a temporary buffer (which it is), and not on it > > being a buffer that is displayed temporarily in its own frame. > > > > The latter distinction is I think the right one, and which > > would be good to handle. That is where MS Windows's > > automatic focusing leads to a problem. > > > > The problematic case is (a) standalone minibuffer (b) > > popped-up buffer in its own frame, (c) that frame being > > new, and (d) the OS giving the new frame the input focus. > > You still have to tell me how to remove that frame when you're done. The informational frame? I'd vote for `delete-frame', at least for my own use. We might want to provide ways for the caller and/or the user to control both what to do with the frame/window and what to do with the buffer. But maybe `frame-auto-hide-function' would make sense here? Anyway, let's talk about this later. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 11:36:31 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 15:36:31 +0000 Received: from localhost ([127.0.0.1]:37692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyPM6-0007jY-SO for submit@debbugs.gnu.org; Mon, 06 Aug 2012 11:36:31 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:34492) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SyPM4-0007jQ-8r for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 11:36:29 -0400 Received: (qmail invoked by alias); 06 Aug 2012 15:28:33 -0000 Received: from 62-47-38-62.adsl.highway.telekom.at (EHLO [62.47.38.62]) [62.47.38.62] by mail.gmx.net (mp071) with SMTP; 06 Aug 2012 17:28:33 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+amGxitJ+a4MxdQGjmcTESUyyDmlznsC5Jz2zBwy LUQ+Q6KLKwcfp7 Message-ID: <501FE2C6.8060204@gmx.at> Date: Mon, 06 Aug 2012 17:29:10 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' References: <83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> <501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> In-Reply-To: <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Tell me the value of the *Help* >> window's `quit-restore' parameter. > > Before loading your code there is no such parameter present. > Likewise after loading it: no such parameter. Whenever I call `display-buffer', the window used has the `quit-restore' parameter set. If it doesn't on your system, I don't know. >> > IOW, the *Help* frame is apparently no longer >> > special-display as it should be. >> >> It still is and should call `frame-auto-hide-function'. > > No idea what that means. `frame-auto-hide-function' is the function called to automatically hide frames. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 11:36:43 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 15:36:43 +0000 Received: from localhost ([127.0.0.1]:37695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyPMJ-0007jv-Dj for submit@debbugs.gnu.org; Mon, 06 Aug 2012 11:36:43 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:55551) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SyPMH-0007jo-3w for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 11:36:41 -0400 Received: (qmail invoked by alias); 06 Aug 2012 15:28:47 -0000 Received: from 62-47-38-62.adsl.highway.telekom.at (EHLO [62.47.38.62]) [62.47.38.62] by mail.gmx.net (mp012) with SMTP; 06 Aug 2012 17:28:47 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX196L/BvmvF65xg3jFkdXr1JGsHSUBnpbxoZ5hZdqU xx/CBYSLip1/8p Message-ID: <501FE2D4.1050103@gmx.at> Date: Mon, 06 Aug 2012 17:29:24 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' References: <83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > In case it helps you in investigating that (other) bug: > > This problem is not specific to *Help*. After I load your code all > special-display is broken. It does not matter how the purported special-display > frame is created (e.g. by matching `special-display-regexps' or using a > special-display function as in the case of *Help*). > > Buffers that without your code are special-display, hence are in dedicated > frames, no longer have dedicated frames after loading your code. > > HTH. No. If, with emacs -Q, I do (progn (load ".../with-temp-buffer-window.el") (setq special-display-buffer-names '("*Process List*")) (display-buffer (get-buffer-create "*Process List*"))) I get the buffer *Process List* on a separate frame, in a strongly dedicated window and with a `quit-restore' window parameter as ((quit-restore frame frame # #)) If I do `quit-window' in that window, the frame is iconified. Tested with Emacs 24.1 release and the latest trunk version I was able to build. If you get different results, there's nothing I can do. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 11:36:56 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 15:36:57 +0000 Received: from localhost ([127.0.0.1]:37698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyPMV-0007kK-MV for submit@debbugs.gnu.org; Mon, 06 Aug 2012 11:36:56 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:55109) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SyPMS-0007kC-Tr for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 11:36:54 -0400 Received: (qmail invoked by alias); 06 Aug 2012 15:28:58 -0000 Received: from 62-47-38-62.adsl.highway.telekom.at (EHLO [62.47.38.62]) [62.47.38.62] by mail.gmx.net (mp017) with SMTP; 06 Aug 2012 17:28:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/iHEQoYQ3ibD0+NCztR8WGWhdBy4S39Y9omo6vkW j186SQ+wmSBPem Message-ID: <501FE2DF.6030906@gmx.at> Date: Mon, 06 Aug 2012 17:29:35 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> In-Reply-To: <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > Something like this: >> > (with-unfocused-buffer-displayed BUFFER &body BODY) >> > >> > where BUFFER is displayed for information only, and where >> > BODY would include the call(s) that read from the minibuffer. >> > >> > The current buffer would remain what it was beforehand, >> > and _if_ BUFFER gets displayed in its own frame and _if_ >> > there is a standalone minibuffer frame, _then_ the focus >> > for BUFFER's frame gets automatically redirected to the >> > minibuffer frame. >> >> In my experience, this requirement is met if the construct requests >> input with BUFFER's window temporarily selected and BUFFER >> temporarily current. Or am I missing something? > > Sorry, I don't know what that means. Perhaps give an example of what you mean > by temporarily selected and current? Temporarily selected means selected via `with-selected-window' and temporarily current means `with-current-buffer'. >> > handling needed - the construct can essentially be a no-op >> > in that case (AFAICT). >> > >> > How something like this would be implemented I'm not sure. >> > When the redirection would need to take place, to DTRT, >> > I'm not sure. Perhaps it would need to be done more than once. >> > >> > But an important further requirement is that nothing >> > should prevent Emacs code in BODY or called from within >> > BODY from switching the input focus to BUFFER's frame. >> >> I don't understand what BODY should contain. Would this macro be >> responsible for displaying BUFFER? > > No, not as I was conceiving it. I suppose that would be a possibility, but I > expect it is better to keep buffer display out of it. That's why I said things > like "_if_ BUFFER gets displayed in its own frame". > > What I had in mind was that the macro would be responsible only for making sure > that minibuffer input gets (re-)directed to the minibuffer frame. And that goes > for any code in BODY, including code that might pop up BUFFER. > > IOW, display of BUFFER would come (if it came) from BODY. > > But again, I'm just thinking out loud. And it's probable that you see things > that I do not. No. Just that I don't have the slightest idea how to write a macro that modifies the behavior of a `yes-or-no-p' dialog it calls. read_minibuf and the code for handling keyboard events do the redirecting. >> > Likewise, nothing should prevent the user from explicitly >> > switching the focus to BUFFER's frame. >> >> This is part of the `yes-or-no-p' dialog, nothing within the scope >> of the construct you propose. > > Can you elaborate? I don't follow. IIUC you want to modify the behavior of `yes-or-no-p' to redirect frame focus in your sense. > No. Again, during reading from the minibuffer it is quite possible for a user > to interact with other buffers and their frames. I gave the example of > *Completions*. The user can hit a key or use the mouse to change the input > focus temporarily to another frame - any frame. > > When the user does that s?he is executing code within BODY. It is code that > reads from the minibuffer, but also code that implements any commands bound to > keys or mouse actions that the user uses during that minibuffer dialog. That's > all I meant. I'm afraid this gets too complicated for me. You have to find someone who understands such scenarios better than me. >> > I do not expect that the problematic use case we've been >> > discussing can be detected and dealt with correctly in an >> > automatic way. If the programmer intention >> >> Who is the programmer here? > > The person who writes the code that reads from the minibuffer, code that might > or might not be wrapped in the new macro, i.e., that might or might not want to > stipulate that BUFFER is not to receive the input focus. The person who writes that code expects `yes-or-no-p' DTRT. >> I refer to the case where a minibuffer-equipped frame is popped up. > > I'd rather you didn't. Let's not bring in new things. Users with non-nil `pop-up-frames' who don't use minibuffer-only frames do get a minibuffer-equipped frame popped up. You can ignore them, I can't. And a user who excludes BUFFER from the list of specially displayed buffers does a perfectly valid thing and can expect Emacs to handle it as it currently does. > I don't know. The only problems I am aware of for `w-t-b-w.el' are these: > > 1. Loss of special-displayness (a separate problem, but important if we're > talking about `w-t-b-w.el' as it stands now). > > 2. The fact that it limits itself to display of temporary buffers, whereas the > actual problem has to do with the temporary display of buffers. Because I can safely kill a temporary buffer and remove its frame when I'm done with the dialog. > And as far as you know, is the fact that the minibuffer frame is still used (as > it should be) due only to the fact that `yes-or-no-p' is used, or can I expect > that the minibuffer frame will be used in general? Due to the fact that `yes-or-no-p' is called in a special way - with the new window selected. >> >> `with-temp-buffer-window' avoids that by asking the >> >> `yes-or-no-p' question in the new frame. > > Dunno why I (or was it you?) said that. I see the question in the minibuffer > frame, not the new frame. Which is TRT. To "see the question in the minibuffer frame" I ask it in the new frame. > Yes, it is more restrictive than the actual problem encountered. As I said, it > might suffice in practice, but there is nothing in the problem description that > requires that the buffer itself be temporary. I have to kill the buffer to remove the frame. And I have to remove the frame because you complained that `save-window-excursion' cannot remove a popped up frame. And I can't kill a non-temporary buffer. >> The invoking code does not care. It expects `display-buffer' and >> `yes-or-no-p' to take care of this. > > In the general case it is not `yes-or-no-p'. It can do anything that reads from the minibuffer. > The informational frame? I'd vote for `delete-frame', at least for my own use. > We might want to provide ways for the caller and/or the user to control both > what to do with the frame/window and what to do with the buffer. But maybe > `frame-auto-hide-function' would make sense here? If we use `frame-auto-hide-function', the caller does not have to kill the buffer and there's no need to make this construct work for temporary buffers only. > Anyway, let's talk about this later. It's your choice. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 17:04:00 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 21:04:00 +0000 Received: from localhost ([127.0.0.1]:38134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUT2-0008S1-0T for submit@debbugs.gnu.org; Mon, 06 Aug 2012 17:04:00 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:35121) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUT0-0008Ru-5h for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 17:03:58 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q76Ku2IH004156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 20:56:02 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q76Ku1fb027957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 20:56:01 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q76Ku1PW032680; Mon, 6 Aug 2012 15:56:01 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Aug 2012 13:56:01 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> <501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> <501FE2C6.8060204@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' Date: Mon, 6 Aug 2012 13:55:59 -0700 Message-ID: <268E38CB8E2A453EACA574FB7B00628F@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1z6CVbDzIbqpHbQUeYqCS/Ka7tKwAFDz2A In-Reply-To: <501FE2C6.8060204@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> Tell me the value of the *Help* > >> window's `quit-restore' parameter. > > > > Before loading your code there is no such parameter present. > > Likewise after loading it: no such parameter. > > Whenever I call `display-buffer', the window used has the > `quit-restore' parameter set. If it doesn't on your system, > I don't know. I don't know either. I've never seen that frame parameter. This has nothing specially to do with the *Help* frame. When I do (frame-parameters) in ANY frame I do not see a parameter named `quit-restore'. Am I missing something? Is this parameter not returned via `frame-parameters' or something? > >> > IOW, the *Help* frame is apparently no longer > >> > special-display as it should be. > >> > >> It still is and should call `frame-auto-hide-function'. > > > > No idea what that means. > > `frame-auto-hide-function' is the function called to > automatically hide frames. What I don't understand is your statement "It still is". From appearances it is not special-display, in the sense that its frame does not seem to be dedicated. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 17:04:41 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 21:04:41 +0000 Received: from localhost ([127.0.0.1]:38138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUTg-0008TJ-Bf for submit@debbugs.gnu.org; Mon, 06 Aug 2012 17:04:41 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:32910) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUTe-0008TC-6H for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 17:04:38 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q76KueNu007211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 20:56:41 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q76KudGp028724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 20:56:40 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q76KudvU024110; Mon, 6 Aug 2012 15:56:39 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Aug 2012 13:56:39 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> <501FE2D4.1 050103@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' Date: Mon, 6 Aug 2012 13:56:38 -0700 Message-ID: <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1z6C0bLasZ3UurTViowD2q8XxTRQAFSJYQ In-Reply-To: <501FE2D4.1050103@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > If, with emacs -Q, I do > (progn > (load ".../with-temp-buffer-window.el") > (setq special-display-buffer-names '("*Process List*")) > (display-buffer (get-buffer-create "*Process List*"))) > > I get the buffer *Process List* on a separate frame, in a strongly > dedicated window I do too (following that recipe from emacs -Q), the dedicatedness being judged by trying to do C-x b in it and getting this error message: switch-to-buffer: Cannot switch buffers in a dedicated window > and with a `quit-restore' window parameter as > > ((quit-restore frame frame # # *Process List*>)) No, there is still no `quit-restore' parameter, according to `frame-parameters'. > If I do `quit-window' in that window, the frame is iconified. Same here. This is with Emacs 24.1. > Tested with Emacs 24.1 release and the latest trunk version I > was able to build. If you get different results, there's nothing I can do. HTH. This test does not involve a standalone minibuffer or other things that are in my setup. But at least you can see that parameter `quit-restore' is missing. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 17:13:47 2012 Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 21:13:47 +0000 Received: from localhost ([127.0.0.1]:38146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUcS-0000E9-2O for submit@debbugs.gnu.org; Mon, 06 Aug 2012 17:13:47 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:37465) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUcL-0000Dw-R7 for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 17:13:42 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q76L5evE015769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 21:05:41 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q76L5ehh016997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 21:05:40 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q76L5etV006538; Mon, 6 Aug 2012 16:05:40 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Aug 2012 14:05:39 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Mon, 6 Aug 2012 14:05:38 -0700 Message-ID: <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1z6DRCPYudJ+Y/R1mGFsweNpTYrgAFqPwg In-Reply-To: <501FE2DF.6030906@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> > Something like this: > >> > (with-unfocused-buffer-displayed BUFFER &body BODY) > >> > > >> > where BUFFER is displayed for information only, and where > >> > BODY would include the call(s) that read from the minibuffer. > >> > > >> > The current buffer would remain what it was beforehand, > >> > and _if_ BUFFER gets displayed in its own frame and _if_ > >> > there is a standalone minibuffer frame, _then_ the focus > >> > for BUFFER's frame gets automatically redirected to the > >> > minibuffer frame. > >> > >> In my experience, this requirement is met if the construct requests > >> input with BUFFER's window temporarily selected and BUFFER > >> temporarily current. Or am I missing something? > > > > Sorry, I don't know what that means. Perhaps give an > > example of what you mean by temporarily selected and current? > > Temporarily selected means selected via `with-selected-window' and > temporarily current means `with-current-buffer'. OK, but I still don't see what you are trying to say, or why. You seem to be saying that if BUFFER is selected/current, and if input is read somewhere (where?) - then what? The focus gets automatically redirected to the minibuffer frame? This is not about reading input with BUFFER selected/current. The idea is to have the _previously_ selected buffer be selected/current, while input is read from the minibuffer. The idea is not to make BUFFER selected/current, but just to display it. Beyond that, that sentence of mine was shorthand. It (apparently) is not enough that the focus be redirected once, at some point, to the minibuffer frame. It needs to either remain there (somehow preventing MS Windows from moving it away) or be put back there (after MS Windows moves it to BUFFER's frame). IOW, even if redirection is happening now as it should, it is not sufficient if, after that redirection to the minibuffer, the OS changes the focus again (to the new frame). > >> > handling needed - the construct can essentially be a no-op > >> > in that case (AFAICT). > >> > > >> > How something like this would be implemented I'm not sure. > >> > When the redirection would need to take place, to DTRT, > >> > I'm not sure. Perhaps it would need to be done more than once. > >> > > >> > But an important further requirement is that nothing > >> > should prevent Emacs code in BODY or called from within > >> > BODY from switching the input focus to BUFFER's frame. > >> > >> I don't understand what BODY should contain. Would this macro be > >> responsible for displaying BUFFER? > > > > No, not as I was conceiving it. I suppose that would be a > > possibility, but I expect it is better to keep buffer display out of it. > > That's why I said things like "_if_ BUFFER gets displayed in its own frame". > > > > What I had in mind was that the macro would be responsible > > only for making sure that minibuffer input gets (re-)directed to the > > minibuffer frame. And that goes for any code in BODY, including code > > that might pop up BUFFER. > > > > IOW, display of BUFFER would come (if it came) from BODY. > > > > But again, I'm just thinking out loud. And it's probable > > that you see things that I do not. > > No. Just that I don't have the slightest idea how to write a > macro that modifies the behavior of a `yes-or-no-p' dialog it calls. > read_minibuf and the code for handling keyboard events do the redirecting. > > >> > Likewise, nothing should prevent the user from explicitly > >> > switching the focus to BUFFER's frame. > >> > >> This is part of the `yes-or-no-p' dialog, nothing within the scope > >> of the construct you propose. > > > > Can you elaborate? I don't follow. > > IIUC you want to modify the behavior of `yes-or-no-p' to > redirect frame focus in your sense. I don't know why you mention `yes-or-no-p'. This is about reading from the minibuffer, in general. I don't want or not want to modify `yes-or-no-p' or `read-from-minibuffer'. I'm just saying that if the problem is that we want to display BUFFER, and it gets displayed in a new frame, and we want to read from the minibuffer, then we do not want, for that minibuffer reading, the input focus to be in BUFFER's frame. I spoke of redirecting, but it might take more than that or doing that more than once, if the OS switches focus after redirection to the minibuffer. > > No. Again, during reading from the minibuffer it is quite > > possible for a user to interact with other buffers and their frames. > > I gave the example of *Completions*. The user can hit a key or use > > the mouse to change the input focus temporarily to another frame - > > any frame. > > > > When the user does that s?he is executing code within > > BODY. It is code that reads from the minibuffer, but also code > > that implements any commands bound to keys or mouse actions that > > the user uses during that minibuffer dialog. That's > > all I meant. > > I'm afraid this gets too complicated for me. You have to find someone > who understands such scenarios better than me. The scenario is as simple as your clicking a special-display (hence dedicated, separate frame) *Completions* frame during minibuffer input. That changes the focus to *Completions*. But that doesn't mean that you cannot switch back to the minibuffer frame again. The only point here is that whatever is done to fix the problem should not in any way prevent a user from clicking *Completions* and thus switching the focus there. Or any other frame, besides *Completions*. You should be able to click another frame, type some text there, then click the minibuffer frame and finish entering the input text it wants to read. IOW, minibuffer interaction is not modal; it does not (should not) prevent you from interacting with other parts of Emacs, including typing into other frames. This was in response to your statement that we wanted to _always_ have the focus on the minibuffer frame. Yes, when reading from the minibuffer is initiated, the minibuffer frame should get the focus. But the user (or Emacs) should not be prevented from switching the focus to another frame. All that we are trying to prevent or remedy is the focus switching to another (new) frame by the OS. We should not be preventing either Emacs or the user from switching focus to another frame, just because the minibuffer is active. That is the only point I was trying to make here. > >> > I do not expect that the problematic use case we've been > >> > discussing can be detected and dealt with correctly in an > >> > automatic way. If the programmer intention > >> > >> Who is the programmer here? > > > > The person who writes the code that reads from the minibuffer, > > code that might or might not be wrapped in the new macro, i.e., > > that might or might not want to stipulate that BUFFER is not to > > receive the input focus. > > The person who writes that code expects `yes-or-no-p' DTRT. Agreed. > >> I refer to the case where a minibuffer-equipped frame is > >> popped up. > > > > I'd rather you didn't. Let's not bring in new things. > > Users with non-nil `pop-up-frames' who don't use minibuffer-only > frames do get a minibuffer-equipped frame popped up. Of course they do. But is there a problem for them? Has any problem similar to the one reported for this bug been identified for those different use cases? This bug is about a problem that arises (with MS Windows) when you do have a standalone minibuffer frame. That's all. > You can ignore them, I can't. No one is asking you to ignore them. If you see a related problem for other use cases, by all means, try to address that problem at the same time. I have not heard of such a problem, so to me bringing up that use case seems irrelevant. I care about _this_ bug being fixed. But that does not mean that I want to prevent you from fixing other bugs. I haven't heard of any such problem without a standalone minibuffer, however. > And a user who excludes BUFFER from the list of specially > displayed buffers does a perfectly valid thing and can expect Emacs to > handle it as it currently does. OK by me. I have no argument against that. I don't see how it's related, but it's fine by me. > > I don't know. The only problems I am aware of for > > `w-t-b-w.el' are these: > > > > 1. Loss of special-displayness (a separate problem, but > > important if we're talking about `w-t-b-w.el' as it stands now). > > > > 2. The fact that it limits itself to display of temporary > > buffers, whereas the actual problem has to do with the temporary > > display of buffers. > > Because I can safely kill a temporary buffer and remove its frame when > I'm done with the dialog. OK. I've already agreed that that is a good thing. I'm in favor of your proposed fix. I was just pointing out that there can be cases of MS Windows messing things up that your fix won't solve, namely, temporary display of a non-temporary buffer, a buffer that you do not want input to be focused to. > > And as far as you know, is the fact that the minibuffer > > frame is still used (as it should be) due only to the fact that > > `yes-or-no-p' is used, or can I expect > > that the minibuffer frame will be used in general? > > Due to the fact that `yes-or-no-p' is called in a special way > - with the new window selected. > > >> >> `with-temp-buffer-window' avoids that by asking the > >> >> `yes-or-no-p' question in the new frame. > > > > Dunno why I (or was it you?) said that. I see the > > question in the minibuffer frame, not the new frame. > > Which is TRT. > > To "see the question in the minibuffer frame" I ask it in the > new frame. OK. That was worth clarifying. I wasn't understanding that. I see the question in the minibuffer frame, and I type the answer there. My impression was that the minibuffer frame had the focus. I did not know where you were asking the question. By that, I assume you mean that the new frame is selected (and has the focus?) when you invoke `yes-or-no-p'. Is that right? Just for my info, why does it matter where `yes-or-no-p' is invoked? _Should_ it matter, or is it just a fact that we must live with that it does matter? > > Yes, it is more restrictive than the actual problem encountered. > > As I said, it might suffice in practice, but there is nothing in the > > problem description that requires that the buffer itself be temporary. > > I have to kill the buffer to remove the frame. I don't understand why, but probably I don't need to understand everything. Why doesn't `delete-frame' do what you need? > And I have to remove the frame because you complained that > `save-window-excursion' cannot remove a popped up frame. Hm. I don't recall that at all, but I believe you that I did. Was that in some other thread? > And I can't kill a non-temporary buffer. > > The informational frame? I'd vote for `delete-frame', at > > least for my own use. We might want to provide ways for the > > caller and/or the user to control both what to do with the > > frame/window and what to do with the buffer. But maybe > > `frame-auto-hide-function' would make sense here? > > If we use `frame-auto-hide-function', the caller does not have to kill > the buffer and there's no need to make this construct work > for temporary buffers only. That sounds good to me. Perhaps I'm missing something. I don't want to steer you down the wrong path, but what you say here sounds good to me. If the more general case can be handled, then the more restrictive case (temporary buffer, not just temporary display) could presumably be handled also, as a subcase, no? Or even if not as a subcase, as a separate case. IOW, if possible it would be good to have both possibilities, so a programmer could get the right behavior for a given context: If s?he wants that buffer to be temporary, then call a construct that treats it as such (killing it). If s?he wants that buffer not to be temporary and only its display to be temporary then call a construct that does that instead. > > Anyway, let's talk about this later. > > It's your choice. Can we have both possibilities? If not, let's get the temporary-buffer one first. IOW, I think you have that case almost nailed - there is just the special-display/dedicatedness that does not work yet. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 05:06:14 2012 Received: (at 11939) by debbugs.gnu.org; 7 Aug 2012 09:06:14 +0000 Received: from localhost ([127.0.0.1]:38795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syfjx-00054k-Jz for submit@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:14 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:39618) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Syfjv-00054c-67 for 11939@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:12 -0400 Received: (qmail invoked by alias); 07 Aug 2012 08:58:12 -0000 Received: from 62-47-37-156.adsl.highway.telekom.at (EHLO [62.47.37.156]) [62.47.37.156] by mail.gmx.net (mp071) with SMTP; 07 Aug 2012 10:58:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19pvW0t08NpNZEmaiG2ZgKEBFM0m5BILtM0WNYq+P 2xniGtVCWb+SlG Message-ID: <5020D8AA.4010200@gmx.at> Date: Tue, 07 Aug 2012 10:58:18 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' References: !<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> <501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> <501FE2C6.8060204@gmx.at> <268E38CB8E2A453EACA574FB7B00628F@us.oracle.com> In-Reply-To: <268E38CB8E2A453EACA574FB7B00628F@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> >> Tell me the value of the *Help* >> >> window's `quit-restore' parameter. ^^^^^^ >> > >> > Before loading your code there is no such parameter present. >> > Likewise after loading it: no such parameter. >> >> Whenever I call `display-buffer', the window used has the ^^^^^^ >> `quit-restore' parameter set. If it doesn't on your system, >> I don't know. > > I don't know either. I've never seen that frame parameter. > > This has nothing specially to do with the *Help* frame. When I do > (frame-parameters) in ANY frame I do not see a parameter named `quit-restore'. > > Am I missing something? Is this parameter not returned via `frame-parameters' > or something? It's returned via `window-parameters'. > >> >> > IOW, the *Help* frame is apparently no longer >> >> > special-display as it should be. >> >> >> >> It still is and should call `frame-auto-hide-function'. >> > >> > No idea what that means. >> >> `frame-auto-hide-function' is the function called to >> automatically hide frames. > > What I don't understand is your statement "It still is". From appearances it is > not special-display, in the sense that its frame does not seem to be dedicated. The notion "dedicated frame" is an aberration of the Elisp manual. Emacs code nowhere supports such a notion. What "appearances" have to do with dedicatedness is beyond my imagination. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 05:06:21 2012 Received: (at 11939) by debbugs.gnu.org; 7 Aug 2012 09:06:21 +0000 Received: from localhost ([127.0.0.1]:38798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syfk5-000555-6v for submit@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:21 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:55429) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Syfk3-00054v-7f for 11939@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:20 -0400 Received: (qmail invoked by alias); 07 Aug 2012 08:58:20 -0000 Received: from 62-47-37-156.adsl.highway.telekom.at (EHLO [62.47.37.156]) [62.47.37.156] by mail.gmx.net (mp035) with SMTP; 07 Aug 2012 10:58:20 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19XEYIQe6lXOWTvo5PETvWvBovD+K6TTOrcTY4fij 8O8XJ6Y2PgIHgy Message-ID: <5020D8B1.9000305@gmx.at> Date: Tue, 07 Aug 2012 10:58:25 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' References: <5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> <501FE2D4.1 050103@gmx.at> <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> In-Reply-To: <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> If, with emacs -Q, I do >> (progn >> (load ".../with-temp-buffer-window.el") >> (setq special-display-buffer-names '("*Process List*")) >> (display-buffer (get-buffer-create "*Process List*"))) >> >> I get the buffer *Process List* on a separate frame, in a strongly >> dedicated window > > I do too (following that recipe from emacs -Q), the dedicatedness being judged > by trying to do C-x b in it and getting this error message: > > switch-to-buffer: Cannot switch buffers in a dedicated window QED >> and with a `quit-restore' window parameter as >> >> ((quit-restore frame frame # #> *Process List*>)) > > No, there is still no `quit-restore' parameter, according to `frame-parameters'. > >> If I do `quit-window' in that window, the frame is iconified. > > Same here. This is with Emacs 24.1. > >> Tested with Emacs 24.1 release and the latest trunk version I >> was able to build. If you get different results, there's nothing I can do. > > HTH. This test does not involve a standalone minibuffer or other things that > are in my setup. But at least you can see that parameter `quit-restore' is > missing. You cannot see that it is not missing. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 05:06:26 2012 Received: (at 11939) by debbugs.gnu.org; 7 Aug 2012 09:06:26 +0000 Received: from localhost ([127.0.0.1]:38802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syfk9-00055K-Hp for submit@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:47536) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Syfk7-00055D-B2 for 11939@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:24 -0400 Received: (qmail invoked by alias); 07 Aug 2012 08:58:25 -0000 Received: from 62-47-37-156.adsl.highway.telekom.at (EHLO [62.47.37.156]) [62.47.37.156] by mail.gmx.net (mp041) with SMTP; 07 Aug 2012 10:58:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/Mx4YeBFnMuwpnGD7HkMjsc/NrN+WePcyc3up0Rd 97tC9dQClNz2PP Message-ID: <5020D8B6.5000701@gmx.at> Date: Tue, 07 Aug 2012 10:58:30 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> In-Reply-To: <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > You seem to be saying that if BUFFER is selected/current, and if input is read > somewhere (where?) - then what? The focus gets automatically redirected to the > minibuffer frame? A BUFFER is not selected, only a window or a frame is. I say that when a window on a minibuffer-less frame is selected and its buffer is current at the time a `yes-or-no-p' question is asked, focus for reading input from the minibuffer gets redirected to a minibuffer-equipped frame. > This is not about reading input with BUFFER selected/current. The idea is to > have the _previously_ selected buffer be selected/current, while input is read > from the minibuffer. The idea is not to make BUFFER selected/current, but just > to display it. I don't talk about ideas. I talk about the current implementation of dialogs that read text from the minibuffer. > Beyond that, that sentence of mine was shorthand. It (apparently) is not enough > that the focus be redirected once, at some point, to the minibuffer frame. It > needs to either remain there (somehow preventing MS Windows from moving it away) > or be put back there (after MS Windows moves it to BUFFER's frame). Focus redirection is done by Emacs. MS Windows won't redirect focus. > IOW, even > if redirection is happening now as it should, it is not sufficient if, after > that redirection to the minibuffer, the OS changes the focus again (to the new > frame). Any redirection is permanent for a frame until it's explicitly changed by Emacs. >> IIUC you want to modify the behavior of `yes-or-no-p' to >> redirect frame focus in your sense. > > I don't know why you mention `yes-or-no-p'. This is about reading from the > minibuffer, in general. > > I don't want or not want to modify `yes-or-no-p' or `read-from-minibuffer'. I'm > just saying that if the problem is that we want to display BUFFER, and it gets > displayed in a new frame, and we want to read from the minibuffer, then we do > not want, for that minibuffer reading, the input focus to be in BUFFER's frame. Above you say that > It (apparently) is not enough > that the focus be redirected once, at some point, to the minibuffer frame. so you want to modify `yes-or-no-p' or `read-from-minibuffer'. > Yes, when reading from the minibuffer is initiated, > the minibuffer frame should get the focus. But the user (or Emacs) should not > be prevented from switching the focus to another frame. > > All that we are trying to prevent or remedy is the focus switching to another > (new) frame by the OS. We should not be preventing either Emacs or the user > from switching focus to another frame, just because the minibuffer is active. > > That is the only point I was trying to make here. And my point is that beyond the initial redirection the mechanism reading keyboard events is responsible for providing such behavior. > I did not know where you were asking the question. By that, I assume you mean > that the new frame is selected (and has the focus?) when you invoke > `yes-or-no-p'. Is that right? I temporarily select the new frame when I invoke `yes-or-no-p'. The new frame will be selected again by `handle-switch-frame' if and when Emacs is notified by the OS. > Just for my info, why does it matter where `yes-or-no-p' is invoked? _Should_ > it matter, or is it just a fact that we must live with that it does matter? It does matter if and when the selected frame does not have a minibuffer and I want to redirect focus to a minibuffer frame. >> > Yes, it is more restrictive than the actual problem encountered. >> > As I said, it might suffice in practice, but there is nothing in the >> > problem description that requires that the buffer itself be temporary. >> >> I have to kill the buffer to remove the frame. > > I don't understand why, but probably I don't need to understand everything. Why > doesn't `delete-frame' do what you need? Because the window is "quit" when the user is done with the dialog. `quit-window' deletes the frame only if the buffer is killed or `frame-auto-hide-function' takes over. >> And I have to remove the frame because you complained that >> `save-window-excursion' cannot remove a popped up frame. > > Hm. I don't recall that at all, but I believe you that I did. Was that in some > other thread? In the thread on the behavior of `dired-mark-pop-up' IIRC. >> If we use `frame-auto-hide-function', the caller does not have to kill >> the buffer and there's no need to make this construct work >> for temporary buffers only. > > That sounds good to me. Perhaps I'm missing something. I don't want to steer > you down the wrong path, but what you say here sounds good to me. > > If the more general case can be handled, then the more restrictive case > (temporary buffer, not just temporary display) could presumably be handled also, > as a subcase, no? Or even if not as a subcase, as a separate case. > > IOW, if possible it would be good to have both possibilities, so a programmer > could get the right behavior for a given context: If s?he wants that buffer to > be temporary, then call a construct that treats it as such (killing it). If > s?he wants that buffer not to be temporary and only its display to be temporary > then call a construct that does that instead. > >> > Anyway, let's talk about this later. >> >> It's your choice. > > Can we have both possibilities? > > If not, let's get the temporary-buffer one first. IOW, I think you have that > case almost nailed - there is just the special-display/dedicatedness that does > not work yet. Then have a look at what happens there. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 09:48:07 2012 Received: (at 11939) by debbugs.gnu.org; 7 Aug 2012 13:48:07 +0000 Received: from localhost ([127.0.0.1]:39111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syk8l-00040r-55 for submit@debbugs.gnu.org; Tue, 07 Aug 2012 09:48:07 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:33928) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syk8h-00040j-TF for 11939@debbugs.gnu.org; Tue, 07 Aug 2012 09:48:05 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q77De2DX028264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 13:40:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q77De0hB015819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 13:40:01 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q77De0tc019803; Tue, 7 Aug 2012 08:40:00 -0500 Received: from dradamslap1 (/10.159.219.109) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Aug 2012 06:39:59 -0700 From: "Drew Adams" To: "'martin rudalics'" References: !<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at> <501BAAB0.1020!807@gmx! .at> <6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com> <501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281ABE6C82A8CA70E@us.oracle.com> <501FE2C6.8060204@gmx.at> <268E38CB8E2A453EACA574FB7B00628F@us.oracle.com> <5020D8AA.4010200@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes' Date: Tue, 7 Aug 2012 06:39:56 -0700 Message-ID: <33B57B2E0F8147CC9B2B23B255977E85@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac10eshdNd7vAf0kTxKRQdWj32B5vgAJSW9w In-Reply-To: <5020D8AA.4010200@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > This has nothing specially to do with the *Help* frame. When I do > > (frame-parameters) in ANY frame I do not see a parameter > > named `quit-restore'. > > > > Am I missing something? Is this parameter not returned > > via `frame-parameters' or something? > > It's returned via `window-parameters'. (window-parameters) returns nil. In every window I've tried so far. Let me know if there is some particular test you want me to make. > >> >> > IOW, the *Help* frame is apparently no longer > >> >> > special-display as it should be. > >> >> > >> >> It still is and should call `frame-auto-hide-function'. > >> > > >> > No idea what that means. > >> > >> `frame-auto-hide-function' is the function called to > >> automatically hide frames. > > > > What I don't understand is your statement "It still is". > > From appearances it is not special-display, in the sense that its > > frame does not seem to be dedicated. > > The notion "dedicated frame" is an aberration of the Elisp manual. > Emacs code nowhere supports such a notion. If you want to describe the phenomenon in more accurate terms, please do so. I simply meant, as should have been clear from the context, that _the window in which the buffer is displayed_ does not seem to be dedicated. Since the frame is a one-window frame, I spoke informally of its _frame_ not seeming to be dedicated. I'm all for being more precise in the language if you think it helps our communication. Feel free to express things more precisely and I will try to follow your lead. But let's not try to be pedantic to no good end. I think you know full well what I was saying, no? The buffer was replaced in its window by another buffer. > What "appearances" have to do with dedicatedness is beyond my imagination. Substitute "behavior" for "appearances", if you like. I think you understand what I am saying. The point is that it should not be possible for another buffer to take the place of a special-display buffer in its window. The window should be dedicated. And that is not what I am seeing (after loading your code). Everywhere that a buffer (in my setup) would normally be special-display, hence its window would be dedicated, it is not so after I load your code. No buffer that should be special-display is so, in the sense that no buffer's window is dedicated, as shown by the buffer being replaced in that window by another. That last phrase is, as should have been obvious, what I meant by "from appearances". And I only added "from appearances" because you are apparently (from appearances ;-)) insisting that the buffer _is_ special-display. If it is in fact special-display, in some sense that I am not familiar with, then at least _from appearances_, with my understanding of special-display, it is not. And by that I mean that it does not appear to behave as a special-display buffer should behave wrt having a dedicated window: its window does not seem to be dedicated. Clear enough now? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 10:07:24 2012 Received: (at 11939) by debbugs.gnu.org; 7 Aug 2012 14:07:24 +0000 Received: from localhost ([127.0.0.1]:39800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SykRQ-0004cb-7P for submit@debbugs.gnu.org; Tue, 07 Aug 2012 10:07:24 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:48855) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SykRO-0004cU-VE for 11939@debbugs.gnu.org; Tue, 07 Aug 2012 10:07:23 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q77DxMr5011077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 13:59:23 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q77DxMrE009278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 13:59:22 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q77DxL9S030559; Tue, 7 Aug 2012 08:59:21 -0500 Received: from dradamslap1 (/10.159.219.109) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Aug 2012 06:59:22 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> <50! 20D8B6.5000701@gmx.at > Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Tue, 7 Aug 2012 06:59:18 -0700 Message-ID: <254E2E4A521F4250A06349AD44BEEE63@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac10es7rjRLrtdwBRXyZbwvuTKgQzAAKB7Ww In-Reply-To: <5020D8B6.5000701@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> > there is nothing in the problem description that > >> > requires that the buffer itself be temporary. > >> > >> I have to kill the buffer to remove the frame. > > > > Why doesn't `delete-frame' do what you need? > > Because the window is "quit" when the user is done with the dialog. > `quit-window' deletes the frame only if the buffer is killed or > `frame-auto-hide-function' takes over. You don't say why `delete-frame' would not do what you need. You say that `quit-window' needs to have the buffer killed (or ... `f-a-h-f'...) for it to delete the frame. What requires you to use `quit-window' and not `delete-frame'? Just asking, to understand. > > Can we have both possibilities? > > > > If not, let's get the temporary-buffer one first. IOW, I > > think you have that case almost nailed - there is just the > > special-display/dedicatedness that does not work yet. > > Then have a look at what happens there. I don't know what you are requesting. What else do you want me to do? I tried your code and reported on it. I will try it more if the breaking of special-display buffers (non-dedicated windows) is fixed. That is the only problem with it that I have encountered so far. But that prevents me from really using it more to see if there are other problems. Can you fix that problem? Is there something more that you would like me to check, which would help you understand that problem? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 08 03:15:53 2012 Received: (at 11939) by debbugs.gnu.org; 8 Aug 2012 07:15:53 +0000 Received: from localhost ([127.0.0.1]:40966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz0Ui-0003zq-Jp for submit@debbugs.gnu.org; Wed, 08 Aug 2012 03:15:53 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:37628) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sz0Uf-0003zi-P6 for 11939@debbugs.gnu.org; Wed, 08 Aug 2012 03:15:50 -0400 Received: (qmail invoked by alias); 08 Aug 2012 07:07:46 -0000 Received: from 62-47-63-60.adsl.highway.telekom.at (EHLO [62.47.63.60]) [62.47.63.60] by mail.gmx.net (mp038) with SMTP; 08 Aug 2012 09:07:46 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19EgxVIiR5EQ5Y35e3wB09zSClsLbLcgUITZYL3Qx 2R4auSbet6NAZQ Message-ID: <5022103E.6060502@gmx.at> Date: Wed, 08 Aug 2012 09:07:42 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' References: <5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> <501FE2D4.1 050103@gmx.at> <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> In-Reply-To: <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > (window-parameters) returns nil. In every window I've tried so far. Let me > know if there is some particular test you want me to make. In your previous reply you wrote: >> If, with emacs -Q, I do >> (progn >> (load ".../with-temp-buffer-window.el") >> (setq special-display-buffer-names '("*Process List*")) >> (display-buffer (get-buffer-create "*Process List*"))) >> >> I get the buffer *Process List* on a separate frame, in a strongly >> dedicated window > > I do too (following that recipe from emacs -Q), the dedicatedness being judged > by trying to do C-x b in it and getting this error message: > > switch-to-buffer: Cannot switch buffers in a dedicated window > >> and with a `quit-restore' window parameter as >> >> ((quit-restore frame frame # #> *Process List*>)) > > No, there is still no `quit-restore' parameter, according to `frame-parameters'. > >> If I do `quit-window' in that window, the frame is iconified. > > Same here. This is with Emacs 24.1. > >> Tested with Emacs 24.1 release and the latest trunk version I >> was able to build. If you get different results, there's nothing I can do. > > HTH. This test does not involve a standalone minibuffer or other things that > are in my setup. But at least you can see that parameter `quit-restore' is > missing. So according to that reply, special display works on your system, the window gets dedicated and the frame iconified. You insisted on the absence of a value for the `quit-restore' window parameter but maybe you can have another look once you manage how to find it. Sections 28.16 and 28.24 of the Elisp manual might help you in this regard. So the only remaining issue is the familiar one: Go through your setup and check why the window does not get dedicated and the `quit-restore' window parameter is not assigned. > Clear enough now? Judge by yourself. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 08 03:16:07 2012 Received: (at 11939) by debbugs.gnu.org; 8 Aug 2012 07:16:07 +0000 Received: from localhost ([127.0.0.1]:40970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz0Uv-00040c-Kd for submit@debbugs.gnu.org; Wed, 08 Aug 2012 03:16:06 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:49933) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sz0Ut-00040L-5H for 11939@debbugs.gnu.org; Wed, 08 Aug 2012 03:16:04 -0400 Received: (qmail invoked by alias); 08 Aug 2012 07:07:59 -0000 Received: from 62-47-63-60.adsl.highway.telekom.at (EHLO [62.47.63.60]) [62.47.63.60] by mail.gmx.net (mp041) with SMTP; 08 Aug 2012 09:07:59 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+miT45urOmyShVbh53E+vkP96+cFv4y00mzkjTMH DGZPLGniOPM7J/ Message-ID: <5022104C.8080802@gmx.at> Date: Wed, 08 Aug 2012 09:07:56 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: !<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> <50! 20D8B6.5000701@gmx.at > <254E2E4A521F4250A06349AD44BEEE63@us.oracle.com> In-Reply-To: <254E2E4A521F4250A06349AD44BEEE63@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > What requires you to use `quit-window' and not `delete-frame'? Just asking, to > understand. I cannot use `delete-frame' because there might be other windows on the frame or because this might be the only visible frame. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 08 12:26:58 2012 Received: (at 11939) by debbugs.gnu.org; 8 Aug 2012 16:26:58 +0000 Received: from localhost ([127.0.0.1]:42626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz961-0002is-KU for submit@debbugs.gnu.org; Wed, 08 Aug 2012 12:26:58 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:16832) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz95x-0002ij-Vn for 11939@debbugs.gnu.org; Wed, 08 Aug 2012 12:26:55 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q78GIllu005372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 16:18:48 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q78GIlRN028044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 16:18:47 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q78GIlPp004219; Wed, 8 Aug 2012 11:18:47 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Aug 2012 09:18:46 -0700 From: "Drew Adams" To: "'martin rudalics'" References: !<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> <50! 20D8B6.5000701@gmx.at > <254E2E4A521F4250A06349AD44BEEE63@us.oracle.co! ! m> <5022104C.808080 2@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Wed, 8 Aug 2012 09:18:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5022104C.8080802@gmx.at> Thread-Index: Ac11NI23rmpUseZtS7Cnh5iq76kgUgARCgaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > What requires you to use `quit-window' and not > > `delete-frame'? Just asking, to understand. > > I cannot use `delete-frame' because there might be other > windows on the frame or because this might be the only visible frame. But those conditions can be tested, no? IOW, it seems to me that if we are talking about a situation where the buffer is to be kept but its display is to be removed, there are ways of doing that. You will no doubt find better ways to do it (e.g., at least a different test from `one-window-p'), but FWIW I use code like the following, depending on the context: 1. (if (one-window-p t) (delete-frame) (delete-window)) 2. (if (and (one-window-p t) (cdr (visible-frame-list))) (delete-frame) ; Sole window but not sole visible frame. (delete-window (selected-window))) 3. (defun browse-kill-ring-quit-deletes-window/frame () "Bury buffer. Delete window or, if dedicated, frame. Useful as customized value of `browse-kill-ring-quit-action'." (let ((buf (current-buffer)) (sole-window-p (eq (selected-window) (frame-root-window)))) (cond ((and sole-window-p (window-dedicated-p (selected-window))) (delete-frame) (bury-buffer buf)) (t (unless sole-window-p (delete-window)) ;; Avoid BUF as explicit arg to `bury-buffer', ;; since we want to undisplay it. (with-current-buffer buf (bury-buffer)))))) 4. (save-window-excursion (pop-to-buffer list-buf) (condition-case nil ; Ignore error if user deleted window. (if (one-window-p) (delete-frame) (delete-window)) (error nil)) (if list-was-shown (bury-buffer list-buf) (kill-buffer list-buf))) 5. (unwind-protect (save-window-excursion (dired-pop-to-buffer bufname) (setq result (apply function args))) (save-excursion (condition-case nil (progn (select-window (get-buffer-window bufname 0)) (if (one-window-p) (delete-frame) (delete-window))) (error nil))) (bury-buffer bufname)) 6. (or (fboundp 'old-delete-window) (fset 'old-delete-window (symbol-function 'delete-window))) (defun delete-window (&optional window) "Remove WINDOW from the display. Default is `selected-window'. If WINDOW is the only one in its frame, then `delete-frame' too." (interactive) (save-current-buffer (setq window (or window (selected-window))) (select-window window) (if (one-window-p t) (delete-frame) (old-delete-window (selected-window))))) 7. (defun delete/iconify-window (&optional window frame-p) "Delete or iconify WINDOW (default: `selected-window'). If WINDOW is the only one in its frame (`one-window-p'), then optional arg FRAME-P determines the behavior regarding the frame, as follows: If FRAME-P is nil, then the frame is deleted (with the window). If FRAME-P is t, then the frame is iconified. If FRAME-P is a symbol naming a function, the function is applied to WINDOW as its only arg. If the result is nil, then the frame is deleted. If the result is non-nil, then the frame is iconified. If FRAME-P is anything else, then behavior is as if FRAME-P were the symbol `window-dedicated-p': the frame is iconified if WINDOW is dedicated, otherwise the frame is deleted. Interactively, FRAME-P depends on the prefix arg, as follows: Without a prefix arg (prefix = nil), FRAME-P is `window-dedicated-p'. With prefix arg < 0, FRAME-P is t. The frame is iconified. With prefix arg >= 0, FRAME-P is nil. The frame is deleted." (interactive (list nil (if current-prefix-arg (not (natnump (prefix-numeric-value current-prefix-arg))) 'window-dedicated-p))) (setq window (or window (selected-window))) (let ((one-win-p t)) (save-window-excursion (select-window window) (if (one-window-p) (if frame-p (if (eq t frame-p) (iconify-frame) (unless (and (symbolp frame-p) (fboundp frame-p)) (setq frame-p 'window-dedicated-p)) (if (funcall frame-p window) (iconify-frame) (delete-frame))) (delete-frame)) ; Default. (setq one-win-p nil))) ;; Do this outside `save-window-excursion'. (unless one-win-p (old-delete-window window)))) 8. (defun delete-1-window-frames-on (buffer) "Delete all visible 1-window frames showing BUFFER." (interactive (list (read-buffer "Delete visible 1-window frames showing buffer: " (current-buffer) 'EXISTING))) (setq buffer (get-buffer buffer)) (save-excursion (when (buffer-live-p buffer) ; Do nothing if dead buffer. ;; Better to search frames or `get-buffer-window-list'? (dolist (fr (filtered-frame-list `(lambda (fr) (get-buffer-window ',buffer)))) (save-window-excursion (select-frame fr) (when (one-window-p t fr) (delete-frame))))))) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 08 12:28:06 2012 Received: (at 11939) by debbugs.gnu.org; 8 Aug 2012 16:28:06 +0000 Received: from localhost ([127.0.0.1]:42632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz977-0002kn-7a for submit@debbugs.gnu.org; Wed, 08 Aug 2012 12:28:06 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:32838) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz975-0002kg-CR for 11939@debbugs.gnu.org; Wed, 08 Aug 2012 12:28:03 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q78GJu2i020828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 16:19:56 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q78GJtYw007078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 16:19:55 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q78GJtMb005606; Wed, 8 Aug 2012 11:19:55 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Aug 2012 09:19:55 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> <501FE2D4.1 050103@gmx.at> <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> <5022103E.6060502@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' Date: Wed, 8 Aug 2012 09:19:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5022103E.6060502@gmx.at> Thread-Index: Ac11NIQuKtiEfDdAR22ZiotmbgIT6gASJlDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) With the emacs -Q scenario, (window-parameters) shows: ((quit-restore frame frame # #)) > So the only remaining issue is the familiar one: Go through your setup > and check why the window does not get dedicated and the `quit-restore' > window parameter is not assigned. That will unfortunately take a while. And again, it is not just _this_ window that is not dedicated. _No_ windows are dedicated after I load your code. I will try to narrow things down when I get some time. Perhaps you can look from your side, since your code that breaks special display is very small, and especially since you have a good understanding of how it changes things. In addition to, or as an alternative to, trying to narrow my setup (lots of code), I will try narrowing your code, evaluating only pieces of it to see if I can determine what the culprit part is. Any advice wrt narrowing your code? I am unfamiliar with it and how its parts might relate to each other, so any such exercise on my part is pretty much blind, unless you have some guidance to offer. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 08 12:40:49 2012 Received: (at 11939) by debbugs.gnu.org; 8 Aug 2012 16:40:50 +0000 Received: from localhost ([127.0.0.1]:42645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz9JR-00032f-AL for submit@debbugs.gnu.org; Wed, 08 Aug 2012 12:40:49 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:30129) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz9JP-00032Y-FD for 11939@debbugs.gnu.org; Wed, 08 Aug 2012 12:40:48 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q78GWeJk002420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 16:32:41 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q78GWdDL004268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 16:32:39 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q78GWcqs000813; Wed, 8 Aug 2012 11:32:38 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Aug 2012 09:32:38 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes' Date: Wed, 8 Aug 2012 09:32:37 -0700 Message-ID: <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac11NIQuKtiEfDdAR22ZiotmbgIT6gASJlDgAAFMwJA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) FWIW, even without loading your code, with my setup, (window-parameters) always returns nil. I will need to dig further to find out why. Perhaps you can help by telling me what vanilla Emacs code normally changes things so that the value returned is non-nil. IOW, what parts of the Emacs code should be setting this up correctly? That might help me narrow things down to find what code I have that is counteracting that correct setup. I note that in Emacs 23 also (windows-parameters) returns nil for me. (And the function apparently does not exist in Emacs 22.) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 08 12:46:47 2012 Received: (at 11939) by debbugs.gnu.org; 8 Aug 2012 16:46:48 +0000 Received: from localhost ([127.0.0.1]:42664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz9PD-0003D9-HE for submit@debbugs.gnu.org; Wed, 08 Aug 2012 12:46:47 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:42043) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sz9P9-0003Cv-9V for 11939@debbugs.gnu.org; Wed, 08 Aug 2012 12:46:44 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q78GcZLV008975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 16:38:36 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q78GcYgB015291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 16:38:35 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q78GcYij018365; Wed, 8 Aug 2012 11:38:34 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Aug 2012 09:38:34 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle!!.com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' Date: Wed, 8 Aug 2012 09:38:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> Thread-Index: Ac11NIQuKtiEfDdAR22ZiotmbgIT6gASJlDgAAFMwJAAAFXIQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) OK, here is a recipe from emacs -Q. runemacs.exe -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs" You will need to download those two libraries from the wiki: http://www.emacswiki.org/emacs/download/hexrgb.el http://www.emacswiki.org/emacs-en/download/oneonone.el After that, evaluating (window-parameters) in any window (AFAICT) returns nil. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 04:52:55 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 08:52:55 +0000 Received: from localhost ([127.0.0.1]:43710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzOUA-0002lH-T9 for submit@debbugs.gnu.org; Thu, 09 Aug 2012 04:52:55 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:59506) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SzOU8-0002lA-TV for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 04:52:53 -0400 Received: (qmail invoked by alias); 09 Aug 2012 08:44:43 -0000 Received: from 62-47-46-150.adsl.highway.telekom.at (EHLO [62.47.46.150]) [62.47.46.150] by mail.gmx.net (mp069) with SMTP; 09 Aug 2012 10:44:43 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+h4BJ/1qqhsDYEzRarmZ0tmUWOx8Ew4pjo0ezZmy wNfiLvXv0BQ7rJ Message-ID: <5023787A.6020304@gmx.at> Date: Thu, 09 Aug 2012 10:44:42 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' References: <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> <50! 20D8B6.5000701@gmx.at > <254E2E4A521F4250A06349AD44BEEE63@us.oracle.co! ! m> <5022104C.808080 2@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > You will no doubt find better ways to do it (e.g., at least a different test > from `one-window-p'), but FWIW I use code like the following, depending on the > context: None of these is suitable for dealing with the case that a window has been reused by `display-buffer'. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 04:53:05 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 08:53:05 +0000 Received: from localhost ([127.0.0.1]:43715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzOUL-0002m8-6w for submit@debbugs.gnu.org; Thu, 09 Aug 2012 04:53:05 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:35336) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SzOUJ-0002lm-Hf for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 04:53:04 -0400 Received: (qmail invoked by alias); 09 Aug 2012 08:44:54 -0000 Received: from 62-47-46-150.adsl.highway.telekom.at (EHLO [62.47.46.150]) [62.47.46.150] by mail.gmx.net (mp019) with SMTP; 09 Aug 2012 10:44:54 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18I1nY3ncYINo+p34MgQfefOgeHRJDEd++c8OCr7j gU3jzm8S0XKXjd Message-ID: <50237884.9040305@gmx.at> Date: Thu, 09 Aug 2012 10:44:52 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' References: <50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> <501FE2D4.1 050103@gmx.at> <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> <5022103E.6060502@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I will try to narrow things down when I get some time. Perhaps you can look > from your side, since your code that breaks special display is very small, and > especially since you have a good understanding of how it changes things. As the example with emacs -Q demonstrates, my code does not break special display. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 04:53:34 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 08:53:34 +0000 Received: from localhost ([127.0.0.1]:43719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzOUn-0002ml-Dn for submit@debbugs.gnu.org; Thu, 09 Aug 2012 04:53:33 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:57121) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SzOUk-0002md-M7 for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 04:53:32 -0400 Received: (qmail invoked by alias); 09 Aug 2012 08:45:21 -0000 Received: from 62-47-46-150.adsl.highway.telekom.at (EHLO [62.47.46.150]) [62.47.46.150] by mail.gmx.net (mp070) with SMTP; 09 Aug 2012 10:45:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19LbxM2tK1Lw90et5gyoovoXf96FsLuBYj8A4M0oK pK1zea9LBJOt1i Message-ID: <5023789F.9000906@gmx.at> Date: Thu, 09 Aug 2012 10:45:19 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes' References: <548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> In-Reply-To: <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > FWIW, even without loading your code, with my setup, (window-parameters) always > returns nil. I will need to dig further to find out why. > > Perhaps you can help by telling me what vanilla Emacs code normally changes > things so that the value returned is non-nil. `display-buffer-record-window' > IOW, what parts of the Emacs code > should be setting this up correctly? That might help me narrow things down to > find what code I have that is counteracting that correct setup. The doc-string of `special-display-function' tells what should be done. The code of `special-display-popup-frame' shows how this can be done. > I note that in Emacs 23 also (windows-parameters) returns nil for me. (And the > function apparently does not exist in Emacs 22.) `display-buffer-record-window' has been introduced in Emacs 24.1. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 04:53:44 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 08:53:44 +0000 Received: from localhost ([127.0.0.1]:43722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzOUw-0002n5-41 for submit@debbugs.gnu.org; Thu, 09 Aug 2012 04:53:43 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:42007) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SzOUt-0002mx-5q for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 04:53:40 -0400 Received: (qmail invoked by alias); 09 Aug 2012 08:45:29 -0000 Received: from 62-47-46-150.adsl.highway.telekom.at (EHLO [62.47.46.150]) [62.47.46.150] by mail.gmx.net (mp028) with SMTP; 09 Aug 2012 10:45:29 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX185w0cZXJM5x6NgHw8AJErzhsQAgsXMgpCOXbL9P9 4B2izXIk4yGIEy Message-ID: <502378A8.9010707@gmx.at> Date: Thu, 09 Aug 2012 10:45:28 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' References: <501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > OK, here is a recipe from emacs -Q. > > runemacs.exe -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs" > > You will need to download those two libraries from the wiki: > http://www.emacswiki.org/emacs/download/hexrgb.el > http://www.emacswiki.org/emacs-en/download/oneonone.el Not this time. Please try to come up with a self-contained, reasonably small test case. > After that, evaluating (window-parameters) in any window (AFAICT) returns nil. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 18:01:22 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 22:01:22 +0000 Received: from localhost ([127.0.0.1]:45389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzanB-00079p-A4 for submit@debbugs.gnu.org; Thu, 09 Aug 2012 18:01:22 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:22261) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szan9-00079i-FY for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 18:01:20 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79Lr5M0014420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 21:53:06 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79Lr4Nt020811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 21:53:04 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79Lr3AD016218; Thu, 9 Aug 2012 16:53:03 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 14:53:03 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <5023789F.90! 00906@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes' Date: Thu, 9 Aug 2012 14:53:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5023789F.9000906@gmx.at> Thread-Index: Ac12C1Gjaqj2g6gEQZK3UTLsFpA/wQANsI8g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Perhaps you can help by telling me what vanilla Emacs code > > normally changes things so that the value [of (windows-parameters)] > > returned is non-nil. > > `display-buffer-record-window' > > > I note that in Emacs 23 also (windows-parameters) returns nil for me. > > `display-buffer-record-window' has been introduced in Emacs 24.1. How does that make sense? If `display-buffer-record-window' is what makes `windows-parameters' return non-nil, and `windows-parameters' existed back in Emacs 23, and `display-buffer-record-window' did not exist in Emacs 23, then `windows-parameters' would have always returned nil in Emacs 23, no? Why would it exist back then if it always returned nil? Does/did it have side effects or something? And its doc even in Emacs 23 says that it returns a list of elements of form (PARAMETER . VALUE). From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 18:02:17 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 22:02:17 +0000 Received: from localhost ([127.0.0.1]:45393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szao4-0007BJ-V6 for submit@debbugs.gnu.org; Thu, 09 Aug 2012 18:02:17 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:42434) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szao3-0007BB-2i for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 18:02:16 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79Ls1s5000827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 21:54:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79Ls1v2008264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 21:54:01 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79Ls0TE029066; Thu, 9 Aug 2012 16:54:01 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 14:54:00 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx! .at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at> <7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com> <501FE2D4.1 050103@gmx.at> <559D41024BC44EAC92C09DC14E1B7362@us.oracle.com> <5022103E.6060502@gmx.at> <50237884.9040305@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes' Date: Thu, 9 Aug 2012 14:53:59 -0700 Message-ID: <323C235F9AB346408D0AECA969878CB7@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50237884.9040305@gmx.at> Thread-Index: Ac12C0BaHDHeExDcQ3OHUWWczj0n9gAN3CtA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > I will try to narrow things down when I get some time. > > Perhaps you can look from your side, since your code that > > breaks special display is very small, and especially since > > you have a good understanding of how it changes things. > > As the example with emacs -Q demonstrates, my code does not > break special display. No need to be defensive. I was clear in saying that it breaks special display for my setup. That some example with emacs -Q might not be broken does not invalidate the fact that with my setup plus your code it is broken. By "it is broken" I mean that buffers that should have dedicated windows (because they are defined to be special display) do not: other buffers replace them in their windows. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 09 18:02:29 2012 Received: (at 11939) by debbugs.gnu.org; 9 Aug 2012 22:02:29 +0000 Received: from localhost ([127.0.0.1]:45396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzaoH-0007Bg-DE for submit@debbugs.gnu.org; Thu, 09 Aug 2012 18:02:29 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:42544) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzaoF-0007Ba-UZ for 11939@debbugs.gnu.org; Thu, 09 Aug 2012 18:02:28 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79LsFfD000994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 21:54:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79LsEHi029506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 21:54:14 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79LsEC0001040; Thu, 9 Aug 2012 16:54:14 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 14:54:13 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> <50! 20D8B6.5000701@gmx.at > <254E2E4A521F4250A06349AD44BEEE63@us.oracle.co! ! m> <5022104C.808080 2@gmx.at> <5023787A.6 020304@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Thu, 9 Aug 2012 14:54:12 -0700 Message-ID: <1F5C3C29D2774AC794B516B872BF03F1@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5023787A.6020304@gmx.at> Thread-Index: Ac12Czr96rDNpuR/T6WhtEq1j9RACQAN9syg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> I cannot use `delete-frame' because there might be other > >> windows on the frame or because this might be the only > >> visible frame. > > > > You will no doubt find better ways to do it (e.g., at least > > a different test from `one-window-p'), but FWIW I use code > > like the following, depending on the context: > > None of these is suitable for dealing with the case that a window has > been reused by `display-buffer'. Perhaps. But they are all useful in practice to distinguish the one-window case, at least with my setup. IOW, they do the job for me - I have not had any problems with them. I'm afraid I can't offer another suggestion for this particular problem. You are the expert here. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 10 05:42:08 2012 Received: (at 11939) by debbugs.gnu.org; 10 Aug 2012 09:42:08 +0000 Received: from localhost ([127.0.0.1]:45995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzljL-0006tn-Kx for submit@debbugs.gnu.org; Fri, 10 Aug 2012 05:42:08 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:53342) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SzljI-0006te-Qc for 11939@debbugs.gnu.org; Fri, 10 Aug 2012 05:42:06 -0400 Received: (qmail invoked by alias); 10 Aug 2012 09:33:48 -0000 Received: from 62-47-36-71.adsl.highway.telekom.at (EHLO [62.47.36.71]) [62.47.36.71] by mail.gmx.net (mp020) with SMTP; 10 Aug 2012 11:33:48 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19icy8qiyhim4wVch3tUizfCAviGKF5xziInKIp+m ucwT8S3uv2It7q Message-ID: <5024D576.2010904@gmx.at> Date: Fri, 10 Aug 2012 11:33:42 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes' References: <2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281! ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <5023789F.90! 00906@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > Perhaps you can help by telling me what vanilla Emacs code >> > normally changes things so that the value [of (windows-parameters)] >> > returned is non-nil. >> >> `display-buffer-record-window' >> >> > I note that in Emacs 23 also (windows-parameters) returns nil for me. >> >> `display-buffer-record-window' has been introduced in Emacs 24.1. > > How does that make sense? If `display-buffer-record-window' is what makes > `windows-parameters' ... with vanilla Emacs code ... > return non-nil, and `windows-parameters' existed back in > Emacs 23, and `display-buffer-record-window' did not exist in Emacs 23, then > `windows-parameters' would have always returned nil in Emacs 23, no? It would have always returned nil in a vanilla Emacs 23. > Why would it exist back then if it always returned nil? For a user or an application to store values in it. > Does/did it have side > effects or something? Not to my knowledge. > And its doc even in Emacs 23 says that it returns a list > of elements of form (PARAMETER . VALUE). nil is an empty list of elements of form (PARAMETER . VALUE) martin From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 10 13:55:30 2012 Received: (at 11939) by debbugs.gnu.org; 10 Aug 2012 17:55:30 +0000 Received: from localhost ([127.0.0.1]:47325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SztQo-0003Ee-B3 for submit@debbugs.gnu.org; Fri, 10 Aug 2012 13:55:30 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:25003) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SztQl-0003EW-TM for 11939@debbugs.gnu.org; Fri, 10 Aug 2012 13:55:28 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AHl9v7006165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2012 17:47:10 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7AHl83a002967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2012 17:47:09 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7AHl8dh004368; Fri, 10 Aug 2012 12:47:08 -0500 Received: from dradamslap1 (/10.159.221.31) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 10:47:08 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' Date: Fri, 10 Aug 2012 10:47:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-reply-to: <502378A8.9010707@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac12C1cA4ssraxGYTxOK+GPA61RQAQBDfPrg Importance: High X-Message-Flag: Follow up X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Please try to come up with a self-contained, > reasonably small test case. > > > After that, evaluating (window-parameters) in any window > > (AFAICT) returns nil. Digging further I found the problem in my code, which was preventing (window-parameters) from returning non-nil, and also apparently preventing special-display buffers from having dedicated windows. The problem was not due to your code. FYI - I have code that redefines `special-display-popup-frame' (only for Emacs 24+) just so that the frame is fit to the buffer contents. The latest version I had was based on a vanilla Emacs snapshot that was old - it did not have a call to `display-buffer-record-window'. With that code updated now per the latest Emacs 24 sources, `window-parameters' does not always return nil, and special-display buffers seem to have dedicated windows as they should. So I think this brings some closure. I do hope you will merge your code into Emacs. If there is something additional you would like me to test, let me know. This will be a big improvement, for me at least. Thank you for your efforts. --- BTW: Do you not think that there should be a call to `raise-frame' in `s-d-p-f' before returning the WINDOW in the case where ARGS is a list (FUNCTION . FN-ARGS)? Should it not _always_ be the case that `special-display-popup-frame' pops up the buffer in a frame, i.e., ensures that its display is clearly visible? Even if the buffer is already displayed somewhere, shouldn't a frame that it is displayed in be raised? In particular, the frame that is the `window-frame' of the window returned by FUNCTION applied to its args? --- NOTE: If the frame fitting did not need to be done in two different cases (ARGS with FUNCTION and otherwise), hence in two different places in the `special-display-popup-frame' code, then I might just use `defadvice'. Or if `s-d-p-f' provided a hook in those two places then I would just do the frame fitting on that hook. I do not especially _like_ redefinining vanilla functions... I do not need to redefine `s-d-p-f' in prior Emacs versions. That is presumably because I already have frame-fitting on existing hooks. Something in the vanilla changes for Emacs 24 made it so that frame fitting was no longer occurring in all cases, which led me to redefine `s-d-p-f'. I'm not sure which hooks were sufficient before. I use, e.g., `after-make-frame-functions' and `temp-buffer-show-hook'. I also redefine `switch-to-buffer' so that if the selected window is dedicated (`window-dedicated-p') then it uses another window, regardless of argument FORCE-SAME-WINDOW. (If it is not dedicated then the vanilla `s-to-b' code is invoked.) From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 11 05:39:31 2012 Received: (at 11939) by debbugs.gnu.org; 11 Aug 2012 09:39:31 +0000 Received: from localhost ([127.0.0.1]:48190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T08AN-0001V0-0v for submit@debbugs.gnu.org; Sat, 11 Aug 2012 05:39:31 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:34837) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T08AJ-0001Ur-Pv for 11939@debbugs.gnu.org; Sat, 11 Aug 2012 05:39:29 -0400 Received: (qmail invoked by alias); 11 Aug 2012 09:31:06 -0000 Received: from 62-47-60-244.adsl.highway.telekom.at (EHLO [62.47.60.244]) [62.47.60.244] by mail.gmx.net (mp071) with SMTP; 11 Aug 2012 11:31:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18ZHJ44gV0ZEIVEiCNmOWnb5XqlK1ETc5XKPycI2k 4XL7uOgD6Fvuvd Message-ID: <50262666.2060809@gmx.at> Date: Sat, 11 Aug 2012 11:31:18 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' References: <5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > BTW: Do you not think that there should be a call to `raise-frame' in `s-d-p-f' > before returning the WINDOW in the case where ARGS is a list (FUNCTION . > FN-ARGS)? > > Should it not _always_ be the case that `special-display-popup-frame' pops up > the buffer in a frame, i.e., ensures that its display is clearly visible? Its doc-string says: "If ARGS is a list whose car is a symbol, use (car ARGS) as a function to do the work." I suppose that "do the work" means that function is entirely responsible for doing what you want. In any other case, `special-display-popup-frame' should do what you want. > Even if the buffer is already displayed somewhere, shouldn't a frame that it is > displayed in be raised? `special-display-popup-frame' does that when it finds a window displaying the buffer. > In particular, the frame that is the `window-frame' of > the window returned by FUNCTION applied to its args? I suppose FUNCTION should be held responsible for raising the frame if needed. > NOTE: If the frame fitting did not need to be done in two different cases (ARGS > with FUNCTION and otherwise), hence in two different places in the > `special-display-popup-frame' code, then I might just use `defadvice'. Or if > `s-d-p-f' provided a hook in those two places then I would just do the frame > fitting on that hook. I do not especially _like_ redefinining vanilla > functions... > > I do not need to redefine `s-d-p-f' in prior Emacs versions. That is presumably > because I already have frame-fitting on existing hooks. Something in the > vanilla changes for Emacs 24 made it so that frame fitting was no longer > occurring in all cases, which led me to redefine `s-d-p-f'. I'm not sure which > hooks were sufficient before. I use, e.g., `after-make-frame-functions' and > `temp-buffer-show-hook'. > > I also redefine `switch-to-buffer' so that if the selected window is dedicated > (`window-dedicated-p') then it uses another window, regardless of argument > FORCE-SAME-WINDOW. (If it is not dedicated then the vanilla `s-to-b' code is > invoked.) I don't understand why you insist on using, advising, or redefining `special-display-popup-frame'. Customizing `display-buffer-base-action' should be all you want. BTW: With with-temp-buffer-window.el it's possible to customize `temp-buffer-resize-frames' and automatically resize temporary frames. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 11 13:07:03 2012 Received: (at 11939) by debbugs.gnu.org; 11 Aug 2012 17:07:03 +0000 Received: from localhost ([127.0.0.1]:49733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0F9S-0004Jg-P4 for submit@debbugs.gnu.org; Sat, 11 Aug 2012 13:07:03 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:34998) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0F9Q-0004JH-IJ for 11939@debbugs.gnu.org; Sat, 11 Aug 2012 13:07:01 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7BGwapk025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 16:58:37 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7BGwagF023484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 16:58:36 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7BGwaGY008096; Sat, 11 Aug 2012 11:58:36 -0500 Received: from dradamslap1 (/10.159.168.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Aug 2012 09:58:36 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' Date: Sat, 11 Aug 2012 09:58:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50262666.2060809@gmx.at> Thread-Index: Ac13pAqcRKOqp2MTQ5eCMZz5OP56nwAK/fQw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > Should it not _always_ be the case that > > `special-display-popup-frame' pops up the buffer in a frame, > > i.e., ensures that its display is clearly visible? > > Its doc-string says... Yes, I know what the doc string says. I raised a question about the design: the desired behavior. The doc string would then follow from whatever was decided about the behavior. > I suppose FUNCTION should be held responsible for raising the frame if > needed. That's just the question I raised - should it? That is the current design (hence the doc string). But is it the best approach? Dunno. In that case, `s-d-p-f' gets completely replaced and adds nothing to the party. It does not necessarily pop up a frame showing the buffer. The FUNCTION passed as (car ARGS) is presumed to "do the work". But "the work" has no meaning, not even a suggested meaning - FUNCTION might well not raise the frame or even display the buffer. That's OK (it's one approach). But is it reasonable to suppose that there are many (any?) use cases where you would not want the frame raised? To be clear: I do not have a problem with the current approach (and I've now changed my version, likewise, to not raise (or fit) the frame in that case). But if we keep that design then it might be clearer to state what "the work" is generally expected to be, i.e., that it typically means displaying the buffer and raising its frame. E.g.: If ARGS is a list whose car is a symbol then use (car ARGS) as a function to do the work: display the buffer and raise its frame. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pass it BUFFER as first argument, and (cdr ARGS) as the rest of the arguments. (See also bug #8853 wrt the last phrase - this regression is still not fixed.) > I don't understand why you insist on using, advising, or redefining > `special-display-popup-frame'. Customizing > `display-buffer-base-action' should be all you want. What part of must-work-with-releases-other-than-just-24 did you not get? You add a new knob, such as `display-buffer-base-action', and you think that that takes care of everything. Maybe it does for Emacs 24, but the knob does not even exist prior to 24. You are concerned only with the latest Emacs release. I, like many (most?) users, am not. > BTW: With with-temp-buffer-window.el it's possible to customize > `temp-buffer-resize-frames' and automatically resize temporary frames. OK, good to know. My need is not just for temporary frames (whatever that term might mean), and it is generally not only for Emacs 24+. But that is definitely good to know. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 12 06:39:37 2012 Received: (at 11939) by debbugs.gnu.org; 12 Aug 2012 10:39:38 +0000 Received: from localhost ([127.0.0.1]:50638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0Va5-00066W-62 for submit@debbugs.gnu.org; Sun, 12 Aug 2012 06:39:37 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:36676) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T0Va2-00066O-3R for 11939@debbugs.gnu.org; Sun, 12 Aug 2012 06:39:35 -0400 Received: (qmail invoked by alias); 12 Aug 2012 10:31:06 -0000 Received: from 62-47-36-185.adsl.highway.telekom.at (EHLO [62.47.36.185]) [62.47.36.185] by mail.gmx.net (mp039) with SMTP; 12 Aug 2012 12:31:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+P0NIJUa6PvAbbSysnku6JXzWsOaE45i56vNIZco u780UmkDQjPJI/ Message-ID: <502785DF.1040200@gmx.at> Date: Sun, 12 Aug 2012 12:30:55 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' References: <501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> I don't understand why you insist on using, advising, or redefining >> `special-display-popup-frame'. Customizing >> `display-buffer-base-action' should be all you want. > > What part of must-work-with-releases-other-than-just-24 did you not get? > > You add a new knob, such as `display-buffer-base-action', and you think that > that takes care of everything. Maybe it does for Emacs 24, but the knob does > not even exist prior to 24. You are concerned only with the latest Emacs > release. I, like many (most?) users, am not. Changing `special-display-popup-frame' for >= 24.2 would not affect its behavior with < 24.2. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 12 11:11:47 2012 Received: (at 11939) by debbugs.gnu.org; 12 Aug 2012 15:11:47 +0000 Received: from localhost ([127.0.0.1]:51450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0ZpT-0004nG-Cs for submit@debbugs.gnu.org; Sun, 12 Aug 2012 11:11:47 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:48393) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0ZpR-0004n9-6M for 11939@debbugs.gnu.org; Sun, 12 Aug 2012 11:11:46 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7CF3Fr5029365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Aug 2012 15:03:16 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7CF3DQv002234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2012 15:03:15 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7CF3DdH016842; Sun, 12 Aug 2012 10:03:13 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Aug 2012 08:03:12 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> <502! 785DF.1040200@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' Date: Sun, 12 Aug 2012 08:03:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <502785DF.1040200@gmx.at> Thread-Index: Ac14dZbKrc3Ii7LXRGSoYZzM5j2IyQAH51fg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > >> > I do not especially _like_ redefinining vanilla functions... > >> > >> I don't understand why you insist on using, advising, or > >> redefining `special-display-popup-frame'. Customizing > >> `display-buffer-base-action' should be all you want. > > > > What part of must-work-with-releases-other-than-just-24 > > did you not get? > > Changing `special-display-popup-frame' for >= 24.2 would not > affect its behavior with < 24.2. Fair enough. I could provide a separate solution for >= 24.2. Agreed. And I'd be glad to learn how. Perhaps I will provide a separate 24.2+ solution, once we have 24.2. By that time, based on past experience, it's quite possible that Emacs Dev will have changed things in this area once again - perhaps even radically (again). But I'm certainly open to finding a solution that does not require redefining `special-display-popup-frame'. However: 1. `display-buffer-base-action' is a user option. Users can set it to anything, including things that do not do what my redefinition of `s-d-p-f' does, which is to invoke `fit-frame'. Advising me to customize `display-buffer-base-action' does not speak to providing such functionality in a library for other users. 2. I do not yet understand `display-buffer-base-action' enough to know _how_ it might be changed to DTRT here. [*] 3. Wrt #2, in particular, redefining `s-d-p-f' affects only those places in Emacs that call `s-d-p-f', in particular, special-display stuff. IIUC, `display-buffer-base-action' is general and affects _all_ calls (and only calls) to `display-buffer'. How to make it affect only what `s-d-p-f' affects? 4. Wrt #2 & #3: Please let me know precisely how you think I could, now (e.g., for recent Emacs 24 builds plus your code, which I hope you will merge soon), use `display-buffer-base-action' to get the effect of my redefinition of `s-d-p-f'. I'm open to your suggestion, but so far it is not concrete enough for me to see how `display-buffer-base-action' might replace redefining `s-d-p-f', even for Emacs >= 24.2. What is no doubt obvious to you is not at all clear to me. --- [*] FWIW, the `display-buffer-base-action' doc string is not very helpful: "It should be a cons cell (FUNCTION . ALIST), where FUNCTION is a function or a list of functions. Each function should accept two arguments: a buffer to display and an alist similar to ALIST." What does "similar" to ALIST mean here? Plus, all the doc tells us is the _form_ of the option value, not what the value means or how it is used. Yes, it sends us off to the doc for `display-buffer', but that is a labyrinthine jungle. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 13 03:21:38 2012 Received: (at 11939) by debbugs.gnu.org; 13 Aug 2012 07:21:38 +0000 Received: from localhost ([127.0.0.1]:52437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0oy1-00039h-Fa for submit@debbugs.gnu.org; Mon, 13 Aug 2012 03:21:37 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:58440) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T0oxy-00039X-Kl for 11939@debbugs.gnu.org; Mon, 13 Aug 2012 03:21:35 -0400 Received: (qmail invoked by alias); 13 Aug 2012 07:13:02 -0000 Received: from 62-47-55-185.adsl.highway.telekom.at (EHLO [62.47.55.185]) [62.47.55.185] by mail.gmx.net (mp012) with SMTP; 13 Aug 2012 09:13:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/kuxt0dSvks8RKXPWi9NUlWwTgRwSMdLj+ag3cQq nkVP2iVeBRsu+q Message-ID: <5028A8FD.60705@gmx.at> Date: Mon, 13 Aug 2012 09:13:01 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' References: <50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> <502! 785DF.1040200@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Changing `special-display-popup-frame' for >= 24.2 would not >> affect its behavior with < 24.2. > > Fair enough. I could provide a separate solution for >= 24.2. For > 24.2 (since yesterday). > Agreed. And I'd be glad to learn how. > > Perhaps I will provide a separate 24.2+ solution, once we have 24.2. By that > time, based on past experience, it's quite possible that Emacs Dev will have > changed things in this area once again - perhaps even radically (again). But > I'm certainly open to finding a solution that does not require redefining > `special-display-popup-frame'. > > However: > > 1. `display-buffer-base-action' is a user option. Users can set it to anything, > including things that do not do what my redefinition of `s-d-p-f' does, which is > to invoke `fit-frame'. Advising me to customize `display-buffer-base-action' > does not speak to providing such functionality in a library for other users. I said that "customizing `display-buffer-base-action' should be all you want" because I didn't know that you want to provide that "functionality in a library for other users'. In such case you probably want to write some function derived from your advised, redefined `special-display-popup-frame', include it in that library and tell people to call that function by customizing their `display-buffer-alist' appropriately. > 2. I do not yet understand `display-buffer-base-action' enough to know _how_ it > might be changed to DTRT here. [*] > > 3. Wrt #2, in particular, redefining `s-d-p-f' affects only those places in > Emacs that call `s-d-p-f', in particular, special-display stuff. IIUC, > `display-buffer-base-action' is general and affects _all_ calls (and only calls) > to `display-buffer'. How to make it affect only what `s-d-p-f' affects? > > 4. Wrt #2 & #3: Please let me know precisely how you think I could, now (e.g., > for recent Emacs 24 builds plus your code, which I hope you will merge soon), > use `display-buffer-base-action' to get the effect of my redefinition of > `s-d-p-f'. > > I'm open to your suggestion, but so far it is not concrete enough for me to see > how `display-buffer-base-action' might replace redefining `s-d-p-f', even for > Emacs >= 24.2. What is no doubt obvious to you is not at all clear to me. It's not obvious to me and I have only a rudimentary solution where I set `display-buffer-base-action' to a function that always splits the selected window. And I do the remaining tweaks by customizing `display-buffer-alist' in some rudimentary manner too. As long as we don't have any feedback from users who start experimenting with this, there won't be much progress indeed. In particular if they insist on tweaking the behavior of `special-display-popup-frame' instead ... > [*] FWIW, the `display-buffer-base-action' doc string is not very helpful: > > "It should be a cons cell (FUNCTION . ALIST), where FUNCTION is a > function or a list of functions. Each function should accept two > arguments: a buffer to display and an alist similar to ALIST." > > What does "similar" to ALIST mean here? Plus, all the doc tells us is the > _form_ of the option value, not what the value means or how it is used. Yes, it > sends us off to the doc for `display-buffer', but that is a labyrinthine jungle. It looks slightly circular indeed. But I believe that you should be able to easily digest the two alist values that currently do have a special meaning (`inhibit-same-window' and `reusable-frames'). The main advantage of ALIST is that in your library you can call `display-buffer' with some special-purpose alist elements and have the function specified via `display-buffer-alist' recognize these values. This means that you can get any special behavior when and where you (or your users) want it, while providing standard behavior for those who do not. With Emacs 23, you could specify special behavior only via `special-display-frame-alist' and the special case entries of `special-display-buffer-names' and `special-display-regexps' in some very restricted manner - use the same window, a window on the same frame, or a new frame with some predefined properties. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 13 10:00:42 2012 Received: (at 11939) by debbugs.gnu.org; 13 Aug 2012 14:00:42 +0000 Received: from localhost ([127.0.0.1]:53501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0vCD-0005gW-TW for submit@debbugs.gnu.org; Mon, 13 Aug 2012 10:00:42 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:32746) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0vCA-0005gO-Nm for 11939@debbugs.gnu.org; Mon, 13 Aug 2012 10:00:40 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DDq47S031473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Aug 2012 13:52:05 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7DDq3OD006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 13:52:04 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7DDq3XL006199; Mon, 13 Aug 2012 08:52:03 -0500 Received: from dradamslap1 (/10.159.171.13) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Aug 2012 06:52:03 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> <502! 785DF.1040200@gmx.at> <5028A8FD.60705@gmx .at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' Date: Mon, 13 Aug 2012 06:51:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5028A8FD.60705@gmx.at> Thread-Index: Ac15IxZik1v5ur83S6KlJS2YrcJW1AAL/lSQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > The main advantage of ALIST is that in your library you can call > `display-buffer' with some special-purpose alist elements and > have the function specified via `display-buffer-alist' recognize > these values. This, I suspect, is a fundamental misunderstanding behind this change (and some other changes in Emacs over the last few years). Let me politely suggest that such changes are misguided if the designers think that this is always the way to go and the answer to everything. In particular, wanting to deprecate and replace, rather than supplement, previous constructs, is a mistake, IMHO. Farther down the road I might see the light and change my mind, but that is my honest point of view at present. As you know, I am no expert on this stuff - I barely understand the new approach, certainly so wrt details. I have some experience with parts of the "old" approach, and I've seen some of the pain you've gone through to try to enable the new to handle some of the straightforward cases of the old. It has not always been so simple, has it? You've succeeded, AFAICT, but it has not been obvious. Granted, part of the difficulty is that you were not familiar with some of the "old" (use cases, for example). Still, it is not clear to me that the new is a reasonable, straightforward replacement for the "old". Here's the misunderstanding, as I see it: "You can call `display-buffer' with some special-purpose alist elements..." misses the point. It is not just that "you can" but that "you MUST" (if you intend this as a replacement rather than an addition). What you've provided is fine for specific places where `display-buffer' is called and you want to give those calls a particular behavior. It is not ideal AFAICT for a package/user that wants to provide/obtain a particular class of behavior across all calls of `display-buffer'. That is what the various "old" user options provide: easy to turn on/off classes of behavior that affect all `display-buffer' calls. As opposed to "customizing" individual `display-buffer' calls (which requires access to modify those calls). That is the power (as well as the limitation) of dynamically scoped global variables: they can affect behavior deep down, with just a flip of the switch. > This means that you can get any special behavior when and > where you (or your users) want it, while providing standard > behavior for those who do not. "You can get" -> "You MUST define". You must have available the "when and where" times and locations, and you must control/customize them. You cannot so simply/easily get a special behavior across all such "when and where" at once. To be clear, I do not say that one _cannot_ do with the new what one can do with the "old". But it does not seem so easy to do - so far. We cannot even seem to get a straightforward "migration table" added to the doc, that clearly tells you how to move from "old" to new. It is not really up to me to prove that the new cannot (or cannot easily) do the job, even if I believed that. It is up to those providing the new to show that it can - IF they intend to deprecate & replace the "old". Hand waving and repeating that "you can" do anything you like with the new is not very persuasive. Yes, this is Lisp: you can do nearly anything. But that is not much help, I'm afraid. It just doesn't cut the mustard. Consider that we users are not so bright, and we need someone to show us the way step by step. IOW, apply the same logic that we ask of users reporting bugs: think of the reader as a six-year old who asks for a bit of hand-holding. Believe me, that will not hurt, and even the explainer can end up learning something now and then from the teaching. > With Emacs 23, you could specify special behavior only via > `special-display-frame-alist' and the special case entries of > `special-display-buffer-names' and `special-display-regexps' in some > very restricted manner - use the same window, a window on the same > frame, or a new frame with some predefined properties. Fair enough. The new is more fine-grained and apparently more general. I can see and appreciate that. But those particular "very restricted" special cases are important use cases - at least for me. For me, the "old" does the job quite well - the "very restricted" job it was intended to do. I am not arguing against the new. Not at all. Wanting to jump on board the new, I'm still waiting to see how best to get the same effects as the "old" using the new. I'm sure I will get there eventually. And I'm guessing that there might be some additional unforeseen hiccups for Emacs Dev that will require still more changes to the new to simulate some aspects of the "old". That's OK, and to be expected. I will say that I am very grateful for your interest and efforts in _getting this right_. It would have been all too easy for someone enthused about his new approach to just throw up his hands and say: it solves all the problems; you are on your own to figure out how. Instead, you have spent time trying to understand and solve the problems raised. Bravo, and thank you, for that. Please understand that I am not opposed to the work you have done in making `display-buffer' (and windows etc.) more coherent, logical, and controllable. Quite the contrary. I defended your work when some wanted to simplify parts and throw some of it overboard. It seemed to me that you were approaching things carefully and with an open mind. You were listening to problems raised and took them seriously. IMHO, it is not appropriate now to deprecate the "old", and it might never be. If the "old" is now no more than a shorthand for a subset of what the new provides, it can usefully be kept as just such: a shorthand, easy way to get that subset. If it turns out - based on _lots_ of user experience and some time - that the "old" is not so convenient as the new, then the new will replace it organically, naturally. Then, and only then, should we deprecate the old: when it truly is no longer serving any purpose, when it truly has become old. Thank you for the new, and please do not be in any hurry to force it on users as a replacement for the "old". If it is better, sufficient, and easier to use, users will naturally adopt it with enthusiasm. Users are not stupid, even if they are more ignorant than the designers wrt the new, esp. when it is first made available. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 13 12:31:46 2012 Received: (at 11939) by debbugs.gnu.org; 13 Aug 2012 16:31:46 +0000 Received: from localhost ([127.0.0.1]:53768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0xYQ-0000ka-1y for submit@debbugs.gnu.org; Mon, 13 Aug 2012 12:31:46 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:60294) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T0xYN-0000kS-A8 for 11939@debbugs.gnu.org; Mon, 13 Aug 2012 12:31:45 -0400 Received: (qmail invoked by alias); 13 Aug 2012 16:23:08 -0000 Received: from 62-47-51-232.adsl.highway.telekom.at (EHLO [62.47.51.232]) [62.47.51.232] by mail.gmx.net (mp036) with SMTP; 13 Aug 2012 18:23:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18kO01NuxskB/lhzp5uaZouZIEcGCtQEwut+zvxFZ 1ZmwO9y/zL0C/0 Message-ID: <502929EA.8010604@gmx.at> Date: Mon, 13 Aug 2012 18:23:06 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' References: <50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> <502! 785DF.1040200@gmx.at> <5028A8FD.60705@gmx .at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > As you know, I am no expert on this stuff - I barely understand the new > approach, certainly so wrt details. I have some experience with parts of the > "old" approach, and I've seen some of the pain you've gone through to try to > enable the new to handle some of the straightforward cases of the old. It has > not always been so simple, has it? You are mistaken here. The "new" approach was _entirely_ coded by Chong based on ideas by Stefan. > You've succeeded, AFAICT, but it has not been obvious. Granted, part of the > difficulty is that you were not familiar with some of the "old" (use cases, for > example). Still, it is not clear to me that the new is a reasonable, > straightforward replacement for the "old". > > Here's the misunderstanding, as I see it: > > "You can call `display-buffer' with some special-purpose alist elements..." > misses the point. It is not just that "you can" but that "you MUST" (if you > intend this as a replacement rather than an addition). As you know very well the old approach is still supported. And I intend "this" as an enhancement rather than a replacement or an addition. > What you've provided is fine for specific places where `display-buffer' is > called and you Who's "you" here? > want to give those calls a particular behavior. It is not ideal > AFAICT for a package/user that wants to provide/obtain a particular class of > behavior across all calls of `display-buffer'. The new approach is superior because it allows packages to specify the behavior they consider most suited and it allows the user to override that. This distinction was not clear in the old approach where a user's customizations could be deliberately turned off by packages that temporarily bound these options to nil. > That is what the various "old" user options provide: easy to turn on/off classes > of behavior that affect all `display-buffer' calls. These confer to `display-buffer-base-action' in the new approach. A package binding this variable is a package I would remove immediately. > As opposed to "customizing" > individual `display-buffer' calls (which requires access to modify those calls). I miss you here. > That is the power (as well as the limitation) of dynamically scoped global > variables: they can affect behavior deep down, with just a flip of the switch. `display-buffer-base-action' provides that switch. > "You can get" -> "You MUST define". You must have available the "when and > where" times and locations, and you must control/customize them. You cannot so > simply/easily get a special behavior across all such "when and where" at once. In which regard does what you write here differ from earlier versions of Emacs? > To be clear, I do not say that one _cannot_ do with the new what one can do with > the "old". But it does not seem so easy to do - so far. We cannot even seem to > get a straightforward "migration table" added to the doc, that clearly tells you > how to move from "old" to new. This is partially true. For example, I'd never explain how a package can override a user's customizations. > It is not really up to me to prove that the new cannot (or cannot easily) do the > job, even if I believed that. It is up to those providing the new to show that > it can - IF they intend to deprecate & replace the "old". Hand waving and > repeating that "you can" do anything you like with the new is not very > persuasive. Yes, this is Lisp: you can do nearly anything. But that is not > much help, I'm afraid. It just doesn't cut the mustard. > > Consider that we users are not so bright, and we need someone to show us the way > step by step. IOW, apply the same logic that we ask of users reporting bugs: > think of the reader as a six-year old who asks for a bit of hand-holding. > Believe me, that will not hurt, and even the explainer can end up learning > something now and then from the teaching. Users who ask will get the appropriate answer. Unfortunately, deprecating options seems the only way to get them do that. And in this regard, I consider myself a user just like you. > Fair enough. The new is more fine-grained and apparently more general. I can > see and appreciate that. But those particular "very restricted" special cases > are important use cases - at least for me. For me, the "old" does the job quite > well - the "very restricted" job it was intended to do. For some users it was bad karma that applications were allowed to overrule them in these important use cases. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 13 18:29:34 2012 Received: (at 11939) by debbugs.gnu.org; 13 Aug 2012 22:29:34 +0000 Received: from localhost ([127.0.0.1]:54386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T138g-0002Gb-9e for submit@debbugs.gnu.org; Mon, 13 Aug 2012 18:29:34 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:47258) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T138d-0002GU-Pr for 11939@debbugs.gnu.org; Mon, 13 Aug 2012 18:29:33 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DMKtNa026583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Aug 2012 22:20:56 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7DMKsUw022502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 22:20:55 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7DMKsqv027667; Mon, 13 Aug 2012 17:20:54 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Aug 2012 15:20:54 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' Date: Mon, 13 Aug 2012 15:20:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac15IxZik1v5ur83S6KlJS2YrcJW1AAL/lSQABBBMzA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Importance: High X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Coming back to an earlier part of this thread. I have some news. I found today that the code you sent does not help in at least one situation. I presume that's because it deals only with temporary buffers, but I'm not sure. The buffer popped up in a separate frame is *Completions*. By "does not help" I mean that it makes no difference in this case whether I load your code or not. Anyway, the scenario involves using my one-on-one stuff with a vanilla Emacs call to `completing-read' or `completing-read-multiple'. [I discovered this because the latter (`c-r-m') does not use anything particular in Icicles, so `customize-face' (via `read-face-name') just calls vanilla `completing-read-multiple' even in Icicle mode.] M-x customize-face b TAB then, trying to type more chars raises an error saying that *Completions* is read-only (IOW, the *Completions* frame was somehow given the input focus). I looked into the problem a little more closely. None of the hacks I had tried previously with `1on1-fit-minibuffer-frame' took care of this problem: neither guarding the minibuffer frame-fitting, using (eq last-event-frame (window-frame (minibuffer-window))) nor adding explicit redirection to the minibuffer frame at the end of `1on1-fit-minibuffer-frame'. It turns out that the problem was 3-fold. That is, there were three places in the code of `1on1-fit-minibuffer-frame' that caused the problem: each was _alone_ capable of causing the problem, so all three needed to be fixed. Here they are. 1. This was one of the guards of the body of `1on1-fit-minibuffer-frame': (save-selected-window (select-window (minibuffer-window)) (one-window-p nil 'selected-frame)) The call to `save-selected-window' somehow gave the focus to the *Completions* frame. The solution was to change `save-selected-window' to `save-window-excursion' here. I don't know why, but I'm hoping you will. 2. This was called near the beginning of the `1on1-fit-minibuffer-frame' body: (let* ((frame (save-selected-window (select-window (minibuffer-window)) (selected-frame))) The fix here too was to use `save-window-excursion' instead of `save-selected-window'. 3. At the end of the `1on1-fit-minibuffer-frame' body there is this call: (1on1-set-minibuffer-frame-top/bottom) The code for that function is this: (defun 1on1-set-minibuffer-frame-top/bottom () (when 1on1-minibuffer-frame (condition-case nil (if (fboundp 'redisplay) (redisplay t) (force-mode-line-update t)) (error nil)) ; Ignore errors from, e.g., killed buffers. (modify-frame-parameters 1on1-minibuffer-frame `((top ,@ (or 1on1-minibuffer-frame-top/bottom (- (* 2 (frame-char-height 1on1-minibuffer-frame))))))))) Here the problem was the call to `redisplay'. I changed (foundp 'redisplay) to just nil to fix things - `force-mode-line-update' works without changing the focus. `redisplay' is defined in C code. I do not know why it causes a problem here (why would redisplay change the input focus?), and I don't know what the proper solution might be, except to just use `force-mode-line-update' as I was already doing in older Emacs versions (which do not have `redisplay'). Do you have an idea about this? Does any of this make sense to you? Each of these fixes is needed for `1on1-fit-minibuffer-frame'. Reverting any of them brings back the problem (giving *Completions* the focus). I do not understand any of these fixes (why they work), and I am certainly not claiming anything about them or about the problem, which I do not understand. I am only saying that together these changes fix the problem I encountered. But if you can explain things I will be glad to learn. Thx/HTH - Drew From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 14 05:19:09 2012 Received: (at 11939) by debbugs.gnu.org; 14 Aug 2012 09:19:09 +0000 Received: from localhost ([127.0.0.1]:55137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1DHI-0004p0-LP for submit@debbugs.gnu.org; Tue, 14 Aug 2012 05:19:09 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:45509) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T1DHG-0004ot-LB for 11939@debbugs.gnu.org; Tue, 14 Aug 2012 05:19:07 -0400 Received: (qmail invoked by alias); 14 Aug 2012 09:10:28 -0000 Received: from 62-47-49-255.adsl.highway.telekom.at (EHLO [62.47.49.255]) [62.47.49.255] by mail.gmx.net (mp024) with SMTP; 14 Aug 2012 11:10:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/klIN7s6jk/HQY5xdJrXHa6BWrKOM7QB3PbC1DAH hcWkf1DJr6b7bZ Message-ID: <502A160E.5040601@gmx.at> Date: Tue, 14 Aug 2012 11:10:38 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' References: <50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > It turns out that the problem was 3-fold. That is, there were three places in > the code of `1on1-fit-minibuffer-frame' that caused the problem: each was > _alone_ capable of causing the problem, so all three needed to be fixed. Here > they are. > > 1. This was one of the guards of the body of `1on1-fit-minibuffer-frame': > > (save-selected-window > (select-window (minibuffer-window)) > (one-window-p nil 'selected-frame)) Any reason why you don't use (one-window-p nil (window-frame (minibuffer-window))) here? > The call to `save-selected-window' somehow gave the focus to the *Completions* > frame. The solution was to change `save-selected-window' to > `save-window-excursion' here. I don't know why, but I'm hoping you will. You mean that `save-select-window' can redirect focus and not direct it back to where it was before calling it? If this is the case, please check whether it happens in Emacs 23 as well and file a bug report (without referencing `1on1-fit-minibuffer-frame', if possible). > 2. This was called near the beginning of the `1on1-fit-minibuffer-frame' body: > > (let* ((frame (save-selected-window > (select-window (minibuffer-window)) > (selected-frame))) Do you mean (window-frame (minibuffer-window)) here? > The fix here too was to use `save-window-excursion' instead of > `save-selected-window'. Same as above. > 3. At the end of the `1on1-fit-minibuffer-frame' body there is this call: > > (1on1-set-minibuffer-frame-top/bottom) > > The code for that function is this: > > (defun 1on1-set-minibuffer-frame-top/bottom () > (when 1on1-minibuffer-frame > (condition-case nil > (if (fboundp 'redisplay) > (redisplay t) > (force-mode-line-update t)) > (error nil)) ; Ignore errors from, e.g., killed buffers. > (modify-frame-parameters > 1on1-minibuffer-frame > `((top ,@ (or 1on1-minibuffer-frame-top/bottom > (- (* 2 (frame-char-height > 1on1-minibuffer-frame))))))))) > > Here the problem was the call to `redisplay'. I changed (foundp 'redisplay) to > just nil to fix things - `force-mode-line-update' works without changing the > focus. > > `redisplay' is defined in C code. I do not know why it causes a problem here > (why would redisplay change the input focus?), and I don't know what the proper > solution might be, except to just use `force-mode-line-update' as I was already > doing in older Emacs versions (which do not have `redisplay'). > > Do you have an idea about this? Does any of this make sense to you? No. Can't you distill a simple test case? `redisplay' shouldn't care about frame focus either. > Each of these fixes is needed for `1on1-fit-minibuffer-frame'. Reverting any of > them brings back the problem (giving *Completions* the focus). I do not > understand any of these fixes (why they work), and I am certainly not claiming > anything about them or about the problem, which I do not understand. I am only > saying that together these changes fix the problem I encountered. > > But if you can explain things I will be glad to learn. I can't explain any of these. In the past, I tried to make most window functions work on any window/frame to work independently from the selected window. Earlier, selecting a window must have been a very simple procedure. Nowadays, this incurs so many side-effects in the window/frame/display area that you should try to avoid `select-window' wherever possible. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 14 10:45:34 2012 Received: (at 11939) by debbugs.gnu.org; 14 Aug 2012 14:45:34 +0000 Received: from localhost ([127.0.0.1]:56408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1INB-0005mG-GS for submit@debbugs.gnu.org; Tue, 14 Aug 2012 10:45:34 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:26222) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1IN9-0005m8-1J for 11939@debbugs.gnu.org; Tue, 14 Aug 2012 10:45:32 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7EEaoN7013998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Aug 2012 14:36:50 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7EEan9M016033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2012 14:36:50 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7EEanUj014792; Tue, 14 Aug 2012 09:36:49 -0500 Received: from dradamslap1 (/10.159.223.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Aug 2012 07:36:49 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502! A160E.5040601@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' Date: Tue, 14 Aug 2012 07:36:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac15/KdZUv81ALbYSnKdqgo8pN6IEQAJzfyQ In-Reply-To: <502A160E.5040601@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > (save-selected-window > > (select-window (minibuffer-window)) > > (one-window-p nil 'selected-frame)) > > Any reason why you don't use > (one-window-p nil (window-frame (minibuffer-window))) > here? The doc for `one-window-p', for Emacs < 24, says this: "If ALL-FRAMES is neither nil nor t, count only the selected frame." To me, that says that the frame must be _selected_. It says that it makes no difference if the non-nil & non-t value is itself a frame: the SELECTED frame is used even if you pass a different frame as arg. The Emacs 24 doc string says something _very_ different - something that accords with your suggestion. It says that a value that is a _frame_ means: "consider all windows on that frame only." Here, "that frame" is presumably the frame passed as argument. However, I wonder if that is correct. The _code_ itself is unchanged from Emacs 20 through Emacs 24. Yet the doc string says something very different suddenly. I see nothing in the `one-window-p' code that deals with a frame value, or a `visible' value for that matter. Perhaps these special cases are handled by one of the functions it calls? Can you explain? Is the Emacs 24 behavior actually different from before, or is it just the doc that is different? Is the Emacs 24 doc string correct for 24? Is the 24 doc string perhaps correct also for older releases? (I see nothing in NEWS about a behavior change.) If your suggestion is appropriate, including for older releases, then I'll be glad to adopt it. Please let me know. Note: I have this comment in the code just before the call to `one-window-p'. I do not recall the issue, but the comment has been there for quite a while: ;; We should be able to use just (one-window-p), ;; but an Emacs bug means we need this: (one-window-p nil 'selected-frame))) Does that ring a bell? Even if that bug has since been fixed, I will presumably need to keep that, for older releases. Just wondering if you recall anything about that bug. > > The call to `save-selected-window' somehow gave the focus > > to the *Completions* frame. The solution was to change > > `save-selected-window' to `save-window-excursion' here. > > I don't know why, but I'm hoping you will. > > You mean that `save-select[ed]-window' can redirect focus and not > direct it back to where it was before calling it? That's certainly what it seems like. And there is definitely a difference here wrt what `save-window-excursion' does (that function DTRT here). Perhaps this info gives you a starting point for investigating. > If this is the case, please check whether it happens in Emacs 23 > as well and file a bug report (without referencing > `1on1-fit-minibuffer-frame', if possible). Yes, AFAICT the behavior is the same in all Emacs versions. Do you have a suggestion for a simpler test? If so, perhaps you can test it. > > 2. This was called near the beginning of the > > `1on1-fit-minibuffer-frame' body: > > > > (let* ((frame (save-selected-window > > (select-window (minibuffer-window)) > > (selected-frame))) > > Do you mean (window-frame (minibuffer-window)) here? I suppose so. _Should_ that make a difference? Certainly that is lighter weight than `save-window-excursion', and it seems to work OK so far. Thanks for the suggestion. Please let me know about the other occurrence (above) - I would like to change that also, if your suggestion will work there as well (for all Emacs versions). > > 3. At the end of the `1on1-fit-minibuffer-frame' body > > there is this call: > > (1on1-set-minibuffer-frame-top/bottom) > > > > The code for that function is this: > > > > (defun 1on1-set-minibuffer-frame-top/bottom () > > (when 1on1-minibuffer-frame > > (condition-case nil > > (if (fboundp 'redisplay) > > (redisplay t) > > (force-mode-line-update t)) > > (error nil)) ; Ignore errors from, e.g., killed buffers. > > (modify-frame-parameters > > 1on1-minibuffer-frame > > `((top ,@ (or 1on1-minibuffer-frame-top/bottom > > (- (* 2 (frame-char-height > > 1on1-minibuffer-frame))))))))) > > > > Here the problem was the call to `redisplay'. I changed > > (foundp 'redisplay) to just nil to fix things - > > `force-mode-line-update' works without changing the focus. > > > > `redisplay' is defined in C code. I do not know why it > > causes a problem here (why would redisplay change the input > > focus?), and I don't know what the proper solution might be, > > except to just use `force-mode-line-update' as I was already > > doing in older Emacs versions (which do not have `redisplay'). > > > > Do you have an idea about this? Does any of this make > > sense to you? > > No. Can't you distill a simple test case? `redisplay' shouldn't care > about frame focus either. You are saying the same thing I am. Can you distill a simpler test case? > > Each of these fixes is needed for > > `1on1-fit-minibuffer-frame'. Reverting any of > > them brings back the problem (giving *Completions* the > > focus). I do not understand any of these fixes (why they work), > > and I am certainly not claiming anything about them or about > > the problem, which I do not understand. I am only > > saying that together these changes fix the problem I encountered. > > > > But if you can explain things I will be glad to learn. > > I can't explain any of these. In the past, I tried to make > most window functions work on any window/frame to work independently > from the selected window. Earlier, selecting a window must have > been a very simple procedure. Nowadays, this incurs so many > side-effects in the window/frame/display area that you should > try to avoid `select-window' wherever possible. You seem to be saying that Emacs has introduced bugs, and nothing more. OK, so I hear the admonition to avoid `select-window' wherever possible. That's a sorry state, though. You seem to be saying that things that used to work, and work simply, are now so bugged or complicated that all we can advise is to avoid using `select-window'. Anyway, my updated code seems to take care of the problem I encountered. I would like to know about `one-window-p', however. Is the Emacs 24 doc string wrong? The code is identical to the code for Emacs 20.7, but suddenly we have a very different behavior description. Is the new description correct for Emacs 24 plus older releases? That would be good news (just an old-doc bug). For the moment, the situation is not clear. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 14 12:13:22 2012 Received: (at 11939) by debbugs.gnu.org; 14 Aug 2012 16:13:22 +0000 Received: from localhost ([127.0.0.1]:56531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1Jk9-0000IK-TD for submit@debbugs.gnu.org; Tue, 14 Aug 2012 12:13:22 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:60999) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T1Jk7-0000IC-D9 for 11939@debbugs.gnu.org; Tue, 14 Aug 2012 12:13:20 -0400 Received: (qmail invoked by alias); 14 Aug 2012 16:04:39 -0000 Received: from 62-47-55-43.adsl.highway.telekom.at (EHLO [62.47.55.43]) [62.47.55.43] by mail.gmx.net (mp033) with SMTP; 14 Aug 2012 18:04:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+64n1SIj+6Kmytu7mQraxnWp17K+4RU3TGp+kz8e IlNIu03VIvzxH5 Message-ID: <502A772A.9030902@gmx.at> Date: Tue, 14 Aug 2012 18:04:58 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' References: <501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502! A160E.5040601@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Any reason why you don't use >> (one-window-p nil (window-frame (minibuffer-window))) >> here? > > The doc for `one-window-p', for Emacs < 24, says this: > > "If ALL-FRAMES is neither nil nor t, count only the selected frame." [...] IIUC `one-window-p' calls `next-window' ever since with the ALL-FRAMES argument unchanged and `next-window' has its traditional interpretation of that argument. So it seems that the old doc-string was inaccurate in this regard. But why you don't you check for yourself? With Emacs 22 (progn (setq old-frame (selected-frame)) (setq new-frame (make-frame)) (select-frame new-frame) (split-window) (select-frame old-frame) (one-window-p nil new-frame)) gets me nil as expected. > Note: I have this comment in the code just before the call to `one-window-p'. I > do not recall the issue, but the comment has been there for quite a while: > > ;; We should be able to use just (one-window-p), > ;; but an Emacs bug means we need this: > (one-window-p nil 'selected-frame))) > > Does that ring a bell? No. > Even if that bug has since been fixed, I will presumably > need to keep that, for older releases. Just wondering if you recall anything > about that bug. All I can say is that for me `one-window-p' is much too hard to understand. I wouldn't use it. Can't you compare the results of `frame-first-window' and `minibuffer-window' instead? >> You mean that `save-select[ed]-window' can redirect focus and not >> direct it back to where it was before calling it? > > That's certainly what it seems like. And there is definitely a difference here > wrt what `save-window-excursion' does (that function DTRT here). Perhaps this > info gives you a starting point for investigating. Hardly. Neither of these should affect focus. >> If this is the case, please check whether it happens in Emacs 23 >> as well and file a bug report (without referencing >> `1on1-fit-minibuffer-frame', if possible). > > Yes, AFAICT the behavior is the same in all Emacs versions. > > Do you have a suggestion for a simpler test? If so, perhaps you can test it. No idea. >> > 2. This was called near the beginning of the >> > `1on1-fit-minibuffer-frame' body: >> > >> > (let* ((frame (save-selected-window >> > (select-window (minibuffer-window)) >> > (selected-frame))) >> >> Do you mean (window-frame (minibuffer-window)) here? > > I suppose so. _Should_ that make a difference? Apparently it does make a difference in your case. >> No. Can't you distill a simple test case? `redisplay' shouldn't care >> about frame focus either. > > You are saying the same thing I am. Can you distill a simpler test case? No. All I can say is that manually selecting the `minibuffer-window' seems harmful. > You seem to be saying that Emacs has introduced bugs, and nothing more. Where did I say that? IIUC all Emacs version behave the same wrt your scenario. > OK, so > I hear the admonition to avoid `select-window' wherever possible. That's a > sorry state, though. You seem to be saying that things that used to work, and > work simply, are now so bugged or complicated that all we can advise is to avoid > using `select-window'. Selecting a window or a frame for the sole purpose to retrieve or compare a value related to that window is plain overkill given that `select-window' also selects a frame, makes a buffer current ... > I would like to know about `one-window-p', however. Is the Emacs 24 doc string > wrong? The code is identical to the code for Emacs 20.7, but suddenly we have a > very different behavior description. Is the new description correct for Emacs > 24 plus older releases? That would be good news (just an old-doc bug). For the > moment, the situation is not clear. I think it was a bug in the old doc-string. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 14 13:48:28 2012 Received: (at 11939) by debbugs.gnu.org; 14 Aug 2012 17:48:28 +0000 Received: from localhost ([127.0.0.1]:56741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1LEB-00066p-UU for submit@debbugs.gnu.org; Tue, 14 Aug 2012 13:48:28 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:50329) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1LE9-00066i-VN for 11939@debbugs.gnu.org; Tue, 14 Aug 2012 13:48:26 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7EHdiDl001497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Aug 2012 17:39:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7EHdi9F029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2012 17:39:44 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7EHdiX8003982; Tue, 14 Aug 2012 12:39:44 -0500 Received: from dradamslap1 (/10.159.223.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Aug 2012 10:39:44 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502! A160E.5040601@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' Date: Tue, 14 Aug 2012 10:39:39 -0700 Message-ID: <4AF3BD064346446AB0F2AEAB5DDCB9DA@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac16NoRLW27Scg2uQVeSogRiI57JbgABju6Q In-Reply-To: <502A772A.9030902@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > All I can say is that for me `one-window-p' is much too hard to > understand. I wouldn't use it. Can't you compare the results of > `frame-first-window' and `minibuffer-window' instead? Is that sure to DTRT? If so, fine. I am not familiar with `frame-first-window'. It was certainly not obvious to me that if those two are eq then the frame can only be showing a minibuffer window (no other windows). `f-f-w' is written in C, and its definition has changed somewhat over Emacs releases. But if I pass a frame parameter then I guess the different definitions should amount to the same thing. I'll give that a try. > >> You mean that `save-select[ed]-window' can redirect focus > >> and not direct it back to where it was before calling it? > > > > That's certainly what it seems like. And there is > > definitely a difference here wrt what `save-window-excursion' > > does (that function DTRT here). Perhaps this > > info gives you a starting point for investigating. > > Hardly. Neither of these should affect focus. What can I say? `save-selected-window' sure seems to. > >> If this is the case, please check whether it happens in > >> Emacs 23 as well and file a bug report (without referencing > >> `1on1-fit-minibuffer-frame', if possible). > > > > Yes, AFAICT the behavior is the same in all Emacs versions. > > > > Do you have a suggestion for a simpler test? If so, > > perhaps you can test it. > > No idea. Too bad. > >> > (let* ((frame (save-selected-window > >> > (select-window (minibuffer-window)) > >> > (selected-frame))) > >> > >> Do you mean (window-frame (minibuffer-window)) here? > > > > I suppose so. _Should_ that make a difference? > > Apparently it does make a difference in your case. > > >> No. Can't you distill a simple test case? `redisplay' > >> shouldn't care about frame focus either. > > > > You are saying the same thing I am. Can you distill a > > simpler test case? > > No. All I can say is that manually selecting the > `minibuffer-window' seems harmful. FWIW, I have not encountered any bugs selecting it (whatever you might mean by "manually"), aside from the `save-selected-window' bug reported here. > > You seem to be saying that Emacs has introduced bugs, and > > nothing more. > > Where did I say that? In the text you snipped, just before that sentence of mine: >> I can't explain any of these. In the past, I tried to >> make most window functions work on any window/frame to >> work independently from the selected window. Earlier, >> selecting a window must have been a very simple procedure. >> Nowadays, this incurs so many side-effects in the >> window/frame/display area that you should >> try to avoid `select-window' wherever possible. And by "nothing more" I meant no more explanation: your "I can't explain any of these". > IIUC all Emacs version behave the same wrt your > scenario. Correct. It is you who suggested that selecting a window used to be simpler than now, and that now it has "many" side effects - so much so that you advise people to avoid `select-window'. My finding was that the `save-selected-window' changes-the-focus bug is present in all Emacs releases (20 through 24). > > OK, so I hear the admonition to avoid `select-window' > > wherever possible. That's a sorry state, though. > > You seem to be saying that things that used to work, and > > work simply, are now so bugged or complicated that all we > > can advise is to avoid using `select-window'. > > Selecting a window or a frame for the sole purpose to retrieve or > compare a value related to that window is plain overkill given that > `select-window' also selects a frame, makes a buffer current ... Agreed 100%. That's why I welcome your suggestions of simpler code to accomplish that. It was not obvious to me that `frame-first-window' could be used to test for only-one-window-ness, or that the doc prior to Emacs 24 for `one-window-p' was not correct wrt a frame argument. Your simplifications are welcome, but they were far from obvious, to me. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 15 06:41:14 2012 Received: (at 11939) by debbugs.gnu.org; 15 Aug 2012 10:41:14 +0000 Received: from localhost ([127.0.0.1]:57910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1b2H-0006aE-LF for submit@debbugs.gnu.org; Wed, 15 Aug 2012 06:41:14 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:49240) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T1b2E-0006a6-Np for 11939@debbugs.gnu.org; Wed, 15 Aug 2012 06:41:12 -0400 Received: (qmail invoked by alias); 15 Aug 2012 10:32:26 -0000 Received: from 62-47-38-188.adsl.highway.telekom.at (EHLO [62.47.38.188]) [62.47.38.188] by mail.gmx.net (mp069) with SMTP; 15 Aug 2012 12:32:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+05Ex8YYW0MNyWiyV831Cu+F8H9JAg0+UvXafeLx 2rm4alVnlTqwiU Message-ID: <502B7AC2.70004@gmx.at> Date: Wed, 15 Aug 2012 12:32:34 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' References: <501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502! A160E.5040601@gmx.at> <4AF3BD064346446AB0F2AEAB5DDCB9DA@us.oracle.com> In-Reply-To: <4AF3BD064346446AB0F2AEAB5DDCB9DA@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> All I can say is that for me `one-window-p' is much too hard to >> understand. I wouldn't use it. Can't you compare the results of >> `frame-first-window' and `minibuffer-window' instead? > > Is that sure to DTRT? If so, fine. I am not familiar with > `frame-first-window'. It was certainly not obvious to me that if those two are > eq then the frame can only be showing a minibuffer window (no other windows). > > `f-f-w' is written in C, and its definition has changed somewhat over Emacs > releases. But if I pass a frame parameter ... frame argument, I suppose ... > then I guess the different > definitions should amount to the same thing. I'll give that a try. >> Hardly. Neither of these should affect focus. > > What can I say? `save-selected-window' sure seems to. What can I say? `select-window' ends up calling somewhere do_switch_frame which has #ifdef HAVE_WINDOW_SYSTEM if (track && FRAME_WINDOW_P (XFRAME (frame))) { Lisp_Object focus, xfocus; xfocus = x_get_focus_frame (XFRAME (frame)); if (FRAMEP (xfocus)) { focus = FRAME_FOCUS_FRAME (XFRAME (xfocus)); if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ()) Fredirect_frame_focus (xfocus, frame); } } #endif /* HAVE_X_WINDOWS */ which _apparently_ directs focus away from one of your frames when it's called for the first time and does not direct focus back to that frame when it's called for the second time. If you (like me) do not understand why and how such a thing happens, you maybe understand why I propose to side-step `select-window' in the first place. >> No. All I can say is that manually selecting the >> `minibuffer-window' seems harmful. > > FWIW, I have not encountered any bugs selecting it Maybe because in all other cases you explicitly wanted to select it (not just temporarily/implicitly). > (whatever you might mean by > "manually"), By "manually" I mean that you "explicitly" select it. I always leave it to Emacs to select the minibuffer window. >> > You seem to be saying that Emacs has introduced bugs, and >> > nothing more. >> >> Where did I say that? > > In the text you snipped, just before that sentence of mine: > >>> I can't explain any of these. In the past, I tried to >>> make most window functions work on any window/frame to >>> work independently from the selected window. Earlier, >>> selecting a window must have been a very simple procedure. >>> Nowadays, this incurs so many side-effects in the >>> window/frame/display area that you should >>> try to avoid `select-window' wherever possible. > > And by "nothing more" I meant no more explanation: your "I can't explain any of > these". The fact that I can't explain something means just that: I'm too silly to comprehend what's going on - but not that Emacs has introduced any bugs. Meanwhile Emacs has to interact with too many different operating systems and window managers, in particular when multiple frames are involved. >> IIUC all Emacs version behave the same wrt your >> scenario. > > Correct. It is you who suggested that selecting a window used to be simpler > than now, ... because people working with a different OS want Emacs to DTRT on their OS and selecting a window which implicitly selects a frame had to cope with their needs ... > and that now it has "many" side effects - so much so that you advise > people to avoid `select-window'. My finding was that the `save-selected-window' > changes-the-focus bug is present in all Emacs releases (20 through 24). ... and to solve this we probably have to add another twist as soon as someone is able to understand and resolve this particular issue ... > It was not obvious to me that `frame-first-window' could be used to test for > only-one-window-ness, or that the doc prior to Emacs 24 for `one-window-p' was > not correct wrt a frame argument. Your simplifications are welcome, but they > were far from obvious, to me. To me as well. I tried to find out which function was present in early Emacsen and whether it could DTRT (in principle). martin From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 26 00:12:52 2012 Received: (at 11939) by debbugs.gnu.org; 26 Aug 2012 04:12:52 +0000 Received: from localhost ([127.0.0.1]:49207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T5UDU-0006fv-9g for submit@debbugs.gnu.org; Sun, 26 Aug 2012 00:12:52 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:32949) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T5UDR-0006fm-2v for 11939@debbugs.gnu.org; Sun, 26 Aug 2012 00:12:50 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7Q4C1i9009392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Aug 2012 04:12:02 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7Q4C1BK021305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2012 04:12:01 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7Q4C10U030830; Sat, 25 Aug 2012 23:12:01 -0500 Received: from dradamslap1 (/10.159.173.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Aug 2012 21:12:00 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502! A160E.5040601@gmx.at> <4AF3BD064346446AB0F2AEAB5DDCB9DA@us.oracle.com>! <502B7AC2.70004@gmx. at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' Date: Sat, 25 Aug 2012 21:11:51 -0700 Message-ID: <6CBC512747C54FC0A9F69E36BC8E384B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <502B7AC2.70004@gmx.at> thread-index: Ac160UW37ckkAMgES7m0LHnOIA3/FwIbYklg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -7.1 (-------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.1 (-------) FYI - I had updated my version of `special-display-popup-frame' to fit the latest Emacs 24 definition of it. (All my version tries to do differently is fit the popped up frame to its buffer, nothing more.) It turns out that in making that update I dropped this sexp from my original definition of the function - the sexp is not in the vanilla Emacs definition: (set-window-buffer window buffer) I have now added that back, because the code does not work without it. The problem was that the frame popped up did not show the BUFFER. It showed another buffer. I mention this in case it might also be needed for the vanilla code (?), or in case it might point to a bug somewhere. You understand these things better than I, Martin. Perhaps you will understand just what is going on. Below is the full definition I am using, which works fine now, (just as before Emacs 24). You don't care about the code that fits the frame, but I show the full definition, just in case it helps you understand better why I might need to explicitly `set-window-buffer' and the vanilla code apparently does not need to do that (?). If you learn something from this, or if you can tell me what I'm not understanding, please let me know. Thx. (defun special-display-popup-frame (buffer &optional args) "Pop up a frame displaying BUFFER. Return its window. If BUFFER is already displayed in a visible or iconified frame then raise that frame. Otherwise, display BUFFER in a new frame. Optional argument ARGS is a list specifying additional information. If ARGS is an alist, use it as a list of frame parameters. If these parameters contain (same-window . t) then display BUFFER in the selected window. If they contain (same-frame . t) then display BUFFER in a window of the selected frame. If ARGS is a list whose car is a symbol then use (car ARGS) as a function to do the work: display the buffer and raise its frame. Pass it BUFFER as first argument, and (cdr ARGS) as the rest of the arguments." (if (and args (symbolp (car args))) (apply (car args) buffer (cdr args)) (let ((window (get-buffer-window buffer 0))) (or ;; If we have a window already, make it visible. (and window (let ((frame (window-frame window))) (make-frame-visible frame) (raise-frame frame) (when (fboundp 'display-buffer-record-window) ; Emacs 24+ (display-buffer-record-window 'reuse window buffer)) (when (fboundp 'fit-frame) (fit-frame frame)) window)) ; Return the window. ;; Reuse the selected window if the caller requested it. (and (cdr (assq 'same-window args)) (condition-case nil ; Try Emacs 24 `switch-to-buffer' first. (progn (switch-to-buffer buffer nil t) (selected-window)) (error ; Try again, with old `switch-to-buffer'. (condition-case nil (progn (switch-to-buffer buffer) (selected-window)) (error nil))))) ;; Stay on the same frame if requested. (and (or (cdr (assq 'same-frame args)) (cdr (assq 'same-window args))) (let ((pop-up-windows t) (pop-up-frames nil) (special-display-buffer-names ()) (special-display-regexps ())) (display-buffer buffer))) ;; If no window yet, make one in a new frame. ;; `make-frame' creates the frame before the buffer is shown in it, ;; so do not call `fit-frame' until we can select the buffer's window. (let* ((make-frame-functions (delq 'fit-frame after-make-frame-functions)) (frame (with-current-buffer buffer (make-frame (append args special-display-frame-alist)))) (window (frame-selected-window frame))) ;; *** IS THIS NOT NEEDED ALSO FOR VANILLA EMACS? WHY NOT? *** (set-window-buffer window buffer) (set-window-dedicated-p window t) (when (fboundp 'display-buffer-record-window) ; Emacs 24+ (display-buffer-record-window 'frame window buffer)) ;; Now call `fit-frame', with WINDOW selected. (with-selected-window window (fit-frame)) window))))) ; Return the window. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 26 00:32:05 2012 Received: (at 11939) by debbugs.gnu.org; 26 Aug 2012 04:32:06 +0000 Received: from localhost ([127.0.0.1]:49218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T5UW5-00076b-8n for submit@debbugs.gnu.org; Sun, 26 Aug 2012 00:32:05 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:28154) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T5UW2-00076S-Ep for 11939@debbugs.gnu.org; Sun, 26 Aug 2012 00:32:03 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7Q4VELb017589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Aug 2012 04:31:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7Q4VDZT021442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2012 04:31:14 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7Q4VDnO004541; Sat, 25 Aug 2012 23:31:13 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Aug 2012 21:31:13 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com><502378A8.90!10707@gmx.at><5026266!6.2060809@gmx.at><502!785DF.1040200@gmx.at><5028! A8FD.60705@gmx .at>< EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502!A160E.5040601@gmx.at> <4AF3BD064346446AB0F2AEAB5DDCB9DA@us.oracle.com>!<502B7AC2.70! 004@gmx. at> <6CBC512 747C54FC0A9F69E36BC8E384B@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes' Date: Sat, 25 Aug 2012 21:31:03 -0700 Message-ID: <428B864CCDCD44C5919EAFF5799FBBCC@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac160UW37ckkAMgES7m0LHnOIA3/FwIbYklgAAEjQSA= In-Reply-To: <6CBC512747C54FC0A9F69E36BC8E384B@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -7.1 (-------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.1 (-------) Sorry, that should be: (save-selected-window window (select-window window) (fit-frame)) Probably doesn't matter for Emacs 24 (either seems to work OK here), but `with-selected-window' is not defined for older Emacs versions. > (with-selected-window window (fit-frame)) From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 05 10:29:42 2012 Received: (at 11939) by debbugs.gnu.org; 5 Sep 2012 14:29:42 +0000 Received: from localhost ([127.0.0.1]:40429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T9Gbu-000158-7j for submit@debbugs.gnu.org; Wed, 05 Sep 2012 10:29:42 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:35478) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1T9Gbs-000150-Kj for 11939@debbugs.gnu.org; Wed, 05 Sep 2012 10:29:41 -0400 Received: (qmail invoked by alias); 05 Sep 2012 14:29:32 -0000 Received: from 62-47-54-51.adsl.highway.telekom.at (EHLO [62.47.54.51]) [62.47.54.51] by mail.gmx.net (mp001) with SMTP; 05 Sep 2012 16:29:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/qPYRfGx3qlSLewGF31THr1iH0GsnAPdXeIlhH3o UefHL+6Is/to7G Message-ID: <50476203.8090503@gmx.at> Date: Wed, 05 Sep 2012 16:30:27 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.3 (/) > This is part of the ongoing saga of trying to get Emacs to DTRT with > buffers popped up only to serve as info while Emacs asks a question > requiring a response. > > IF you use a standalone minibuffer frame, AND the popped up buffer is > special-display (e.g. because of `special-display-regexps'), AND you are > on MS Windows (which automatically shifts the focus to a new frame that > it creates), THEN: > > 1. When you try to exit Emacs with active processes, Emacs pops up a new > frame for buffer `*Process List*' and asks you about killing them. > > 2. But the minibuffer frame no longer has the focus! So when you type > your answer (e.g. "yes") Emacs tries to insert it as text in buffer > `*Process List*'. Poor Emacs. Please check with the next binaries whether this works now as intended. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 05 10:36:11 2012 Received: (at 11939) by debbugs.gnu.org; 5 Sep 2012 14:36:11 +0000 Received: from localhost ([127.0.0.1]:40455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T9GiA-0001G9-QK for submit@debbugs.gnu.org; Wed, 05 Sep 2012 10:36:11 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:50705) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T9Gi8-0001G1-3s for 11939@debbugs.gnu.org; Wed, 05 Sep 2012 10:36:08 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q85EZxXq012308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2012 14:36:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q85EZwhb022754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2012 14:35:59 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q85EZw9Q031997; Wed, 5 Sep 2012 09:35:58 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Sep 2012 07:35:58 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50476203.8090503@gmx.at> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes' Date: Wed, 5 Sep 2012 07:35:57 -0700 Message-ID: <3E32A24D52324067986D05701BF1103A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50476203.8090503@gmx.at> Thread-Index: Ac2LcuDwAmEqZmNVRGOYOv/C+3aVjgAANbdA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Please check with the next binaries whether this works now as > intended. Thanks, martin Will do; thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 03 12:18:52 2012 Received: (at 11939) by debbugs.gnu.org; 3 Oct 2012 16:18:52 +0000 Received: from localhost ([127.0.0.1]:51550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRet-0000Zb-Qt for submit@debbugs.gnu.org; Wed, 03 Oct 2012 12:18:52 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:40389) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRer-0000ZO-9p for 11939@debbugs.gnu.org; Wed, 03 Oct 2012 12:18:51 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93GIgT3008390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 16:18:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93GIffp005817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 16:18:42 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93GIfsP012581; Wed, 3 Oct 2012 11:18:41 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 09:18:41 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <50476203.8090503@gmx.at> <3E32A24D52324067986D05701BF1103A@us.oracle.com> Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' Date: Wed, 3 Oct 2012 09:18:40 -0700 Message-ID: <0624342AFA2B4430B3116DC5891ED2B0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3E32A24D52324067986D05701BF1103A@us.oracle.com> Thread-Index: Ac2LcuDwAmEqZmNVRGOYOv/C+3aVjgAANbdABYOLlaA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 11939 Cc: 11939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > Sent: Wednesday, September 05, 2012 7:36 AM > > > Please check with the next binaries whether this works now as > > intended. Thanks, martin > > Will do; thanks. Finally got a Windows binary I could check this with. There was a lot in this thread. But I at least checked that the original problem reported (for the popup question about active processes) is fixed. It is. Thx. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 05 03:04:52 2012 Received: (at 11939-done) by debbugs.gnu.org; 5 Oct 2012 07:04:52 +0000 Received: from localhost ([127.0.0.1]:54989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TK1xs-0000ml-GG for submit@debbugs.gnu.org; Fri, 05 Oct 2012 03:04:52 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:44872) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TK1xq-0000mY-QT for 11939-done@debbugs.gnu.org; Fri, 05 Oct 2012 03:04:51 -0400 Received: (qmail invoked by alias); 05 Oct 2012 07:04:35 -0000 Received: from 62-47-57-32.adsl.highway.telekom.at (EHLO [62.47.57.32]) [62.47.57.32] by mail.gmx.net (mp034) with SMTP; 05 Oct 2012 09:04:35 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/oCdwFfnbo3cnQrrmpafv3v9X+9s7jIBcfuP2RH5 KHK5JuZ4PQ/dP3 Message-ID: <506E8683.30008@gmx.at> Date: Fri, 05 Oct 2012 09:04:35 +0200 From: martin rudalics MIME-Version: 1.0 To: 11939-done@debbugs.gnu.org Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes' References: <50476203.8090503@gmx.at> <3E32A24D52324067986D05701BF1103A@us.oracle.com> <0624342AFA2B4430B3116DC5891ED2B0@us.oracle.com> In-Reply-To: <0624342AFA2B4430B3116DC5891ED2B0@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 11939-done Cc: Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > There was a lot in this thread. But I at least checked that the original > problem reported (for the popup question about active processes) is fixed. It > is. Thx. OK. Closing this as well. Thanks, martin From unknown Thu Aug 14 12:26:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 02 Nov 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator