From unknown Fri Aug 15 04:03:07 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3303 <3303@debbugs.gnu.org> To: bug#3303 <3303@debbugs.gnu.org> Subject: Status: delete-frame raises old (invisible) frame Reply-To: bug#3303 <3303@debbugs.gnu.org> Date: Fri, 15 Aug 2025 11:03:07 +0000 retitle 3303 delete-frame raises old (invisible) frame=20 reassign 3303 emacs,ns submitter 3303 David Reitter severity 3303 normal thanks From david.reitter@gmail.com Fri May 15 18:09:24 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 16 May 2009 01:09:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.8 required=4.0 tests=AWL,IMPRONONCABLE_2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4G19LMt031975 for ; Fri, 15 May 2009 18:09:22 -0700 Received: from mail.gnu.org ([199.232.76.166]:35478 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1M58Ou-0001ZZ-9r for emacs-pretest-bug@gnu.org; Fri, 15 May 2009 21:09:20 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1M58Ot-0000l7-J3 for emacs-pretest-bug@gnu.org; Fri, 15 May 2009 21:09:20 -0400 Received: from mail-ew0-f210.google.com ([209.85.219.210]:52850) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M58Ot-0000l1-9X for emacs-pretest-bug@gnu.org; Fri, 15 May 2009 21:09:19 -0400 Received: by ewy6 with SMTP id 6so2962912ewy.42 for ; Fri, 15 May 2009 18:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=bGy1rElRbqAPiUqyAzmXl8C0rB4zN8FRBZdt97nrAPU=; b=XlY6CPSvk6zon8r98/NT/cJ9BKG055J1nV9Wrx6Iba3QQwvpfzsF4ExuP5p2fqv7sp fWjEhXzwlSo4hNg4Vx19ggh8jplq+768QHLQK6B4Xrpf1igID/fjWq2VornWD6cszwiI rWtQQrARs5io+XL+ke4ejGttnPhsxzxYMb3Fc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=s/1A+KbbshdUlL0xghrbeZ8trrrOSgvHsCyklzQS37yyglW4KPr/dtgwH/lLpWzvXC vnOhTu9clpckAVWomApxTUcgaPiMtzMzKcMR6SrcQxiTJY6TBClxf+KoiAND1exXBk8T B2R9hg67FUjSIX3r1uX0NAm7KErLbJKVWK8Ds= Received: by 10.210.82.13 with SMTP id f13mr4393958ebb.72.1242436158356; Fri, 15 May 2009 18:09:18 -0700 (PDT) Received: from ?192.168.250.233? ([69.26.225.190]) by mx.google.com with ESMTPS id 5sm2444837eyf.8.2009.05.15.18.09.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 May 2009 18:09:18 -0700 (PDT) Message-Id: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> From: David Reitter To: emacs-pretest-bug@gnu.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: delete-frame raises old (invisible) frame Date: Fri, 15 May 2009 18:09:11 -0700 X-Mailer: Apple Mail (2.935.3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Emacs -Q under NS, then (progn (make-frame-invisible nil t) (make-frame) (delete-frame (selected-frame) t)) will unexpectedly leave one frame visible and raised. It should actually hide all frames. The code that does it come in via the NS port (75f88b1c by arobert on 2008-07-15), in do_switch_frame(): #ifdef NS_IMPL_COCOA /* term gets no other notification of this */ if (for_deletion) Fraise_frame(Qnil); #endif (do_switch_frame): When for_deletion under Cocoa, add Fraise_frame(Qnil). This seems needed in order to raise another (visible) frame - otherwise no frame gets raised (or visibly selected). The change below would address this - but is Fselect_frame() intended to make frames visible (on other platforms)? diff --git a/src/frame.c b/src/frame.c index de857af..fbef938 100644 --- a/src/frame.c +++ b/src/frame.c @@ -868,7 +868,7 @@ do_switch_frame (frame, track, for_deletion, norecord) #ifdef NS_IMPL_COCOA /* term gets no other notification of this */ - if (for_deletion) + if (for_deletion && FRAME_VISIBLE_P (XFRAME (frame))) Fraise_frame(Qnil); #endif From david.reitter@gmail.com Fri May 15 19:28:15 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 16 May 2009 02:28:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.7 required=4.0 tests=AWL,MISSING_SUBJECT,NOSUBJECT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4G2S6DU022950; Fri, 15 May 2009 19:28:08 -0700 Received: by ewy26 with SMTP id 26so3083160ewy.1 for ; Fri, 15 May 2009 19:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=4kq68ooETr9muUyofzGIgaBzi4xFlZkz2kMoR2jA3Xc=; b=vZ0QtTptM2VeRgEJ6scNy2ltGg37Ob6zwKbdaeLEtOjq7GwDFgQWonaVC25Prq1a8J QscCMlS+UocQKKaG3fg3Us0Qpts3AXLR49AyphvzrguccALx+G+Ed9puhoWfJ/RYl+Y7 LKOLLx0f0bB2S1NlaAZraYlv0trzxcFXY+0/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=NEquGsuGuF9kg5BKFQhGchgI+0AqOfjioNObMYb24coYSdbMv4G9M3BDtHOZc+AU5a gANYUn7BNyfEJRdxVS9HUn76Mc/RCBciB5v8e9paoN56jixK+z//7iC+IzCGZuJmWRWQ tZuNv9ejAatwdTfo+4ANBc104MlhFZT2mQ/H4= Received: by 10.210.91.17 with SMTP id o17mr4906012ebb.3.1242440881253; Fri, 15 May 2009 19:28:01 -0700 (PDT) Received: from ?192.168.251.50? ([69.26.225.190]) by mx.google.com with ESMTPS id 10sm2493310eyd.2.2009.05.15.19.27.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 May 2009 19:28:00 -0700 (PDT) Message-Id: <6253E096-6D5F-4AA6-8455-F4B422DD64A6@gmail.com> From: David Reitter To: 3303@debbugs.gnu.org, 3204@debbugs.gnu.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Date: Fri, 15 May 2009 19:27:55 -0700 X-Mailer: Apple Mail (2.935.3) Bugs 3303 and 3204 are probably related / same. From cyd@stupidchicken.com Sat May 16 12:28:16 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 16 May 2009 19:28:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4GJSDeu010240 for <3303@emacsbugs.donarmstrong.com>; Sat, 16 May 2009 12:28:14 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 2A1CB57E21E; Sat, 16 May 2009 15:28:29 -0400 (EDT) From: Chong Yidong To: David Reitter Cc: 3303@debbugs.gnu.org Subject: Re: delete-frame raises old (invisible) frame Date: Sat, 16 May 2009 15:28:29 -0400 Message-ID: <87ljow6e5e.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Emacs -Q under NS, then > > (progn > (make-frame-invisible nil t) > (make-frame) > (delete-frame (selected-frame) t)) > > will unexpectedly leave one frame visible and raised. It should > actually hide all frames. Emacs does this on GNU/Linux as well, at least under the Metacity window manager. If we "fix" it---which I'm not sure we should---then the fix should occur in the platform-independent code. From david.reitter@gmail.com Sat May 16 19:56:05 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 17 May 2009 02:56:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.9 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4H2txuM014239 for <3303@emacsbugs.donarmstrong.com>; Sat, 16 May 2009 19:56:01 -0700 Received: by ey-out-2122.google.com with SMTP id d26so746782eyd.13 for <3303@emacsbugs.donarmstrong.com>; Sat, 16 May 2009 19:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=zMVeMLJJi7GKw1ZXtt8Eoz4pZwj0RjAOmuaMmlJh+2M=; b=K0E8Av5JkjJcGO5Q6GTNasn+P2odK90SFmRBp9tDkd855gbZJTOkflcXvattUMqRb7 l3Ev0qRTbY/M6DPznO27iGjP14B7V+/JDeYbbgxyM8n+HEdT1zSLVymsRa22tz47E4Uz vo/2byx3EVM1m1GaG4A3MElwfITOLg8Lut3x0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=MonNYaMb+3te0VMTz65AzKnNje0lg/y23pOhlImDH4DWFdPt8bfgpKP0H/y6O8JeQz WWmwhZGNYO6rRwOFf0tHzg5QtYWtNfRZ9FgyEcTk54eV4K18M+CgEyZQJon7gecfMlUH +rL/0UiqA3p1FFQoa3gehKez1UALQ8s1CHs0Q= Received: by 10.210.143.11 with SMTP id q11mr2768221ebd.65.1242528959155; Sat, 16 May 2009 19:55:59 -0700 (PDT) Received: from ?192.168.1.42? (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 28sm3987477eye.36.2009.05.16.19.55.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 16 May 2009 19:55:58 -0700 (PDT) Cc: 3303@debbugs.gnu.org Message-Id: From: David Reitter To: Chong Yidong In-Reply-To: <87ljow6e5e.fsf@cyd.mit.edu> Content-Type: multipart/signed; boundary=Apple-Mail-13-81265970; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: delete-frame raises old (invisible) frame Date: Sat, 16 May 2009 22:55:54 -0400 References: <87ljow6e5e.fsf@cyd.mit.edu> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-13-81265970 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 16, 2009, at 3:28 PM, Chong Yidong wrote: >> will unexpectedly leave one frame visible and raised. It should >> actually hide all frames. > > Emacs does this on GNU/Linux as well, at least under the Metacity > window > manager. If we "fix" it---which I'm not sure we should---then the fix > should occur in the platform-independent code. As it stands, Emacs is unable to consistently hide all frames, and this behavior of unhiding frames is simply not documented as such. If it is the window manager that makes a frame visible, then we should respect that. It's not our business. But forcefully un-hiding some other frame as is done specifically in NS is not a great idea. (We can select a frame without unhiding it!) Hiding a frame is the only workaround that I know that allows me to remove all frames. Running an application without any open frames is a perfectly normal thing to do in any environment that displays the menu bar on the top. The code can't handle deleting the last frame (as it is assumed in many places that there is a live, selected frame). That's why hiding is important to me. --Apple-Mail-13-81265970 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUxNzAyNTU1NVowIwYJKoZIhvcNAQkEMRYEFDlvxFTse1UyEVPsAdBB7qSxQD1A MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgHsFUAo420VJvO5HpHXPSzttbSImVohh3/eCsGwtzNpo540IpkAMkXSi3JOgxrFUnFx3 5Ehi/z8J9bRRkP5QCG3CmBsNGg5H/r6j+DqV8LHyBX/2IOOeBzfmnqHd2ivQUNP+4a6vdwIHxsuh tnDGjILy2/PBSEq8dVHy3JVDg6lYAAAAAAAA --Apple-Mail-13-81265970-- From monnier@iro.umontreal.ca Sun May 17 12:05:40 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 17 May 2009 19:05:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4HJ5ZjV003993 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 12:05:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAFADL9D0pMCovv/2dsb2JhbACBT84phAEFhWo X-IronPort-AV: E=Sophos;i="4.41,208,1241409600"; d="scan'208";a="38711725" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 17 May 2009 15:05:29 -0400 Received: by pastel.home (Postfix, from userid 20848) id DD95A8096; Sun, 17 May 2009 15:06:17 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: Adrian Robert , 3303@debbugs.gnu.org Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> Date: Sun, 17 May 2009 15:06:17 -0400 In-Reply-To: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> (David Reitter's message of "Fri, 15 May 2009 18:09:11 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > (progn > (make-frame-invisible nil t) > (make-frame) > (delete-frame (selected-frame) t)) > will unexpectedly leave one frame visible and raised. Under GNU/Linux it also leaves a frame visible and raised, but it's not the one you think: the (selected-frame) call returns the invisible frame, not the new frame, because `make-frame' did not select the new frame. So you may want to prefer (progn (make-frame-invisible nil t) (with-selected-frame (make-frame) (delete-frame (selected-frame) t))) which at least under GNU/Linux seems to do the right thing. Still, the #ifdef NS_IMPL_COCOA /* term gets no other notification of this */ if (for_deletion) Fraise_frame(Qnil); #endif in frame.c looks plain wrong and should probably just be deleted: frame-selection is never intended to raise (or lower) any frame. If this `raise' is really necessary, then it needs a much more extensive comment justifying its presence. Adrian, could you remove this code, or justify clearly why it's here? Stefan From david.reitter@gmail.com Sun May 17 12:12:54 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 17 May 2009 19:12:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-bw0-f157.google.com (mail-bw0-f157.google.com [209.85.218.157]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4HJCoSh006199 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 12:12:51 -0700 Received: by bwz1 with SMTP id 1so3758709bwz.1 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 12:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=4ZHWkuNG0Xll+5ivGASIxriPk/2boEE+58H2pqKbJC8=; b=oPHvSjAOB72CkhnsWrI/AW70jYRW8JAi8zBwQNv+eLqu5g3z+c5U/V3ljIlsUn2zIA StpGrEerTcgdWhrajmRSpRx4lqPtvdElMI5JP+S01bKwpBhlf6IJsO6dQD2llAisXZDm VAFqjas/+Pe/EKuW4gD6RWHZfkfUTTL53eXMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=O7J/0ts5/hqJIRjdzw5vmAK6cndOlvqWIpAYv03CGM3mb1vCsvw/Oeu390FKaCb5Ey her2oCgNjyJF8e0z65o7dfDhqCdJlqmCKAQU7PJkAHdtyJAKd1WIDjFsZWKEhiPDli/Q Jh1CXGXtJ0aZESpW9uuqHTPMtJq9frqW+6X/4= Received: by 10.102.247.10 with SMTP id u10mr3621374muh.76.1242587564224; Sun, 17 May 2009 12:12:44 -0700 (PDT) Received: from ?192.168.1.42? (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 25sm1187774mul.59.2009.05.17.12.12.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 12:12:43 -0700 (PDT) Cc: Adrian Robert , 3303@debbugs.gnu.org Message-Id: <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> From: David Reitter To: Stefan Monnier In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-16-139870763; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Sun, 17 May 2009 15:12:39 -0400 References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-16-139870763 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 17, 2009, at 3:06 PM, Stefan Monnier wrote: > > Still, the > > #ifdef NS_IMPL_COCOA > /* term gets no other notification of this */ > if (for_deletion) > Fraise_frame(Qnil); > #endif > > in frame.c looks plain wrong and should probably just be deleted: > frame-selection is never intended to raise (or lower) any frame. > If this `raise' is really necessary, then it needs a much more > extensive > comment justifying its presence. > Adrian, could you remove this code, or justify clearly why it's here? I think it is there because we need to raise another (visible) frame when a frame is deleted. This is standard behavior (and sensible). However, this should not occur if the other frame is hidden, i.e. if there is no visible and uniconified frame. Im currently experimenting with something like this: #ifdef NS_IMPL_COCOA /* term gets no other notification of this */ if (for_deletion && FRAME_VISIBLE_P (XFRAME (selected_frame)) && FRAME_LIVE_P (XFRAME (selected_frame)) && ! FRAME_ICONIFIED_P (XFRAME (selected_frame))) Fraise_frame(Qnil); #endif - D --Apple-Mail-16-139870763 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUxNzE5MTIzOVowIwYJKoZIhvcNAQkEMRYEFBbN9Y2OUiYlW8itJ9+BCFI/DdB6 MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgB2HoUEjdTurneBmZpDd5SRtNGJkPiRpboGlOq6hicOwzZjpNPfYgJNzMyUNYOXcFCje 6M6rYZHh7Spo8un0VLfOFXehWOlJi7m8FTTC0SDT0HwVOQF7/6Rk/FTOQDjipTMiwXR9Nke+97Bq FRESe3a9hS/m1uHWfQsEPmspuAM6AAAAAAAA --Apple-Mail-16-139870763-- From monnier@iro.umontreal.ca Sun May 17 13:44:04 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 17 May 2009 20:44:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4HKi0Rl000328 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 13:44:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAFAHcTEEpMCovv/2dsb2JhbACBTs1ihAEFhWo X-IronPort-AV: E=Sophos;i="4.41,208,1241409600"; d="scan'208";a="38713280" Received: from 76-10-139-239.dsl.teksavvy.com (HELO ceviche.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 17 May 2009 16:43:55 -0400 Received: by ceviche.home (Postfix, from userid 20848) id A7150B41E3; Sun, 17 May 2009 16:43:54 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: Adrian Robert , 3303@debbugs.gnu.org Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> Date: Sun, 17 May 2009 16:43:54 -0400 In-Reply-To: <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> (David Reitter's message of "Sun, 17 May 2009 15:12:39 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Still, the >> >> #ifdef NS_IMPL_COCOA >> /* term gets no other notification of this */ >> if (for_deletion) >> Fraise_frame(Qnil); >> #endif >> >> in frame.c looks plain wrong and should probably just be deleted: >> frame-selection is never intended to raise (or lower) any frame. >> If this `raise' is really necessary, then it needs a much more extensive >> comment justifying its presence. >> Adrian, could you remove this code, or justify clearly why it's here? > I think it is there because we need to raise another (visible) frame when > a frame is deleted. This is standard behavior (and sensible). This is a behavior which depends on the window-management policy, so it's the responsibility of the window-manager (which may even decide that the focus should return to some other application, which would make a lot of sense if the frame was created via $EDITOR=emacsclient). So, I'd still want to know what undesirable behavior would happen under NS if we don't call Fraise_frame here (and also, why it needs to be called here rather than elsewhere). Stefan From lennart.borgman@gmail.com Sun May 17 15:27:17 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 17 May 2009 22:27:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f160.google.com (mail-fx0-f160.google.com [209.85.220.160]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4HMRCLD031211 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 15:27:14 -0700 Received: by fxm4 with SMTP id 4so3897796fxm.1 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 15:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vRbT3NzEs3Kit24V/DCvDiboNgzm2U/hntz944oCk4E=; b=BjNt2nSD5m00MIYz0wGnhVHahML7YHe8+fKBBv4ikkuS4dmDQYaBNSbgXF5OKub+a6 yc474I9Uh4IyPjijQnyCmdEzbiboIBhE6m7CmvS+lvqtT1X0MaKeMWPtum/i6UTstHtq 7XgrPeETswLjv+OdoiexmqrTR5WMs/q8jAbo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=obKmLXWIkeGuN76qBWQ3wxt7iFi0d+IAIuZMS8BZvXAJYNgUjV/bEp+7/9PRnI7ggg VO34/glA+ndwn4/QLOKh9ihZmxgSKSS9C7pUs3KFAwXHMx3lk6Mvbc2nsORKs1AhWdWA VmNeyB9n/RO3omXyzVyO5NT1zacG87dVzc1ig= MIME-Version: 1.0 Received: by 10.223.113.200 with SMTP id b8mr3887258faq.84.1242599227114; Sun, 17 May 2009 15:27:07 -0700 (PDT) In-Reply-To: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> Date: Mon, 18 May 2009 00:27:07 +0200 Message-ID: Subject: Re: bug#3303: delete-frame raises old (invisible) frame From: Lennart Borgman To: Stefan Monnier , 3303@debbugs.gnu.org Cc: David Reitter , Adrian Robert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 17, 2009 at 10:43 PM, Stefan Monnier wrote: >>> Still, the >>> >>> #ifdef NS_IMPL_COCOA >>> /* term gets no other notification of this */ >>> if (for_deletion) >>> Fraise_frame(Qnil); >>> #endif >>> >>> in frame.c looks plain wrong and should probably just be deleted: >>> frame-selection is never intended to raise (or lower) any frame. >>> If this `raise' is really necessary, then it needs a much more extensiv= e >>> comment justifying its presence. >>> Adrian, could you remove this code, or justify clearly why it's here? > >> I think it is there because we need to raise another (visible) frame whe= n >> a frame is deleted. =C2=A0This is standard behavior (and sensible). > > This is a behavior which depends on the window-management policy, so > it's the responsibility of the window-manager (which may even decide > that the focus should return to some other application, which would make > a lot of sense if the frame was created via $EDITOR=3Demacsclient). Shouldn't then frames created via emacsclient be a special case? That would of course make more sense if the frame was deleted together with the buffer opened through emacsclient... For other frames both leaving it to the window manager and staying in Emacs makes sense to me. Maybe a user option (if it is possible to stay in Emacs at all)? > So, I'd still want to know what undesirable behavior would happen under > NS if we don't call Fraise_frame here (and also, why it needs to be > called here rather than elsewhere). > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan > > > > > From adrian.b.robert@gmail.com Sun May 17 18:16:25 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 01:16:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.2 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-px0-f108.google.com (mail-px0-f108.google.com [209.85.216.108]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4I1GMaj014641 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 18:16:23 -0700 Received: by pxi6 with SMTP id 6so1654187pxi.19 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 18:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=XOfqjhdoBwGCbXAs8U3Uwv17/lvBJCO02AuQQ9br5mA=; b=lxr+RjYYTKXnBWnrymA7fhe+HIE8YqFqE6eFVaJtuGjYdOExqQ9zN1QflQKKBSZ4Rg r5PVeVnu520btP0Dq4YdE/j2wrazFrYW8wvtVk7tlyLSMIct/n11wT8zbJZEdUFl5cNk MR6LEJ9Jj4l1V3v87hzcTZCFBiAKdYwKW3nSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=kRXQhbZe1uvH0x1PT44hx2p/TDpVlfYLNVwqCqDpPvdB+fIlTSMeJI6qtlTlw/6/UB Fnk8tgdK/bqDp1a6KXhHrputj2s3CLRGOjztkdN586ZoIs6tikUydRoeglxqvqInr21N iIZNr3bVOgqt5xULfK038L9TSo9HuLnY6aUs4= Received: by 10.115.19.16 with SMTP id w16mr10152773wai.51.1242609376980; Sun, 17 May 2009 18:16:16 -0700 (PDT) Received: from ?10.174.11.32? ([203.146.63.182]) by mx.google.com with ESMTPS id j39sm4238740waf.45.2009.05.17.18.16.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 May 2009 18:16:16 -0700 (PDT) In-Reply-To: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> Cc: David Reitter , 3303@debbugs.gnu.org Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Mon, 18 May 2009 08:16:22 +0700 To: Stefan Monnier X-Mailer: Apple Mail (2.753.1) On May 18, 2009, at 3:43 AM, Stefan Monnier wrote: >>> in frame.c looks plain wrong and should probably just be deleted: >>> frame-selection is never intended to raise (or lower) any frame. >>> If this `raise' is really necessary, then it needs a much more >>> extensive >>> comment justifying its presence. >>> Adrian, could you remove this code, or justify clearly why it's >>> here? > >> I think it is there because we need to raise another (visible) >> frame when >> a frame is deleted. This is standard behavior (and sensible). > > This is a behavior which depends on the window-management policy, so > it's the responsibility of the window-manager (which may even decide > that the focus should return to some other application, which would > make > a lot of sense if the frame was created via $EDITOR=emacsclient). > > So, I'd still want to know what undesirable behavior would happen > under > NS if we don't call Fraise_frame here (and also, why it needs to be > called here rather than elsewhere). The behavior that arose was that no other frame would be selected or have focus after a frame was deleted. NS is click-to-focus, and the user would have to click another one manually, which is wrong on this platform. There is no behavior built into the NS window manager to choose another application window to be active after the active one has been removed -- this is left to application code. This can be put in the comment if it would clarify -- the thing is I did not and don't understand why other terms, W32 at least, don't need it as well. From monnier@iro.umontreal.ca Sun May 17 20:26:05 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 03:26:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4I3Q1VY016132 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 20:26:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAGJyEEpMCovv/2dsb2JhbACBT8xmhAEFhWo X-IronPort-AV: E=Sophos;i="4.41,208,1241409600"; d="scan'208";a="38721404" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 17 May 2009 23:25:55 -0400 Received: by pastel.home (Postfix, from userid 20848) id AA6A18096; Sun, 17 May 2009 23:26:46 -0400 (EDT) From: Stefan Monnier To: Lennart Borgman Cc: 3303@debbugs.gnu.org, David Reitter , Adrian Robert Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> Date: Sun, 17 May 2009 23:26:46 -0400 In-Reply-To: (Lennart Borgman's message of "Mon, 18 May 2009 00:27:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> This is a behavior which depends on the window-management policy, so >> it's the responsibility of the window-manager (which may even decide >> that the focus should return to some other application, which would make >> a lot of sense if the frame was created via $EDITOR=emacsclient). > Shouldn't then frames created via emacsclient be a special case? That > would of course make more sense if the frame was deleted together with > the buffer opened through emacsclient... > For other frames both leaving it to the window manager and staying in > Emacs makes sense to me. Maybe a user option (if it is possible to > stay in Emacs at all)? Part of what you quoted was meant to imply that it's not for Emacs to decide (both that it shouldn't and that it can't: at least under X11 it's usually out of Emacs's control). Stefan From monnier@iro.umontreal.ca Sun May 17 20:32:18 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 03:32:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4I3WEoP017956 for <3303@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 20:32:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAI9zEEpMCovv/2dsb2JhbACBT8xshAEFhWo X-IronPort-AV: E=Sophos;i="4.41,208,1241409600"; d="scan'208";a="38721541" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 17 May 2009 23:32:09 -0400 Received: by pastel.home (Postfix, from userid 20848) id 2D04B8096; Sun, 17 May 2009 23:33:00 -0400 (EDT) From: Stefan Monnier To: Adrian Robert Cc: David Reitter , 3303@debbugs.gnu.org Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> Date: Sun, 17 May 2009 23:33:00 -0400 In-Reply-To: <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> (Adrian Robert's message of "Mon, 18 May 2009 08:16:22 +0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > There is no behavior built into the NS window manager to choose another > application window to be active after the active one has been removed -- > this is left to application code. [ So, nothing gets focus? Keyboard events are just dropped on the floor in such a case? Sounds odd: it should be easy for Apple to provide a sensible default behavior without any negative impact. ] Thanks. That explains why calling Fraise_frame might be necessary. It's still not clear why this place is the right place for it. > This can be put in the comment if it would clarify Yes, please do so, it would help a lot. > -- the thing is I did not and don't understand why other terms, W32 at > least, don't need it as well. Don't know about W32, but under X11, window-managers are expected to (and do) make such decisions. Stefan From adrian.b.robert@gmail.com Mon May 18 01:06:09 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 08:06:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4I8653P028034 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 01:06:06 -0700 Received: by pxi6 with SMTP id 6so1758377pxi.19 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 01:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=bsTN0klMgSQd8XUSU0iTjbPljnDA/MHAt19ECgHp8Fs=; b=X98E3zB8QL+a86FIb6J563dJOfRVgRiKI/jQrBblzI8eqt3PKlGg+TERJWbRhCYfIH lg9eXsTSkq5nZqpR2IyHGAeaeavHpheB10xl68CLpE9jMXX4rJ32AkDQbhFHl0AynA4E QGMCzf3RCqz/aqHVSCkLLCTOtqLqTOhClK5N8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=EJF8S/cxQpQOXsFZ2n8mzykdPMRbKRvu1sgVfnXRTXGhw6nMTi9W5odOtMukyDj83m ubycDkGZfdBkx0h4K1wayqbWpaWJYmJRawyljmVY/dEAtCvnehtxXuWFv1UiHiZl62iP 6R/KULXiXTUIUAQ1HvWIiw5ZgNu2WEOAa/Bwk= Received: by 10.114.176.7 with SMTP id y7mr10809706wae.194.1242633960319; Mon, 18 May 2009 01:06:00 -0700 (PDT) Received: from ?10.174.116.214? ([203.146.63.185]) by mx.google.com with ESMTPS id j39sm4584020waf.10.2009.05.18.01.05.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 01:05:59 -0700 (PDT) In-Reply-To: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> Cc: David Reitter , 3303@debbugs.gnu.org Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Mon, 18 May 2009 15:05:35 +0700 To: Stefan Monnier X-Mailer: Apple Mail (2.753.1) On May 18, 2009, at 10:33 AM, Stefan Monnier wrote: >> There is no behavior built into the NS window manager to choose >> another >> application window to be active after the active one has been >> removed -- >> this is left to application code. > > [ So, nothing gets focus? Keyboard events are just dropped on the > floor > in such a case? Sounds odd: it should be easy for Apple to provide > a sensible default behavior without any negative impact. ] Yes, KB events only get sent to a focused window, except for menu shortcut invocations. It might be that in NSDocument-based apps (which Emacs.app isn't, but would be conceptually similar to if 1- buffer=1-frame) the NSDocument architecture would autofocus the most recently available doc window, but I guess NeXT/Apple decided not to make assumptions otherwise about sensible focus-sequencing. > Thanks. That explains why calling Fraise_frame might be necessary. > It's still not clear why this place is the right place for it. > >> This can be put in the comment if it would clarify > > Yes, please do so, it would help a lot. Done, and I've committed David's fix along with it. (I tried it and observed no problems -- hope that's OK David.) From mituharu@math.s.chiba-u.ac.jp Mon May 18 01:19:09 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 08:19:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4I8J5UX031261 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 01:19:06 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 09CCF2C40; Mon, 18 May 2009 17:19:04 +0900 (JST) Date: Mon, 18 May 2009 17:19:04 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier , 3303@debbugs.gnu.org Cc: Adrian Robert , David Reitter Subject: Re: bug#3303: delete-frame raises old (invisible) frame In-Reply-To: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Sun, 17 May 2009 23:33:00 -0400, Stefan Monnier said: >> There is no behavior built into the NS window manager to choose another >> application window to be active after the active one has been removed -- >> this is left to application code. > [ So, nothing gets focus? Keyboard events are just dropped on the floor > in such a case? Sounds odd: it should be easy for Apple to provide > a sensible default behavior without any negative impact. ] I'm not sure about GNUstep, but at least Cocoa AppKit does what you expect if the main (or possibly some) event loop is running. Actually, the Carbon+AppKit port doesn't do anything special in do_switch_frame. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From david.reitter@gmail.com Mon May 18 08:08:54 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 15:08:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f160.google.com (mail-fx0-f160.google.com [209.85.220.160]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IF8oWm018759 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 08:08:51 -0700 Received: by fxm4 with SMTP id 4so4511536fxm.1 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 08:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=dmoFnpD2KJccYkvx1yd4yfcD6X0PPDV7/st32/i7P1g=; b=YvfjAeHOVTheE0uxgtyJzMm/RTIF1WscNZiE9Lxy/eXxbGSDZKDVUp+XJLtvCRDr0+ vXifWyuKpsOazAu9OyA/JSqKntnxV5okOc+APVlYDW934Lr2ZpbxfmzlA0kaic/dYYSB W2HeZ+3N1kd2ihjJaDmAJiotQkAPrEG/JW5Eg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=Rz1xnDwUoy+lpCY6BkFzbxV7a7eOkRHAKUCHNe4ZmWImSmVUT9Wu2JemhxPzoP7eky WjBNKl4aQoT0ezm9PuaFFY+bBTjPI6ChJZ/6tTteW42sZi7p8cJcMWfKshQgArT88gX3 Z2LN5d/q1M3Fk4fzvtdW1NwNI89h+G3TPWygo= Received: by 10.103.193.12 with SMTP id v12mr4144677mup.23.1242659324182; Mon, 18 May 2009 08:08:44 -0700 (PDT) Received: from ?192.168.1.42? (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id e9sm258527muf.2.2009.05.18.08.08.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 08:08:43 -0700 (PDT) Cc: Stefan Monnier , 3303@debbugs.gnu.org Message-Id: From: David Reitter To: Adrian Robert In-Reply-To: <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-21-211631399; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Mon, 18 May 2009 11:08:39 -0400 References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-21-211631399 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 18, 2009, at 4:05 AM, Adrian Robert wrote: > > On May 18, 2009, at 10:33 AM, Stefan Monnier wrote: > >>> There is no behavior built into the NS window manager to choose >>> another >>> application window to be active after the active one has been >>> removed -- >>> this is left to application code. >> >> [ So, nothing gets focus? Keyboard events are just dropped on the >> floor >> in such a case? Sounds odd: it should be easy for Apple to provide >> a sensible default behavior without any negative impact. ] > > Yes, KB events only get sent to a focused window, except for menu > shortcut invocations. It might be that in NSDocument-based apps > (which Emacs.app isn't, but would be conceptually similar to if 1- > buffer=1-frame) the NSDocument architecture would autofocus the most > recently available doc window, but I guess NeXT/Apple decided not to > make assumptions otherwise about sensible focus-sequencing. Precisely for this reason is the patch not sufficient. When there is a hidden frame, and you delete the only other existing frame, we end up in a situation where there is no key window to receive the event, and all events (including menu items) are simply dropped. I've experimented with NSWindow's makeKeyWindow, which should leave the order of the windows so the frame stays hidden. However, this alone doesn't do the job. Events still get dropped when you do (progn (make-frame-invisible (selected-frame) t) (make-frame) (delete-frame (selected-frame) t)) Note that I had to add FRAME_SAMPLE_VISIBILITY compared to the last patch I sent. diff --git a/src/frame.c b/src/frame.c index de857af..144b8ac 100644 --- a/src/frame.c +++ b/src/frame.c @@ -778,6 +778,9 @@ affects all frames on the same terminal device. */) is dead. The value of NORECORD is passed as argument to Fselect_window. */ +#ifdef HAVE_NS +extern void x_make_key_frame (struct frame *f); +#endif Lisp_Object do_switch_frame (frame, track, for_deletion, norecord) @@ -868,8 +871,12 @@ do_switch_frame (frame, track, for_deletion, norecord) #ifdef NS_IMPL_COCOA /* term gets no other notification of this */ + FRAME_SAMPLE_VISIBILITY (XFRAME (selected_frame)); if (for_deletion) - Fraise_frame(Qnil); + if (FRAME_VISIBLE_P (XFRAME (selected_frame))) + Fraise_frame(Qnil); + else + x_make_key_frame(XFRAME (selected_frame)); #endif /* We want to make sure that the next event generates a frame-switch diff --git a/src/nsterm.m b/src/nsterm.m index 7e3028a..0994f7d 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -910,6 +910,20 @@ ns_raise_frame (struct frame *f) } +void +x_make_key_frame (struct frame *f) +/* -------------------------------------------------------------------------- + Make window active + -------------------------------------------------------------------------- */ +{ + NSView *view = FRAME_NS_VIEW (f); + check_ns (); + BLOCK_INPUT; + [[view window] makeKeyWindow]; + UNBLOCK_INPUT; +} + + static void ns_lower_frame (struct frame *f) /* -------------------------------------------------------------------------- --Apple-Mail-21-211631399 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUxODE1MDg0MFowIwYJKoZIhvcNAQkEMRYEFMMrVFZqZCVAoLU7xlXmetluHGZL MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgJ4iCj7dcQJIHn968WACFHSYHNPxAETumaUCXk4nO7XGoc5OJR/y7a5/Lhojd0Y2UsHc +taRzd8aDPokynv/eARlzWaKqBIrwg6OCyuKMaRmBGKp+yGaQeSjpFxoPMsAmNZZtvLWQb/oDUjP CtExGMMPgb5msGwh75W++NLpUXJXAAAAAAAA --Apple-Mail-21-211631399-- From monnier@iro.umontreal.ca Mon May 18 13:12:41 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 20:12:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IKCbqw011161 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 13:12:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAO9dEUpMCovv/2dsb2JhbACBT80khAEFhWo X-IronPort-AV: E=Sophos;i="4.41,211,1241409600"; d="scan'208";a="38738372" Received: from 76-10-139-239.dsl.teksavvy.com (HELO ceviche.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 18 May 2009 16:12:32 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 4B6DBB4136; Mon, 18 May 2009 16:12:32 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: Adrian Robert , 3303@debbugs.gnu.org Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> Date: Mon, 18 May 2009 16:12:32 -0400 In-Reply-To: (David Reitter's message of "Mon, 18 May 2009 11:08:39 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> [ So, nothing gets focus? Keyboard events are just dropped on the floor >>> in such a case? Sounds odd: it should be easy for Apple to provide >>> a sensible default behavior without any negative impact. ] >> >> Yes, KB events only get sent to a focused window, except for menu shortcut >> invocations. It might be that in NSDocument-based apps (which Emacs.app >> isn't, but would be conceptually similar to if 1- >> buffer=1-frame) the NSDocument architecture would autofocus the most >> recently available doc window, but I guess NeXT/Apple decided not to make >> assumptions otherwise about sensible focus-sequencing. > Precisely for this reason is the patch not sufficient. I do not understand. > When there is a hidden frame, and you delete the only other existing frame, > we end up in a situation where there is no key window to receive the event, > and all events (including menu items) are simply dropped. Could you explain concretely why it's a problem. Stefan PS: Another problem I see is that I don't think raise-frame should make an invisible frame visible. It's right for iconified frames, but I don't think it's right for invisible frames. I.e. a patch like the one below might be a good change (not for 23.1, tho, obviously). === modified file 'src/frame.c' --- src/frame.c 2009-05-05 14:50:29 +0000 +++ src/frame.c 2009-05-18 20:09:22 +0000 @@ -2020,7 +2020,7 @@ if (FRAME_TERMCAP_P (f)) /* On a text-only terminal select FRAME. */ Fselect_frame (frame, Qnil); - else + else if (FRAME_ICONIFIED_P (f)) /* Do like the documentation says. */ Fmake_frame_visible (frame); From david.reitter@gmail.com Mon May 18 16:00:31 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 18 May 2009 23:00:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-qy0-f178.google.com (mail-qy0-f178.google.com [209.85.221.178]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IN0Qa2026611 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 16:00:27 -0700 Received: by qyk8 with SMTP id 8so5720189qyk.19 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 16:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=qQkL4+Y+zUpBTR9fa/S0m6bR4uOIJC0+O46A31bSGeI=; b=HoKLyhKVJhDluSXoNymBnfnCst9PmViCfp6XogXTlL2CEWinoPYDnpxwn+uvNaUWFr VecqGsUaunFEmUAVe1g6bZ2ab7rErQ6UEH44DJzW8xTAijM+II6H530c1cp2rGsDOd0h aaWqk7eqqERwfbqDwPTDb8EQIRGf+OvtKwFmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=X9ONJ5iwxqhGFrUuCbFolneFlZ+0u7GyKc/W4yO3NuPCCR0/2Dy2ShPzB4ch64CzKY PIvTUtQuttT59HxuQs9AJgI/BCH+esLn0MAn46/HYD8ao2ITJMOMHXm5ASN/08vh1m5c E6eAWU8uEq9LoX8gdRh64GubCR9+mVsygy76M= Received: by 10.224.2.75 with SMTP id 11mr6984906qai.3.1242687620361; Mon, 18 May 2009 16:00:20 -0700 (PDT) Received: from SCARLETT.PSY.CMU.EDU (SCARLETT.PSY.CMU.EDU [128.2.249.106]) by mx.google.com with ESMTPS id 7sm343490qwb.46.2009.05.18.16.00.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 16:00:19 -0700 (PDT) Cc: Adrian Robert , 3303@debbugs.gnu.org Message-Id: <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> From: David Reitter To: Stefan Monnier In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-36-239929134; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Mon, 18 May 2009 19:00:17 -0400 References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-36-239929134 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 18, 2009, at 4:12 PM, Stefan Monnier wrote: >> Precisely for this reason is the patch not sufficient. > > I do not understand. > >> When there is a hidden frame, and you delete the only other >> existing frame, >> we end up in a situation where there is no key window to receive >> the event, >> and all events (including menu items) are simply dropped. > > Could you explain concretely why it's a problem. Well, if you have only hidden frames this way, you will receive no key events: (progn (make-frame-invisible (selected-frame) t) (make-frame) (delete-frame (selected-frame) t)) The Lisp level doesn't even see menu events. A little more investigation shows that we get the event in keyDown:, but we discard it in this code: if (![[self window] isKeyWindow]) { /* XXX: There is an occasional condition in which, when Emacs display updates a different frame from the current one, and temporarily selects it, then processes some interrupt-driven input (dispnew.c:3878), OS will send the event to the correct NSWindow, but for some reason that window has its first responder set to the NSView most recently updated (I guess), which is not the correct one. */ if ([[theEvent window] isKindOfClass: [EmacsWindow class]]) [(EmacsView *)[[theEvent window] delegate] keyDown: theEvent]; return; } The outer if condition is true, presumably for the weird reason stated in the comment. The inner if condition is false, so the event doesn't get passed on, and we just discard it. Sticking the "return" into the inner if helps. Of course I'm not so sure if that is the right fix. Even with this workaround/fix, now we're back to the other problem with this bit of code: (progn (make-frame-invisible (selected-frame) t) (make-frame) (delete-frame (selected-frame) t) (make-frame) (sit-for 0) (delete-frame (selected-frame) t)) This will leave a frame visible, i.e. in the last `delete-frame', the frame is deleted, but the other one is made visible. That happens because the FRAME_VISIBLE_P check in do_switch_frame does not return nil for frames that are actually supposed to be hidden. It shouldn't do that... f->visible and f->async_visible are both 1, even at the beginning of do_switch_frame. I don't understand why. Note that this does NOT happen if you run it without the `sit-for' call, e.g. in a single `progn' form. Ideas? --Apple-Mail-36-239929134 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUxODIzMDAxOFowIwYJKoZIhvcNAQkEMRYEFCabeoJilmypBEdxxPBao12EWSy+ MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgL53bEwbf4DMjsTxRKg9P2EtCKdFHt5SKR11bi+lS5HjXBRebnjZE6WptHfUE+dAtcCw l1DI7d+nAsvHRRFxoXTyB4WSwWG6G/TkNSKnPBSFzYUV9mtyzO6br6nWV9d/Ne9EAdpoeq4mVn2r 5JIjB/USC5umfoDsgIAkv/CZFWGvAAAAAAAA --Apple-Mail-36-239929134-- From mituharu@math.s.chiba-u.ac.jp Mon May 18 17:58:49 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 00:58:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,GMAIL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J0whJV027352 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 17:58:44 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 942162C40; Tue, 19 May 2009 09:58:42 +0900 (JST) Date: Tue, 19 May 2009 09:58:42 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: David Reitter , 3303@debbugs.gnu.org Cc: Adrian Robert Subject: Re: bug#3303: delete-frame raises old (invisible) frame In-Reply-To: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Mon, 18 May 2009 11:08:39 -0400, David Reitter said: >>>> There is no behavior built into the NS window manager to choose >>>> another application window to be active after the active one has >>>> been removed -- this is left to application code. >>> >>> [ So, nothing gets focus? Keyboard events are just dropped on the >>> floor in such a case? Sounds odd: it should be easy for Apple to >>> provide a sensible default behavior without any negative impact. >>> ] >> >> Yes, KB events only get sent to a focused window, except for menu >> shortcut invocations. It might be that in NSDocument-based apps >> (which Emacs.app isn't, but would be conceptually similar to if 1- >> buffer=1-frame) the NSDocument architecture would autofocus the >> most recently available doc window, but I guess NeXT/Apple decided >> not to make assumptions otherwise about sensible focus-sequencing. > Precisely for this reason is the patch not sufficient. As I mentioned in (*), neither the above consideration about NSDocument-based vs. non-NSDocument-based nor the updated comment in frame.c is correct. *: http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-05/msg00373.html If you don't observe the problems on the Carbon+AppKit port, then it indicates that they can most likely be solved without touching the platform-independent code. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From monnier@iro.umontreal.ca Mon May 18 19:45:31 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 02:45:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J2jRaM025660 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 19:45:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAI66EUpMCovv/2dsb2JhbACBT8t7hAEFhWo X-IronPort-AV: E=Sophos;i="4.41,212,1241409600"; d="scan'208";a="38745224" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 18 May 2009 22:45:21 -0400 Received: by pastel.home (Postfix, from userid 20848) id C89AB7F29; Mon, 18 May 2009 22:46:19 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: Adrian Robert , 3303@debbugs.gnu.org Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> Date: Mon, 18 May 2009 22:46:19 -0400 In-Reply-To: <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> (David Reitter's message of "Mon, 18 May 2009 19:00:17 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> Precisely for this reason is the patch not sufficient. >> >> I do not understand. >> >>> When there is a hidden frame, and you delete the only other existing >>> frame, >>> we end up in a situation where there is no key window to receive the >>> event, >>> and all events (including menu items) are simply dropped. >> >> Could you explain concretely why it's a problem. > Well, if you have only hidden frames this way, you will receive no key > events: > (progn > (make-frame-invisible (selected-frame) t) > (make-frame) > (delete-frame (selected-frame) t)) > The Lisp level doesn't even see menu events. You just repeated what you had already written. It's not concrete enough for me to understand. What means "receive no key event" or "Lisp doesn't even see menu events"? > A little more investigation shows that we get the event in keyDown:, but we > discard it in this code: > if (![[self window] isKeyWindow]) > { > /* XXX: There is an occasional condition in which, when Emacs display > updates a different frame from the current one, and temporarily > selects it, then processes some interrupt-driven input > (dispnew.c:3878), OS will send the event to the correct NSWindow, > but > for some reason that window has its first responder set to the > NSView > most recently updated (I guess), which is not the correct one. */ > if ([[theEvent window] isKindOfClass: [EmacsWindow class]]) > [(EmacsView *)[[theEvent window] delegate] keyDown: theEvent]; > return; > } I think I understand: you mean that when there's only one frame and it's invisible, we actively ignore *all* events (rather than the OS refusing to deliver them to us), and hence Emacs becomes completely unresponsive. Yes, that bug would need to be fixed. > Even with this workaround/fix, now we're back to the other problem with this > bit of code: > (progn > (make-frame-invisible (selected-frame) t) > (make-frame) > (delete-frame (selected-frame) t) > (make-frame) > (sit-for 0) > (delete-frame (selected-frame) t)) I still don't understand the above code, for the reason already explained: you use `selected-frame' in a way that seems to imply that you expect make-frame to change the selected-frame, where its docstring says explicitly that it doesn't. Stefan From david.reitter@gmail.com Mon May 18 19:56:49 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 02:56:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J2uhUn029169 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 19:56:44 -0700 Received: by ewy26 with SMTP id 26so5141158ewy.1 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 19:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=2FQOv0CCOvpinCd5X6nRPlpgeSKzMJhvebI5WUVFYtM=; b=UoQQndHLbK79irXWZnMStZjIZIi/C+Av9VqLrWmkdvrbcNdo4+P8Qlas1hT/FM0VP/ lLWNMWvlY4Kb38oGIAwfdqEowFXyDpfCVdPga+gzAOMeoI4JgNyq5lxUBcpJV9oCV1j+ vXIZPUP9OV5RYFfIJFOCqutAfSPUzqS6F/Zug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=ahbLoB4e/0e/NLHvW2JDu22tX4zxR3foJTpbdR/Sic/juKEbao5qS6PrzlwhG51Vpz wqF7r9deS3YDEPgipclN73LV7x9p0ykvOJyrW0vBaVXXutxxx+KPBb3eP7HoZsDxmNbz A2jhGb+weJUP0POp1Aol3ONVRtDSvMlwWw7LY= Received: by 10.210.11.13 with SMTP id 13mr182226ebk.81.1242701797429; Mon, 18 May 2009 19:56:37 -0700 (PDT) Received: from ?192.168.1.42? (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 28sm3762815eye.46.2009.05.18.19.56.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 19:56:36 -0700 (PDT) Cc: Adrian Robert , 3303@debbugs.gnu.org Message-Id: From: David Reitter To: Stefan Monnier In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-38-254104052; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Mon, 18 May 2009 22:56:32 -0400 References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-38-254104052 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 18, 2009, at 10:46 PM, Stefan Monnier wrote: > You just repeated what you had already written. It's not concrete > enough for me to understand. What means "receive no key event" or > "Lisp > doesn't even see menu events"? I enter a key sequence, e.g. C-x 5 2, and Emacs does not react. I select a menu item from the Options menu, and Emacs does not react. > I think I understand: you mean that when there's only one frame and > it's > invisible, we actively ignore *all* events (rather than the OS > refusing > to deliver them to us), and hence Emacs becomes completely > unresponsive. > Yes, that bug would need to be fixed. This does not happen all the time when there is only one frame and it is invisible, but it is perfectly reproducible for me with the code I sent. > I still don't understand the above code, for the reason already > explained: you use `selected-frame' in a way that seems to imply that > you expect make-frame to change the selected-frame, where its > docstring > says explicitly that it doesn't. Ah, now I see why you don't understand. The doc string says that the system may select it, and that's exactly what happens here on Cocoa/OSX. This reproduces the problem just as well: (progn (make-frame-invisible (selected-frame) t) (select-frame (make-frame)) (delete-frame (selected-frame) t) (select-frame (make-frame)) (sit-for 0) (delete-frame (selected-frame) t)) i.e. we end up with a visible frame, the frame that we hid initially. --Apple-Mail-38-254104052 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUxOTAyNTYzM1owIwYJKoZIhvcNAQkEMRYEFKDcxbh33dJFzLFnJU0kcO9ruxyR MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgGO9d6cJuAoV2SkoSaSsJ1kusmVJnkSzfprx0dfzry6gv2N1zESWYjuTopRAFjre8y0W /pf6HaYbxVxp4zuVNkGiuTyWLqDRxeB55ap0IhDrSzvqYF4q3ZUI00NTv7i24hI1yCrtxM33DVIG oPxR0524ozAArCJzJNDrghVldnWOAAAAAAAA --Apple-Mail-38-254104052-- From monnier@iro.umontreal.ca Mon May 18 20:08:33 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 03:08:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J38TA1032636 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 20:08:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEADO/EUpMCovv/2dsb2JhbACBT8t6hAEFhWo X-IronPort-AV: E=Sophos;i="4.41,212,1241409600"; d="scan'208";a="38745566" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 18 May 2009 23:08:14 -0400 Received: by pastel.home (Postfix, from userid 20848) id C43BB7F29; Mon, 18 May 2009 23:09:12 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: Adrian Robert , 3303@debbugs.gnu.org Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> Date: Mon, 18 May 2009 23:09:12 -0400 In-Reply-To: (David Reitter's message of "Mon, 18 May 2009 22:56:32 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > i.e. we end up with a visible frame, the frame that we hid initially. As mentioned, part of the reason is that raise-frame incorrectly makes the frame visible. Admittedly, the correctness is debatable, since the docstring says "If frame is iconified, make it visible" whereas the Elisp manual says "If FRAME is invisible or iconified, this makes it visible". So the code is correct w.r.t the Elisp manual but not the docstring. I actually believe the docstring describes the behavior we want. Stefan From david.reitter@gmail.com Mon May 18 20:15:25 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 03:15:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J3FKio002299 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 20:15:21 -0700 Received: by ey-out-2122.google.com with SMTP id d26so1038050eyd.13 for <3303@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 20:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=p494m7iPk9R9IRmCc8aE5T1qvdOp4OyfFosm5EKtgOo=; b=DqVig7WTjPdg+EFZrX1WLJr2SvKHazuAg7VU3odz+65wcIaqcaQY15TB2lMCv34STv WmFLbAIUKpf5VonUr5dsS0TZc1qnLmd2DWz+ULWi1zaX+II09gAqlOaIup8VT6jM2Mwj ctZzOHjeD2v7gq0+suxCuk4IlaqUWsJuYqLHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=kuxX3sMqY2tD0fc5U7TRlPknlCwefF8VU/d2DKgZoRnMKWJCy4S6lUiOna9CuI/GQJ XPShf2rh8ic1uJmY88awixKzbf6W6x2sCIQo0HfD5mfmqBdE20pvB4gpe3FowkaBB/0I wcIdpa2BJGu37rAmAQuv9PnM9c59KV299glig= Received: by 10.210.53.1 with SMTP id b1mr1423254eba.31.1242702919384; Mon, 18 May 2009 20:15:19 -0700 (PDT) Received: from ?192.168.1.42? (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 24sm2280891eyx.43.2009.05.18.20.15.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 20:15:18 -0700 (PDT) Cc: Adrian Robert , 3303@debbugs.gnu.org Message-Id: <93D72634-9A9C-45E0-8249-A5178C538E3A@gmail.com> From: David Reitter To: Stefan Monnier In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-39-255226083; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Mon, 18 May 2009 23:15:14 -0400 References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-39-255226083 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 18, 2009, at 11:09 PM, Stefan Monnier wrote: >> i.e. we end up with a visible frame, the frame that we hid initially. > > As mentioned, part of the reason is that raise-frame incorrectly makes > the frame visible. > > Admittedly, the correctness is debatable, since the docstring says "If > frame is iconified, make it visible" whereas the Elisp manual says "If > FRAME is invisible or iconified, this makes it visible". So the > code is > correct w.r.t the Elisp manual but not the docstring. I actually > believe the docstring describes the behavior we want. What I described happens with your path installed just the same, so it is really only part of the problem. One issue I can see there in NS is that NS hides frames by moving them behind the desktop in the view hierarchy, so raising them implies making them visible. Of course we could (and should) add a check for frame visibility to the appropriate NS functions. As far as I remember, raising implied making a frame visible in Emacs 22/Carbon. I'm not sure if a change to the behavior of raise-frame would be a good idea at this stage; the bug at hand needs fixing of course. --Apple-Mail-39-255226083 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUxOTAzMTUxNVowIwYJKoZIhvcNAQkEMRYEFDBP78tZiSehJPWlBXaFxILioJSO MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgKQr8wB2tTewwhWCvm5HnRmCpJ8h/xVWn+CcwR/Bg6DlsK5pbIzsCT3SgIdSq3scYFxi 0c2Kms1KAZbY+xxnwmS0bn5y0bPSn1RLnpZYMn4iI4emoDJX4D05RgGa8CL0quy/CsjOSswHezCD PZuWUX8IN4km9tqFAQSZ89IonkOsAAAAAAAA --Apple-Mail-39-255226083-- From mituharu@math.s.chiba-u.ac.jp Tue May 19 01:20:26 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 08:20:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J8KMFI022955 for <3303@emacsbugs.donarmstrong.com>; Tue, 19 May 2009 01:20:24 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 82EF82C44; Tue, 19 May 2009 17:20:20 +0900 (JST) Date: Tue, 19 May 2009 17:20:20 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: David Reitter , 3303@debbugs.gnu.org Cc: Stefan Monnier , Adrian Robert Subject: Re: bug#3303: delete-frame raises old (invisible) frame In-Reply-To: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Mon, 18 May 2009 22:56:32 -0400, David Reitter said: >> I still don't understand the above code, for the reason already >> explained: you use `selected-frame' in a way that seems to imply >> that you expect make-frame to change the selected-frame, where its >> docstring says explicitly that it doesn't. > Ah, now I see why you don't understand. > The doc string says that the system may select it, and that's > exactly what happens here on Cocoa/OSX. That's due to the following NS-specific code in term/ns-win.el: ;; frame will be focused anyway, so select it ;; (if this is not done, modeline is dimmed until first interaction) (add-hook 'after-make-frame-functions 'select-frame) I would read this comment as "this is a workaround". TRT is to investigate why the modeline is dimmed until the first interaction and fix it, of course. Otherwise, the NS port will face hard-to-find incompatibilities in various elisp packages. The docstring says "The previously selected frame remains selected. However, the window system may select the new frame for its own reasons, for instance ...". In (non-NS) click-to-focus environments, the selection of the new frame does not happen immediately but does when the Lisp interpreter goes back to the command loop and reads events (cf. docstring of select-frame). YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From monnier@iro.umontreal.ca Tue May 19 07:29:54 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 19 May 2009 14:29:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4JETncZ006935 for <3303@emacsbugs.donarmstrong.com>; Tue, 19 May 2009 07:29:50 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAL9fEkpMCovv/2dsb2JhbACBT84ThAIFhXCCOQ X-IronPort-AV: E=Sophos;i="4.41,215,1241409600"; d="scan'208";a="38759479" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 19 May 2009 10:29:25 -0400 Received: by pastel.home (Postfix, from userid 20848) id 393027F29; Tue, 19 May 2009 10:30:26 -0400 (EDT) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: David Reitter , 3303@debbugs.gnu.org, Adrian Robert Subject: Re: bug#3303: delete-frame raises old (invisible) frame Message-ID: References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> Date: Tue, 19 May 2009 10:30:26 -0400 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Tue, 19 May 2009 17:20:20 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> I still don't understand the above code, for the reason already >>> explained: you use `selected-frame' in a way that seems to imply >>> that you expect make-frame to change the selected-frame, where its >>> docstring says explicitly that it doesn't. >> Ah, now I see why you don't understand. >> The doc string says that the system may select it, and that's >> exactly what happens here on Cocoa/OSX. > That's due to the following NS-specific code in term/ns-win.el: > ;; frame will be focused anyway, so select it > ;; (if this is not done, modeline is dimmed until first interaction) > (add-hook 'after-make-frame-functions 'select-frame) > I would read this comment as "this is a workaround". TRT is to > investigate why the modeline is dimmed until the first interaction and > fix it, of course. Otherwise, the NS port will face hard-to-find > incompatibilities in various elisp packages. Agreed. Could someone remove the above line and install a proper fix for it? Stefan From david.reitter@gmail.com Tue May 19 19:07:16 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 20 May 2009 02:07:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,FVGT_m_MULTI_ODD, HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4K27BpH021719 for <3303@emacsbugs.donarmstrong.com>; Tue, 19 May 2009 19:07:13 -0700 Received: by ewy26 with SMTP id 26so244357ewy.1 for <3303@emacsbugs.donarmstrong.com>; Tue, 19 May 2009 19:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=7NKRwAjfmgMMzuEfTY8BoiTXzQa23Vma98wPrgl+xeo=; b=JsAr9ts8OlpnrSiZsgwMMevXfC1kFImPvYAupTgPGsB7fPtIKq+zkwtNol2MP4A2Ym d/0vcb1wkoW45dlKR+KMmN0Cs8Ybi9yB/Eq8grsjapGTD+EzvSR9/equK3UQhXpIBm1T smpv4+TbfIVgO19MGFuPNMtAzyTls1Tr1uYFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=dqibmutBPv1oA8LwqxfNQ0dxtR1WhxoJIlXDrB8f4qSNGoI8inrucs8As45zeFll/G os06HyAP1NYo4/7GuHp59q3NuuUyMwW4sR47ti5zmhCBs7A1Y9BURelgDqNkUC/F5lU0 rN9xsj+lpwryZfJg11iAMlT3j/dAOxvz1sGPI= Received: by 10.210.36.8 with SMTP id j8mr5726903ebj.44.1242785226201; Tue, 19 May 2009 19:07:06 -0700 (PDT) Received: from ?192.168.1.42? (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) by mx.google.com with ESMTPS id 28sm1114965eye.16.2009.05.19.19.07.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 May 2009 19:07:05 -0700 (PDT) Cc: 3303@debbugs.gnu.org Message-Id: From: David Reitter To: Stefan Monnier , Adrian Robert In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-7-337531945; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: bug#3303: delete-frame raises old (invisible) frame Date: Tue, 19 May 2009 22:07:00 -0400 References: <2C87549A-2553-4477-BF77-6258A1CC32BE@gmail.com> <6A510E91-6262-44CF-AA62-315DECB52EF6@gmail.com> <90E34251-C034-4169-91FE-22A28C94901F@gmail.com> <73A0DAB1-9D16-4E35-A9F7-E9E4CCEACC50@gmail.com> <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> X-Mailer: Apple Mail (2.935.3) --Apple-Mail-7-337531945 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 18, 2009, at 10:56 PM, David Reitter wrote: > The doc string says that the system may select it, and that's > exactly what happens here on Cocoa/OSX. > This reproduces the problem just as well: > > (progn > (make-frame-invisible (selected-frame) t) > (select-frame (make-frame)) > (delete-frame (selected-frame) t) > (select-frame (make-frame)) > (sit-for 0) > (delete-frame (selected-frame) t)) > > i.e. we end up with a visible frame, the frame that we hid initially. OK, I have traced this a bit further and reduced it to this: (progn (setq aa1 (selected-frame)) (make-frame-invisible (selected-frame) t) (setq aa2 (selected-frame) aa2v (frame-visible-p (selected-frame))) (sit-for 1) (setq aa3 (selected-frame) aa3v (frame-visible-p (selected-frame)))) (list aa1 aa2 aa2v aa3 aa3v) After evaluating the first sexp (Emacs -Q), one can see that the selected frame doesn't change at any point. But aa2v is nil (correctly so), and aa3v is suddenly t. This does not happen with Emacs 22/Appkit. Both aa2v and aa3v are nil, as they should. Could someone check what the behavior is in another port (of 23)? I believe that this is the cause of the problems we're after. In the previous examples, when delete_frame calls do_switch_frame, the frame is already deemed visible, even though it hasn't been made visible through the appropriate system call. The above example demonstrates that something (in the event loop, presumably) sets frame visibility. It is not a call to FRAME_SAMPLE_VISIBILITY, which is done in `frame- visible-p' anyways. (The NS port always sets f->async_visible and lets this macro set ->visible later.) --Apple-Mail-7-337531945 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFxDCCAn0w ggHmoAMCAQICED6shx13jEDrq0eL8FRq5ykwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwOTAyMDgwMVoXDTA5MTIwOTAyMDgw MVowYjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxJjAkBgkqhkiG9w0BCQEWF2RhdmlkLnJlaXR0ZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDOdo6kAwlkBxUb8dj4saMbYg4SVng8CUePFn3cjjWrakBTbUVa4Z0n wlUxr7AitEeKhBy5nGhu96+jKUPrCwYNRCZ0l2ovvuGq4z1m1nZ5/c8WvFlVhieuxXMUfmb/O7D3 IojoX6iS8n5MNNU2IWNNT/AD3vOl6DKgOtOw4J9y+QIDAQABozQwMjAiBgNVHREEGzAZgRdkYXZp ZC5yZWl0dGVyQGdtYWlsLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAIjI8yEW wkiEfA9PMgpjnD6KyCXT0iZjHhW2PkR53yZZLUoTboHnKgsFwYp/gzzIL8J5cvZaRUyMUzXDufPP dRmxxCs2jXXLDD/8bvdvOuMzqgYoFA73fAfsC8S6qUL1PayZ90J8CZHNhDwqWqOA56T+DdKUegJT sqoHKh6OnypTMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJz b25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVow YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU 5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5 jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA+rIcdd4xA66tH i/BUaucpMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA5MDUyMDAyMDcwMVowIwYJKoZIhvcNAQkEMRYEFE/oI+uR/2bZ2j/6ScX+zDIqOZjn MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPqyHHXeMQOurR4vwVGrnKTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPqyHHXeMQOurR4vwVGrnKTANBgkqhkiG9w0B AQEFAASBgD0dU7R/xbgROzPlclF9XLSYUY2eKI8GVn/vYVT+hWWfuWtjm8qkWa2cawO3aiItXDAl X4lZb8TXUolB+uRwvham3h1a66P2OJS3LEMJ5NM2nZ1TdQ13xmiVDDdETLXRDqCC6PHfVajXx41L KoSG05ce4mSy04wIgUNibmxmioCQAAAAAAAA --Apple-Mail-7-337531945-- From reitter@cmu.edu Thu May 21 20:57:21 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 22 May 2009 03:57:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,FVGT_m_MULTI_ODD, IMPRONONCABLE_2,MURPHY_DRUGS_REL8 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4M3vGnv026876 for <3303@emacsbugs.donarmstrong.com>; Thu, 21 May 2009 20:57:18 -0700 Received: from [192.168.1.42] (pool-71-162-19-47.pitbpa.east.verizon.net [71.162.19.47]) (user=reitter mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.3/8.13.8) with ESMTP id n4M3v91H024519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 May 2009 23:57:10 -0400 Message-Id: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> From: David Reitter To: 3303@debbugs.gnu.org Content-Type: multipart/signed; boundary=Apple-Mail-31-516940623; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: delete-frame raises old (invisible) frame Date: Thu, 21 May 2009 23:57:08 -0400 Cc: Adrian Robert , Stefan Monnier , Chong Yidong , YAMAMOTO Mitsuharu X-Mailer: Apple Mail (2.935.3) X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.5.22.33435 X-SMTP-Spam-Clean: 10% ( CTYPE_MULTIPART_NO_QUOTE 0.5, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, TO_NO_NAME 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __RDNS_POOLED_9 0, __SANE_MSGID 0, __TO_MALFORMED_2 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 --Apple-Mail-31-516940623 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit OK, I think I have a set of fixes now for this bug. The problems included swallowed events, setting async_visible and async_iconified from drawRect under the false assumption that this proves that the frame view is visible, and attendant failure to set visibility correctly when creating the frame (as the other ports, including Appkit, do). Also, we separate visibility from frame order in the NS layer. Description, test cases and patch below. Can someone look this over to see if there is anything obviously wrong? I'll check it in pending feedback. - David PS.: I agree with the proposed change to after-make-frame-functions (not selecting the frame immediately), but this doesn't relate to the bug at hand. Also, I don't know why the modeline isn't updated. Desc: frame.c: Fraise_frame: do not make invisible frames visible (Stefan Monnier). nsterm.m: ns_raise_frame(): only raise frame if visible. x_make_frame_visible(): move frame to front rather than calling ns_raise_frame(). keyDown: do not swallow events that aren't re-sent if frame isn't key window. drawRect: do not set visibility/iconified flags because drawRect may be called by NSView even if the frame is hidden. nsfns.m: Fx_create_frame(): follow other ports in determining visibility; default to t. Ensure async_visible is set. Test cases: ;; test case ;; second time around aaa is t (let ((f (selected-frame))) (make-frame-invisible f t) (setq aa2v (frame-visible-p f)) (redisplay) (setq aa3v (frame-visible-p f)) ) ;; frame should be gone (list aa2v aa3v) ;; should be nil nil ;; test case (progn (make-frame-invisible (selected-frame) t) (select-frame (make-frame)) (delete-frame (selected-frame) t) (select-frame (make-frame)) (sit-for 0) (delete-frame (selected-frame) t)) ;; there should be no frame Patch: diff --git a/src/frame.c b/src/frame.c index afcc96c..fbb00ba 100644 --- a/src/frame.c +++ b/src/frame.c @@ -2024,7 +2024,7 @@ doesn't support multiple overlapping frames, this function selects FRAME. */) if (FRAME_TERMCAP_P (f)) /* On a text-only terminal select FRAME. */ Fselect_frame (frame, Qnil); - else + else if (FRAME_ICONIFIED_P (f)) /* Do like the documentation says. */ Fmake_frame_visible (frame); diff --git a/src/nsfns.m b/src/nsfns.m index 01ffcf1..25d9b30 100644 --- a/src/nsfns.m +++ b/src/nsfns.m @@ -1317,13 +1317,20 @@ be shared by the new frame. */) if (! f->output_data.ns->explicit_parent) { - tem = x_get_arg (dpyinfo, parms, Qvisibility, 0, 0, RES_TYPE_BOOLEAN); - if (EQ (tem, Qunbound)) - tem = Qnil; - - x_set_visibility (f, tem, Qnil); - if (EQ (tem, Qt)) - [[FRAME_NS_VIEW (f) window] makeKeyWindow]; + tem = x_get_arg (dpyinfo, parms, Qvisibility, 0, 0, RES_TYPE_SYMBOL); + if (EQ (tem, Qunbound)) + tem = Qt; + x_set_visibility (f, tem, Qnil); + if (EQ (tem, Qicon)) + x_iconify_frame (f); + else if (! NILP (tem)) + { + x_make_frame_visible (f); + f->async_visible=1; + [[FRAME_NS_VIEW (f) window] makeKeyWindow]; + } + else + f->async_visible=0; } if (FRAME_HAS_MINIBUF_P (f) diff --git a/src/nsterm.m b/src/nsterm.m index 9ca74e8..d7a8f81 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -895,9 +895,14 @@ ns_raise_frame (struct frame *f) { NSView *view = FRAME_NS_VIEW (f); check_ns (); - BLOCK_INPUT; - [[view window] makeKeyAndOrderFront: NSApp]; - UNBLOCK_INPUT; + + FRAME_SAMPLE_VISIBILITY (f); + if (FRAME_VISIBLE_P (f)) + { + BLOCK_INPUT; + [[view window] makeKeyAndOrderFront: NSApp]; + UNBLOCK_INPUT; + } } @@ -979,11 +984,17 @@ x_make_frame_visible (struct frame *f) -------------------------------------------------------------------------- */ { NSTRACE (x_make_frame_visible); + NSView *view = FRAME_NS_VIEW (f); /* XXX: at some points in past this was not needed, as the only place that called this (frame.c:Fraise_frame ()) also called raise_lower; if this ends up the case again, comment this out again. */ if (!FRAME_VISIBLE_P (f)) - ns_raise_frame (f); + { + BLOCK_INPUT; + [[view window] makeKeyAndOrderFront: NSApp]; + UNBLOCK_INPUT; + } + f->async_visible = 1; } @@ -4461,7 +4472,8 @@ extern void update_window_cursor (struct window *w, int on); if (!emacs_event) return; - if (![[self window] isKeyWindow]) + if (![[self window] isKeyWindow] + && [[theEvent window] isKindOfClass: [EmacsWindow class]]) { /* XXX: There is an occasional condition in which, when Emacs display updates a different frame from the current one, and temporarily @@ -4469,8 +4481,7 @@ extern void update_window_cursor (struct window *w, int on); (dispnew.c:3878), OS will send the event to the correct NSWindow, but for some reason that window has its first responder set to the NSView most recently updated (I guess), which is not the correct one. */ - if ([[theEvent window] isKindOfClass: [EmacsWindow class]]) - [(EmacsView *)[[theEvent window] delegate] keyDown: theEvent]; + [(EmacsView *)[[theEvent window] delegate] keyDown: theEvent]; return; } @@ -5466,8 +5477,6 @@ extern void update_window_cursor (struct window *w, int on); ns_clear_frame_area (emacsframe, x, y, width, height); expose_frame (emacsframe, x, y, width, height); - emacsframe->async_visible = 1; - emacsframe->async_iconified = 0; } --Apple-Mail-31-516940623 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGODCCAvEw ggJaoAMCAQICEEUTODS9VcXIOFaPH+ApeTwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyNzAwMzgxNloXDTA5MDgyNzAwMzgx NlowWjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxHjAcBgkqhkiG9w0BCQEWD3JlaXR0ZXJAY211LmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJW3Pr3O1TOI9MTahUDKcJkkoZQOmnQVYtchDAALotmkjxNO/wC2b+CiDGGg +8TbJ/EwdMD2IOh1TilL/SXKk2txTgduV5yBrYXk04z1cGxNcCCTRiSZY1A5I3rvnP2jhUf8I49O WXFs8v8XvcJ0o1wFoPITU7b9KBLg22kl+DqNuj10fCLQldlNfe4o5PX/TWFE/NqI+//Ooehr+5hY B1XtAXQXU3/DC6M8l6Sqsm0vw5OO44K7KceG85zQchZ60LOJnGWA2UKcfNTIZGr18LUJMdl6kiU2 TEwy1H/3JAOMmekIbiQ7AWDiVYlkY6QUXBmgAPizQ81yOL3u/sUolt0CAwEAAaMsMCowGgYDVR0R BBMwEYEPcmVpdHRlckBjbXUuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAuxCV 2UwfCwGkNBLsntGFfOObkWhvGLwol+lIdGLGBUll1A1QXdL279qMr2Nk1yR8tVgxx36z3p29itxu jRI7e5WA/devk3WIZwjK4MrWmC/TS5FAbR5PD/Q8iUXaiqQJR39kOdokEVAS3R8wYnHDSV/eQkUx OhDWpDhMbdCgtk4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HO AdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIAC ZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB /wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVBy aXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FD lpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2p nDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEUTODS9VcXI OFaPH+ApeTwwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDkwNTIyMDM1NzA5WjAjBgkqhkiG9w0BCQQxFgQUkY+8OvaYD7TEVoa36sbi0k75 GKUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MA0GCSqGSIb3 DQEBAQUABIIBAJTBN+EUkwBYcI/NtrivaKDc2W5Mb+TSuuzBNbWO74faUqo2QIZJv3h2KnMBdlEQ qGsIvlq6JP9e3csS6BvInQz9Po8Z1CvZ39f4nbCScSzUXmP1uoZK+3zRirlOc1g7Sf0Mnb/y8gbF BwN1JAcWrxtPN5kLzfBdzween2yae4j1fn5rRHaL8vBWCTBRezQBlyqYt/uHerlBJWoevHm0P3KL UeO4MgGLOVa2lUmUgbMKR1tZ0Yc4yL1/BAr0ThFYtQ/fxUCD/Hx+h+1Rx3mXTPHpDXiLxdfWS0x9 OGmvwfv9Y9Cq8cl3rwx8cA0YFip++kkAKvX6dPCZ+29cyFcJansAAAAAAAA= --Apple-Mail-31-516940623-- From monnier@IRO.UMontreal.CA Mon May 25 14:34:01 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 25 May 2009 21:34:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from harpie.CC.UMontreal.CA (harpie.cc.umontreal.ca [132.204.2.134]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4PLXucM012751 for <3303@emacsbugs.donarmstrong.com>; Mon, 25 May 2009 14:33:57 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n4PFHH0S025704; Mon, 25 May 2009 11:17:18 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id C7E8F3A07A; Mon, 25 May 2009 11:17:17 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: 3303@debbugs.gnu.org, Adrian Robert , Chong Yidong , YAMAMOTO Mitsuharu Subject: Re: delete-frame raises old (invisible) frame Message-ID: References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> Date: Mon, 25 May 2009 11:17:17 -0400 In-Reply-To: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> (David Reitter's message of "Thu, 21 May 2009 23:57:08 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3281=0 > OK, I think I have a set of fixes now for this bug. Good, thanks. > PS.: I agree with the proposed change to after-make-frame-functions (not > selecting the frame immediately), but this doesn't relate to the bug at > hand. Also, I don't know why the modeline isn't updated. Agreed, this is a separate problem. I'm not familiar enough with the NS code to judge if the patch is OK, but here are some comments: > frame.c: > Fraise_frame: do not make invisible frames visible (Stefan Monnier). This is not OK for 23.1. It might be good to try it for 23.2. Also I think your other changes should make it unnecessary for the problem we're trying to fix. > nsterm.m: > ns_raise_frame(): only raise frame if visible. Since you say that "invisible" is implemented by lowering the window below the background, this seems like a plain bug-fix, yes. > x_make_frame_visible(): move frame to front rather than calling > ns_raise_frame(). Sounds right. > keyDown: do not swallow events that aren't re-sent if frame isn't > key window. If you say so. > drawRect: do not set visibility/iconified flags because drawRect may be > called by NSView even if the frame is hidden. Do you happen to know why/when NSView might be called even for a frame that's not visible? > nsfns.m: > Fx_create_frame(): follow other ports in determining visibility; default to > t. Ensure async_visible is set. Sounds good. > + f->async_visible=1; [...] > + f->async_visible=0; Please put spaces around infix operators (like `=' above). > @@ -895,9 +895,14 @@ ns_raise_frame (struct frame *f) > { > NSView *view = FRAME_NS_VIEW (f); > check_ns (); > - BLOCK_INPUT; > - [[view window] makeKeyAndOrderFront: NSApp]; > - UNBLOCK_INPUT; > + > + FRAME_SAMPLE_VISIBILITY (f); > + if (FRAME_VISIBLE_P (f)) > + { > + BLOCK_INPUT; > + [[view window] makeKeyAndOrderFront: NSApp]; > + UNBLOCK_INPUT; > + } > } Shouldn't we BLOCK_INPUT around the whole thing, just in case async_visible gets changed at the wrong time? It probably doesn't matter. > { > NSTRACE (x_make_frame_visible); > + NSView *view = FRAME_NS_VIEW (f); > /* XXX: at some points in past this was not needed, as the only place > that > called this (frame.c:Fraise_frame ()) also called raise_lower; > if this ends up the case again, comment this out again. */ > if (!FRAME_VISIBLE_P (f)) > - ns_raise_frame (f); > + { > + BLOCK_INPUT; > + [[view window] makeKeyAndOrderFront: NSApp]; > + UNBLOCK_INPUT; > + } > + f->async_visible = 1; > } I think I'd prefer: if (!FRAME_VISIBLE_P (f)) + { + f->async_visible = 1; ns_raise_frame (f); + } > @@ -5466,8 +5477,6 @@ extern void update_window_cursor (struct window *w, > int on); > ns_clear_frame_area (emacsframe, x, y, width, height); > expose_frame (emacsframe, x, y, width, height); > - emacsframe->async_visible = 1; > - emacsframe->async_iconified = 0; > } In this kind of change, it's often good to keep the old code commented out, with a comment explaining why it was removed (and ideally why it was there before as well). Stefan From reitter@cmu.edu Tue May 26 11:20:33 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 26 May 2009 18:20:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4QIKSh5014543 for <3303@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 11:20:29 -0700 Received: from SCARLETT.PSY.CMU.EDU (SCARLETT.PSY.CMU.EDU [128.2.249.106]) (user=reitter mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.3/8.13.8) with ESMTP id n4QIKMPN019461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 14:20:22 -0400 Cc: 3303@debbugs.gnu.org, Adrian Robert , Chong Yidong , YAMAMOTO Mitsuharu Message-Id: <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> From: David Reitter To: Stefan Monnier In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-36-914333579; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: delete-frame raises old (invisible) frame Date: Tue, 26 May 2009 14:20:22 -0400 References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> X-Mailer: Apple Mail (2.935.3) X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.5.26.180435 X-SMTP-Spam-Clean: 10% ( CTYPE_MULTIPART_NO_QUOTE 0.5, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __TO_MALFORMED_2 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 --Apple-Mail-36-914333579 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks Stefan for reviewing these changes. Agreed on all of your points. I've adopted them and checked this in now since I didn't get any other feedback. >> PS.: I agree with the proposed change to after-make-frame-functions >> (not >> selecting the frame immediately), but this doesn't relate to the >> bug at >> hand. Also, I don't know why the modeline isn't updated. > > Agreed, this is a separate problem. OK, are you keeping track of it, should we file another bug report to do so? >> frame.c: >> Fraise_frame: do not make invisible frames visible (Stefan Monnier). > > This is not OK for 23.1. It might be good to try it for 23.2. > Also I think your other changes should make it unnecessary for the > problem we're trying to fix. As above. >> keyDown: do not swallow events that aren't re-sent if frame isn't >> key window. > > If you say so. What does Adrian say?? I'm just fixing the workaround, even though I don't fully understand the bug that leads to the problem. >> drawRect: do not set visibility/iconified flags because drawRect >> may be >> called by NSView even if the frame is hidden. > > Do you happen to know why/when NSView might be called even for a frame > that's not visible? Unfortunately not, but invisibility does not guarantee absence of drawRect messages unless this is promised somewhere in the NS API. I do think that my patch here is right, though, as other ports set visibility in more obvious places. Perhaps we should make sure that we don't get a lot of drawRect calls for totally obscured frames, which would possibly be a performance- eater. --Apple-Mail-36-914333579 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGODCCAvEw ggJaoAMCAQICEEUTODS9VcXIOFaPH+ApeTwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyNzAwMzgxNloXDTA5MDgyNzAwMzgx NlowWjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxHjAcBgkqhkiG9w0BCQEWD3JlaXR0ZXJAY211LmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJW3Pr3O1TOI9MTahUDKcJkkoZQOmnQVYtchDAALotmkjxNO/wC2b+CiDGGg +8TbJ/EwdMD2IOh1TilL/SXKk2txTgduV5yBrYXk04z1cGxNcCCTRiSZY1A5I3rvnP2jhUf8I49O WXFs8v8XvcJ0o1wFoPITU7b9KBLg22kl+DqNuj10fCLQldlNfe4o5PX/TWFE/NqI+//Ooehr+5hY B1XtAXQXU3/DC6M8l6Sqsm0vw5OO44K7KceG85zQchZ60LOJnGWA2UKcfNTIZGr18LUJMdl6kiU2 TEwy1H/3JAOMmekIbiQ7AWDiVYlkY6QUXBmgAPizQ81yOL3u/sUolt0CAwEAAaMsMCowGgYDVR0R BBMwEYEPcmVpdHRlckBjbXUuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAuxCV 2UwfCwGkNBLsntGFfOObkWhvGLwol+lIdGLGBUll1A1QXdL279qMr2Nk1yR8tVgxx36z3p29itxu jRI7e5WA/devk3WIZwjK4MrWmC/TS5FAbR5PD/Q8iUXaiqQJR39kOdokEVAS3R8wYnHDSV/eQkUx OhDWpDhMbdCgtk4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HO AdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIAC ZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB /wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVBy aXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FD lpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2p nDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEUTODS9VcXI OFaPH+ApeTwwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDkwNTI2MTgyMDIyWjAjBgkqhkiG9w0BCQQxFgQUJkMX6YI4pyZIUDwAdcH6+R0x ZaEwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MA0GCSqGSIb3 DQEBAQUABIIBAFN4SPy5iLDHpTldAf3FBA+kUIMvj4TwDSlNJoaNNi4yP7E2LhZ0ylmeKVGIhLWL Ic72seiwFZJtlnU0oflRy4gpQuP3hJFIkpgFeZ5b2UunlIWWDByKd00iHyIPpGSFLXQNWMoJ3EOw OfsP8mQxShnWP9WqkGj/2/Pt4OJ8XnpRzuiZ/ceBD3qDDovnFqX1UO8FLxVjlAmBWA1mL+Uwepuu H1SdiJZcNSDrlz5/mxGntJ9Mp3qecjOLKXdR4nx5713J71Naipy9r/CCS0awo1Zgg1aDTZgmzJX3 KlzGhGZEnRAyqPeNlNAdzlCUmJMKFZg/tiSOYEkugs5NGigvKgAAAAAAAAA= --Apple-Mail-36-914333579-- From monnier@iro.umontreal.ca Tue May 26 12:37:22 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 26 May 2009 19:37:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4QJbHsO025469 for <3303@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 12:37:19 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAPfhG0rO+JxR/2dsb2JhbACBT8xshAsFhX2COw X-IronPort-AV: E=Sophos;i="4.41,253,1241409600"; d="scan'208";a="39137944" Received: from 206-248-156-81.dsl.teksavvy.com (HELO pastel.home) ([206.248.156.81]) by ironport2-out.teksavvy.com with ESMTP; 26 May 2009 15:37:12 -0400 Received: by pastel.home (Postfix, from userid 20848) id 150DA84B6; Tue, 26 May 2009 15:37:12 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: 3303@debbugs.gnu.org, Adrian Robert , Chong Yidong , YAMAMOTO Mitsuharu Subject: Re: delete-frame raises old (invisible) frame Message-ID: References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> Date: Tue, 26 May 2009 15:37:12 -0400 In-Reply-To: <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> (David Reitter's message of "Tue, 26 May 2009 14:20:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> PS.: I agree with the proposed change to after-make-frame-functions (not >>> selecting the frame immediately), but this doesn't relate to the bug at >>> hand. Also, I don't know why the modeline isn't updated. >> Agreed, this is a separate problem. > OK, are you keeping track of it, should we file another bug report to do so? Please make another bug report for it. >>> frame.c: >>> Fraise_frame: do not make invisible frames visible (Stefan Monnier). >> This is not OK for 23.1. It might be good to try it for 23.2. >> Also I think your other changes should make it unnecessary for the >> problem we're trying to fix. > As above. I intend to install it myself for Emacs-23.2. No need for a bug report for that, I think. >>> drawRect: do not set visibility/iconified flags because drawRect may be >>> called by NSView even if the frame is hidden. >> Do you happen to know why/when NSView might be called even for a frame >> that's not visible? > Unfortunately not, but invisibility does not guarantee absence of drawRect > messages unless this is promised somewhere in the NS API. > I do think that my patch here is right, though, as other ports set > visibility in more obvious places. Yes, the patch looks OK, but I'd still like to know why drawRect gets called in such cases, as well as why the visibility settings were modified in that routine. > Perhaps we should make sure that we don't get a lot of drawRect calls for > totally obscured frames, which would possibly be a performance-eater. Indeed. Stefan From reitter@cmu.edu Tue May 26 13:15:44 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 26 May 2009 20:15:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.95]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4QKFfHo031228 for <3303@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 13:15:42 -0700 Received: from SCARLETT.PSY.CMU.EDU (SCARLETT.PSY.CMU.EDU [128.2.249.106]) (user=reitter mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.3/8.13.8) with ESMTP id n4QKFZgX029228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 16:15:35 -0400 Cc: 3303@debbugs.gnu.org, Adrian Robert , Chong Yidong , YAMAMOTO Mitsuharu Message-Id: <77EF744F-5194-4E1F-AE4D-DD4D81BB88F8@cmu.edu> From: David Reitter To: Stefan Monnier In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-38-921246210; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: delete-frame raises old (invisible) frame Date: Tue, 26 May 2009 16:15:34 -0400 References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> X-Mailer: Apple Mail (2.935.3) X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.5.26.200206 X-SMTP-Spam-Clean: 10% ( CTYPE_MULTIPART_NO_QUOTE 0.5, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __TO_MALFORMED_2 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.95 --Apple-Mail-38-921246210 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 26, 2009, at 3:37 PM, Stefan Monnier wrote: > >>>> drawRect: do not set visibility/iconified flags because drawRect >>>> may be >>>> called by NSView even if the frame is hidden. >>> Do you happen to know why/when NSView might be called even for a >>> frame >>> that's not visible? >> Unfortunately not, but invisibility does not guarantee absence of >> drawRect >> messages unless this is promised somewhere in the NS API. >> I do think that my patch here is right, though, as other ports set >> visibility in more obvious places. > > Yes, the patch looks OK, but I'd still like to know why drawRect gets > called in such cases, as well as why the visibility settings were > modified in that routine. In this vein, is it possible to get the development history of the NS port merged with the other Emacs history? I mean, everything begins (ends) with the merge, with all code there appearing to have been authored by 'arobert'. In this particular case I would have wanted to know when these lines of code were added (e.g., pre-22?), and what the comments were. I could probably try to find this in Emacs.app, but I'm wondering if we can have this history (perhaps in a separate branch) in the Bzr/Git repositories. --Apple-Mail-38-921246210 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGODCCAvEw ggJaoAMCAQICEEUTODS9VcXIOFaPH+ApeTwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyNzAwMzgxNloXDTA5MDgyNzAwMzgx NlowWjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxHjAcBgkqhkiG9w0BCQEWD3JlaXR0ZXJAY211LmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJW3Pr3O1TOI9MTahUDKcJkkoZQOmnQVYtchDAALotmkjxNO/wC2b+CiDGGg +8TbJ/EwdMD2IOh1TilL/SXKk2txTgduV5yBrYXk04z1cGxNcCCTRiSZY1A5I3rvnP2jhUf8I49O WXFs8v8XvcJ0o1wFoPITU7b9KBLg22kl+DqNuj10fCLQldlNfe4o5PX/TWFE/NqI+//Ooehr+5hY B1XtAXQXU3/DC6M8l6Sqsm0vw5OO44K7KceG85zQchZ60LOJnGWA2UKcfNTIZGr18LUJMdl6kiU2 TEwy1H/3JAOMmekIbiQ7AWDiVYlkY6QUXBmgAPizQ81yOL3u/sUolt0CAwEAAaMsMCowGgYDVR0R BBMwEYEPcmVpdHRlckBjbXUuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAuxCV 2UwfCwGkNBLsntGFfOObkWhvGLwol+lIdGLGBUll1A1QXdL279qMr2Nk1yR8tVgxx36z3p29itxu jRI7e5WA/devk3WIZwjK4MrWmC/TS5FAbR5PD/Q8iUXaiqQJR39kOdokEVAS3R8wYnHDSV/eQkUx OhDWpDhMbdCgtk4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HO AdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIAC ZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB /wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVBy aXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FD lpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2p nDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEUTODS9VcXI OFaPH+ApeTwwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDkwNTI2MjAxNTM1WjAjBgkqhkiG9w0BCQQxFgQUQRdd984BS20gbBWFrKVr0u8u x1QwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MA0GCSqGSIb3 DQEBAQUABIIBAFUb6g2mdsAr6VNArxztnlVGXiT1qdwJ1QZW1e8XChIoDnm6qYhp9gbs7T1MeNw5 0vhmdujrPEztoTKcJV3npObXpP7pn7GpOcnNoPWB3x5hXzqYA03UPKyx/I3kbzvuuFEa7OvUfgeh REjr9061Jmo7nKU5mHWO9Yr86P6OfU+pwq7eDxYoKg2PT9q7OYTTVdVXVhsZ1iJFQ4fDqXXgYvnF 17U3E6S8bYZ3kREj8Sn6y1vz/faNxcsXhL5+jYL4RJY4+3WkhWvrq2WsaQ9eIunCpMYwQJeJCZ5a w19kJ+O+ed37N+4PoCuPLQbBFSwBi3rQ773yNv4NsuQgRkrkt3UAAAAAAAA= --Apple-Mail-38-921246210-- From monnier@iro.umontreal.ca Tue May 26 14:30:56 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 26 May 2009 21:30:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4QLUpPU009559 for <3303@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 14:30:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAOv8G0rO+JxR/2dsb2JhbACBT81ihAsFhX2COw X-IronPort-AV: E=Sophos;i="4.41,254,1241409600"; d="scan'208";a="39145372" Received: from 206-248-156-81.dsl.teksavvy.com (HELO pastel.home) ([206.248.156.81]) by ironport2-out.teksavvy.com with ESMTP; 26 May 2009 17:30:46 -0400 Received: by pastel.home (Postfix, from userid 20848) id 090BE84B6; Tue, 26 May 2009 17:30:45 -0400 (EDT) From: Stefan Monnier To: David Reitter Cc: 3303@debbugs.gnu.org, Adrian Robert , Chong Yidong , YAMAMOTO Mitsuharu Subject: Re: delete-frame raises old (invisible) frame Message-ID: References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> <77EF744F-5194-4E1F-AE4D-DD4D81BB88F8@cmu.edu> Date: Tue, 26 May 2009 17:30:45 -0400 In-Reply-To: <77EF744F-5194-4E1F-AE4D-DD4D81BB88F8@cmu.edu> (David Reitter's message of "Tue, 26 May 2009 16:15:34 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > I could probably try to find this in Emacs.app, but I'm wondering if > we can have this history (perhaps in a separate branch) in the > Bzr/Git repositories. It would be good, but I don't think much of this history even exists. Stefan From adrian.b.robert@gmail.com Tue May 26 21:51:52 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 27 May 2009 04:51:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4R4pl0Y007291 for <3303@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 21:51:48 -0700 Received: by ewy26 with SMTP id 26so4766163ewy.1 for <3303@emacsbugs.donarmstrong.com>; Tue, 26 May 2009 21:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:from:subject:date:to :x-mailer; bh=ZWvlXDyWlJcHUrGGL89iu87AnlkGoCnQVJ7+3MrnuSA=; b=sMh03aaXoEUeLPn7CVpIhTUIQ1f7T577036gr1oOJ3TNEFPTE8fbMl8dWrGKRP58Cj O4RWr71yssdNQ85bUwFCY7ickluT6s3iwcnO9M4y9QB39N0bk2URxQCHLPytVTnXXmVO 5BiUllWg8xCvwyZVrJCkyGSbFlJHP361EoRhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc:from :subject:date:to:x-mailer; b=I45ckHbt7cRTxTb0MFN0/10zeS9cGGMB7IVM4P/d2p24YIlGEqDQ98M/R7UDW+NfgE jLqh18lvAnuuvBPAaD9csRlmv48B3jAkK1A3QWjXv8m3NjYsvyaUT3hDSp0ugIv8GYGD COq5JfmF3Lqn3S3vYCTTqKK65KHzFuz1xfERI= Received: by 10.216.72.207 with SMTP id t57mr3426246wed.158.1243399901026; Tue, 26 May 2009 21:51:41 -0700 (PDT) Received: from ?10.175.67.124? ([202.149.25.194]) by mx.google.com with ESMTPS id g9sm1728330gvc.25.2009.05.26.21.51.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 May 2009 21:51:39 -0700 (PDT) In-Reply-To: <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/mixed; boundary=Apple-Mail-5-952220205 Message-Id: <2C80B262-1E12-4786-90C9-B7F44494AD9E@gmail.com> Cc: Stefan Monnier , 3303@debbugs.gnu.org From: Adrian Robert Subject: Re: delete-frame raises old (invisible) frame Date: Wed, 27 May 2009 11:51:48 +0700 To: David Reitter X-Mailer: Apple Mail (2.753.1) --Apple-Mail-5-952220205 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed >>> keyDown: do not swallow events that aren't re-sent if frame isn't >>> key window. >> >> If you say so. > > What does Adrian say?? I'm just fixing the workaround, even though > I don't fully understand the bug that leads to the problem. The symptom I observed that led me to add that section of code was that, when two frames are open, both displaying different buffers, and you hold the cursor-down or page-down key down in one, the focus would shift back and forth between the windows, and the cursor would do some movement in each. It's possible this no longer occurs due to other changes in focus handling both on NS and core sides, but it's worth testing. Regarding the history question, there was no use of CVS during my maintainership (or before, I believe), but there was a ChangeLog. It got removed in the merge, but I'm attaching it here. In addition, when bzr was being used for a couple of months just prior to the merge, the person that did the import put in history entries for each release, about a dozen all together. I'm not sure if they were full changelog segments or just the release notes, but anyway I believe this is gone now too, as the eventual CVS add to trunk was done separately from the bzr tree. --Apple-Mail-5-952220205 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name=ChangeLog Content-Disposition: attachment; filename=ChangeLog 2008-03-20 Adrian Robert * nsterm.m (show_hourglass, hide_hourglass): New functions, no impl yet. * nsmenu.m (EmacsDialog): Update appearance to be more like standard NS alert panel. (Fns_yes_or_no_p): Remove. * ns-win.el (ns-yes-or-no-p): Add implementation that calls yes-or-no-p. 2008-03-17 Adrian Robert * nsterm.m (ns_read_socket): Increment/decrement handling_signal when experimental_ctrl_g set, due to advice on emacs-devel, although it really seems this should be done in keyboard.c (input_available_signal et al.) since we have no idea of whether we are being called from a signal handler or not. Also, ignore the 'expected' argument, which seems a crock but fixes the input handling in mixed terminal/GUI sessions. * keymap.c (where-is-internal): Generalize the handling of 'super' preference to any modifier. * lisp/ns-grabenv.el: Reworked based on David Reitter's version in Aquamacs distribution. Behaves better w/non-csh shells. 2008-03-01 Adrian Robert * (various): Update for merge to trunk, and Stefan Monnier comments. 2007-12-14 Adrian Robert * nsfns.m (ns_set_background_color): Clear frame first (in attempt to fix occasional improper text erasing problem). * ns-win.el (ns-print-buffer): Reimplement print-buffer confirmation to not use advice. 2007-11-25 Adrian Robert * ns-win.el: Remove mic-paren, yank-menu-length redefinition, redo print-buffer override to not need advice. 2007-11-23 Adrian Robert * Version 9.0-rc3 released. 2007-11-22 Adrian Robert * configure.in, Makefile.in, src/Makefile.in, src/config.in, nextstep/compile: Change logic for GNUstep platforms to handle FHS installations in addition to regular. 2007-11-19 Adrian Robert * ns-win.el (ns-define-service): Take arg or marked text, and return string if arg given. * nsfns.m, nsselect.m: Use of Fsignal: send Qquit instead of Qerror, since these are more wrong-args type of messages, not serious errors requiring the debugger. 2007-11-16 Adrian Robert * ns-win.el: Adapt to recent change in buffer menu variable. * facemenu.el (facemenu-read-color): Don't require match to color list, so ARGB colors can be read. 2007-11-15 Adrian Robert * nsterm.m (x_set_window_size): Correct behavior on certain toolbar-added resizes by constraining to screen ourselves -- leaving it to Cocoa generated inconsistent results. 2007-11-11 Adrian Robert * lisp/international/fontset.el (script-representative-chars): Added chars for 'symbol' script. 2007-11-08 Adrian Robert * (various): Improved multi-TTY integration. * nsterm.m (x_set_window_size): Don't return if font width/height has changed. 2007-11-01 Adrian Robert * (various): Updated for multi-TTY integration. 2007-10-14 Adrian Robert * nsmenu.m (ns_popup_menu): Set frame in call to mouse_position_hook. * nsterm.m (ns_mouse_position): Check for null frame. 2007-10-14 Adrian Robert * nsmenu.m (EmacsToolbar-changed): Report changed on enablement state change. 2007-10-13 Adrian Robert * image.c (xpm_load_image): Work around an apparent bug in NSImage alpha management (avoids blocky appearance of startup image on black bg). * nsimage.m (-setXBMColor:): Only set color for non-alpha-masked pixels. Shouldn't have to do this, but... (Fixes "fat" rendering w/colored or dark fringe backgrounds). * nsterm.m (ns_dumpglyphs_image): Fix minor glitch w/background drawing. (-setMiniwindowImage:): Add argument to set to optionally set nil (for miniaturized version of window). * nsfns.m (ns_implicitly_set_icon_type): Use it. 2007-10-12 Adrian Robert * lisp/ns-menu-bar.el: Cut down to minimal code, eliminating most remaining redundancy with menu-bar.el, and move the remnant to ns-win.el. 2007-10-10 Adrian Robert * Patch 20071010_rc2a released. 2007-10-10 Peter Dyballa * nextstep/compile: Add --local-lisp-path= option to prepend a path to epaths.h to search for lisp before other directories. 2007-10-10 Seiji Zenitani * nsterm.m (ns_init_paths): Switch order from lisp, leim, site-lisp to site-lisp, lisp, leim. * ns-win.el (ns-utf8-nfd-post-read-conversion etc.): Define coding system utf-nfd to handle decomposed (normal form D) UTF-8 in MacOSX filenames. Based on initial contribution by Carsten Bormann. (This change went into rc2 but was not noted in the ChanngeLog there.) 2007-09-26 Adrian Robert * nsterm.m (ns_pending_files, -openFile:, ns_read_socket): Handle openFile requests by storing to a queue and acting on later when events can be processed. 2007-09-25 Adrian Robert * nsterm.m (ns_draw_window_cursor, EmacsView-windowDidResignKey): Be more clever about drawing background (to avoid flicker with blinking cursor). Also, rename cursor type line -> bar, bar -> underscore. * frame.c (do_switch_frame): Explicitly call Fraise_frame() on for_deletion case (to fully focus the frame). * nsterm.m (x_make_frame_visible): Make into a no-op (unneeded). 2007-09-21 Adrian Robert * nsterm.m (ns_draw_fringe_bitmap): Expand bitmap image cache as needed. * image.c: Be more careful about retain/release on image backgrounds. 2007-09-20 Adrian Robert * Version 9.0-rc2a released. 2007-09-18 Adrian Robert * nsimage.m (initFromSkipXBM, setXBMColor): Support colored bitmap rendering. * ns-win.el (print-buffer advice): Advice function to request confirm before print-buffer. Due to Kevin Rodgers. 2007-09-17 Adrian Robert * nsterm.m (EmacsWindow): New class to handle resize drags, which are directly handed to it by EmacsApp-sendEvent:. Allows continuous display update. Only enabled under Cocoa as resize handles vary under GNUstep. 2007-09-16 Adrian Robert * nsmenu.m (ns_popup_menu): Fix bug in location computation with horizontally-split windows. * nsmenu_common.c (find_and_return_menu_selection): Fix initialization bug that could cause crash on menu selection. * nsterm.m (cursor_blink_rate, cursor_blink_mode): Added cursor_blink_mode variable and set in ns-win.el:blink-cursor-mode. 2007-09-15 Adrian Robert * nsfont.m (nsfont_open): Improve font width calculation. * nsterm.m (ns_clear_frame_area): Check for non-null default face. 2007-09-14 Adrian Robert * nsterm.m (EmacsView -drawRect:): Incorporate an expose-frame call following suggestion of YAMAMOTO Mitsuharu. * lisp/faces.el (frame-set-background-mode): Undo a change by Daiki Ueno that made every face seem "locally-modified" such that it will not be updated for background color. 2007-09-13 Adrian Robert * nsterm.m (ns_draw_relief): Determine relief colors dynamically. 2007-09-12 Adrian Robert * nsfns.m (ns_set_background_color): Fixed crash bug when frame's default face not set yet. * nsmenu.m (EmacsMenu): Set action nil on items w/submenu. * nsfont.m (draw): Take account of s->gidx when determining chars to render. 2007-09-11 Adrian Robert * Version 9.0-rc2 released. 2007-09-09 Adrian Robert * nsterm.m (EmacsView-mouseDown:): Ignore scrollwheel events with delta == 0. Also, send scrollwheel events from scrollbars here. 2007-09-08 Adrian Robert * lisp/ns-mark-nav.el: Replaced with simplified implementation that also includes global functionality, due to Andrew L. Moore. 2007-09-07 Adrian Robert * nextstep/compile: Add support for installing lisp in shared location such as /usr/local/share/emacs/23.0.0 (--enable-shared 'prefix' option). 2007-09-06 Adrian Robert * nsfont.m (ns_uni_to_glyphs, ns_glyph_metrics): Implemented on-demand loading of metrics cached by 256-glyph blocks for each font. * (various): Fixed a few memory leaks. 2007-09-03 Adrian Robert * nsmenu.m, nsmenu_common.c: New menu implementation, following mac and X terms more closely. * ns-menu-bar.el: Use the common update buffers function. 2007-08-29 Adrian Robert * nsterm.m (EmacsScroller): Change scrolling to set bar position driven by emacs only and never internally -- prevents adjustment cycles causing jumpiness. * ns-win.el (ns-scroll-bar-move, ns-handle-scroll-bar-event): Work with the above change, and also use pager commands for slot clicks. Pager commands now use vertical-motion instead of forward-lines in order to avoid problems scrolling buffers with long lines. 2007-08-27 Adrian Robert * ns-win.el (ns-in-echo-area, ns-insert-working-text), (ns-delete-working-text, ns-echo-working-text, ns-unecho-working-text): Added/modified so composed editing works in weird cases when in minibuffer but not really in minibuffer (e.g., isearch). Also pick up deleteBackward: request when aborting a compose. * nsterm.m (EmacsView -keyDown et al.): If command is 'super', use system-given key to follow, e.g., dvorak/qwerty-shortcuts map correctly. Also, use charactersIgnoringModifers as criterion for determining whether we have a modifier sequence (instead of a composition). * cus-start.el: Add 'ns to the long list of window systems ignoring gtk variables. 2007-08-26 Adrian Robert * nsterm.m (ns_draw_glyph_string, ns_draw_box_or_relief) (ns_dumpglyphs): Improve box border and background coordinate computations, drop non-font-backend code. * nsterm.m (ns_compute_glyph_string_overhangs): Implemented for real. * nsfont.m (open, text_extents, draw): Compute proper bearings in open(), use them in text_extents. In draw(), now handle introductory matters previously done in ns_dumpglyphs(), which is no longer used. * font.c (font_load_for_face), nsfont.m (draw): Support overstrike for families with no bold member. 2007-08-25 Adrian Robert * image.c (xpm_load_image): Use lisp strings instead of ints for passing NSColor pointers. (Patch by David M. Cooke.) * nsimage.m: Clean up getPixel/setPixel methods, cache a reference to an NSBitmapImageRep as well as pixmap data, minor fixes to allocInitFromFile, and explicitly cache NSColor colorWithPatternImage used for stipple rendering rather than image rep. 2006-12-29 Adrian Robert * nsfont.m, nsterm.m: Use '_' to substitute for spaces in font names. * nsfns.m (ns-font-name): New function to extract font name from XLFD for pref-saving purposes. * ns-win.el (ns-save-preferences): Use it. Also, save ns-control-modifier, ns-function-modifier. 2006-12-24 Adrian Robert * Version NS 9.0-rc1 released: major feature enhancements and bug fixes. 2006-12-22 Adrian Robert * src/nsterm.m, nsfont.m: Improvements/fixes to clip rect calculation and certain drawing cases: fringe now goes to top, and top-row, full-width blocks look better. Also, (EV_BUTTON), make right mouse button be mouse-3 to emulate other emacsen. Finally, recognize dead-key modifiers accessible only when SHIFT is pressed (-keyDown). * nextstep/compile: Link MacOS/libexec items into MacOS/bin as some lisp packages seem to look for them there. 2006-12-21 Adrian Robert * lisp/ns-menu-bar.el: Updated menus to Emacs 21+ conventions. 2006-11-27 Adrian Robert * src/nsfns.m (x-create-frame): Correctly heed frame geometry specifications. * src/nsterm.m, nextstep/Cocoa/preferences.nib: Added ns-option-modifier (alias for ns-alternate-modifier), ns-control-modifier, ns-function-modifier settings. * src/ns-win.el (before-make-frame-hook): Behave correctly with strange negative-number symbol lists. 2006-11-20 Adrian Robert * src/nsfont.m: New file, implementing driver for Kenichi Handa's new font back-end. Font handling code is now simplified, consolidated, and more reliable. Fontsets now implemented and auto-created if a font is set for a frame instead of a fontset. * lisp/term/ns-win.el: Supporting changes for above. 2006-09-22 Adrian Robert * lib-src/Makefile.in: Use autoconf-determined $INSTALL_SCRIPT instead of $INSTALL_PROGRAM to install scripts (HAVE_NS only). 2006-09-19 Adrian Robert * src/emacs.c: #include GSConfig.h on GNUstep to pick up fake main definition to gnustep_base_user_main. * src/config.in: Add -I($GNUSTEP_SYSROOT) to C_SWITCH_X_SYSTEM so that this works. * src/alloc.c: Don't call 'asm("ta 3")' on Sparc / GNUstep systems, although maybe this should be Sparc / FreeBSD only. * configure.in: Add sparc-*-freebsd* to machine recognition -- though not sure why the OS is used in the pattern for machines. 2006-09-07 Adrian Robert * src/nsfns.m (ns-yes-or-no-p): Fixed function prototype. 2006-08-27 Adrian Robert * lisp/composite.el, loaddefs.el: Do not rely on emacs-basic-display being set when initializing global-auto-compose-mode, as it will not be when running in CANNOT_DUMP situation. * nextstep/compile: Check for 'info' under 'share' (put there in some gnustep builds). * nextstep/GNUstep/Images/emacs-orange-64.tiff: Make smaller. * nextstep/GNUstep/preferences.gorm: Updated for variable name change. * nsterm.m (EmacsPrefsController -setValuesFromPanel): Fixed bug in setting ExpandSpace. 2006-08-01 Adrian Robert * nsterm.m (ns_xlfd_to_fontname): Be more robust against malformed XLFD input. (ns_get_color): Return calibrated RGB versions of named colors. (syms_of_nsterm): Update documentation for modifier key variables. * etc/Emacs.clr: Add new colors from recent X11 rgb.txt files. (Courtesy of Peter Dyballa .) 2006-06-09 Adrian Robert * fontset.c (load_font_get_repertory): Avert a crash by checking whether get_font_repertory_func is defined. * nsterm.m (ns_draw_window_cursor): Adjust to changes in core. (ns_find_ccl_program): New function copied verbatim from xterm.c. (-keyDown) Accept alt(=Qnone)-fnKey as fnKey, not mapped characters. 2006-06-08 Adrian Robert * Version NS 9.0-pre3 released: major feature enhancements and bug fixes. 2006-06-07 Adrian Robert * nsselect.m (ns_string_from_pasteboard): Convert line endings (EOL) on incoming text. 2006-06-06 Adrian Robert * nsterm.m (-performDragOperation:): Correct coordinate calculation. * ns-win.el (ns-face-at-pos): Correct coordinate calculation. (all): Cleaned up / organized file. 2006-06-05 Adrian Robert * ns-win.el (ns-working-text-face, ns-working-overlay, ns-working-overlay-len): New variables supporting keyboard composition. (ns-insert-working-text, ns-delete-working-text): New functions supporting keyboard composition. * nsterm.m (-keyDown: -insertText:, -deleteWorkingText, -setMarkedText:selectedRange): New/updated methods supporting keyboard composition. (ns_working_text): New variable supporting keyboard composition. 2006-06-03 Adrian Robert * ns-win.el (ns-set-background-alpha) * nsfns.m (Fns_set_alpha): Add user function ns-set-background-alpha for setting window transparency, backed by ns-set-alpha. 2006-06-02 Adrian Robert * nsterm.m (ns_dumpglyphs): Further hackery to work around box borders. (-windowShouldZoom): New delegate method implementation needed on OS X to move window to origin on zoom. (ns_set_vertical_scroll_bar): Realize that window->total_lines is a lisp integer. 2006-06-01 Adrian Robert * nsterm.m ([EmacsView -keyDown]): Differentiate Backspace, Delete, and KP-Delete; also, report Ctrl-(code < 0x20) keys by code conversion, rather than solely by modifier flags. 2006-05-30 Adrian Robert * nsterm.m (ns_term_init): Set a Windows menu in NSApp so dock menu shows window list. 2006-05-29 Adrian Robert * nsterm.m (ns_draw_window_cursor): Check in right place for need to draw in fringe. (ns_load_font): Set rbearings a bit better so italic overhangs rendered more or less correctly. 2006-05-28 Adrian Robert * nsfns.m, nsterm.m, nsmenu.m: Finished toolbar support. * nsfns.m, nsterm.h, nsmenu.m: Tooltip support. * fontset.c (face_for_char): Shortcircuit a codepath, uneeded under NS, that was causing crashes when displaying non-ASCII characters. * nsterm.m (ns_define_frame_cursor): Act so cursor correctly updates when leaving window. 2006-04-22 Adrian Robert * Version NS 9.0-pre2a released: Stopgap release to sync w/latest unicode-2 CVS. XPM + partial toolbar support included. 2006-04-22 Adrian Robert * nsfns.m, nsterm.m, nsmenu.m: Toolbar support (incomplete). 2006-03-22 Adrian Robert * nsimage.m, image.c: XPM support. 2005-12-15 Adrian Robert * lread.c (init_lread): Stamp out path warning under NS. 2005-12-13 Adrian Robert * nsterm.m (ns_init_paths): Fixed bug where .app-internal lisp load path was being set even when it did not exist. 2005-11-11 Adrian Robert * nsterm.h: Set selection color when system default not used to emacs default LightGoldenRod2. (Can be changed by customizing 'region' face.) * man/ns-emacs.texi: Added a node describing Preferences Panel usage written by Adam Ratcliffe . * nsterm.m ([EmacsPrefsController -runHelp]): Go to this prefs node specifically; also, update display. 2005-11-11 Adrian Robert * Version NS 9.0-pre2 released: bugfixes and minor feature enhancements. * nextstep/compile, **/*.in: Revamped build process to place greater load on configure, less on C/CPPFLAGS env variables. For GNUstep, only the GNUSTEP_SYSTEM_ROOT variable must be set, and the compile script attempts to get this from /etc/GNUstep/GNUstep.conf. 2005-11-10 Adrian Robert * frame.c (syms_of_frame): Default scrollbar to right side under Cocoa. 2005-11-09 Adrian Robert * nsterm.m: Support flexible remapping of Alt/Opt and Command keys. 2005-11-08 Adrian Robert * nsterm.m (ns_load_font): Improvement to 11/07 change: new height metrics calculation. Changed "ShrinkSpace" default to "ExpandSpace" to reflect its role. Updated prefs panel. * nexstep/compile: Added detection of failure and made configure invocation more robust. Based on suggestion by Peter Dyballa. 2005-11-07 Adrian Robert * nsimage.m ([EmacsImage prepareForStippling]): Only cache if both height and width less than max. * nsterm.m (ns_load_font()): Set font height in XFontStruct (which is used for frame line height) to be same as was being set in max_bounds. This makes (window-text-height) correct, as well as estimates made in nsterm.m during resizes. 2005-11-06 Adrian Robert * nsterm.m ([EmacsView windowDidDeminiaturize]): Check emacs_event, since can be invoked asynchronously. --Apple-Mail-5-952220205 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-5-952220205-- From monnier@iro.umontreal.ca Wed May 27 07:36:43 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 27 May 2009 14:36:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4REae81025744 for <3303@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 07:36:41 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4FACftHErO+JxR/2dsb2JhbACBT81PhAwFhgA X-IronPort-AV: E=Sophos;i="4.41,260,1241409600"; d="scan'208";a="39170023" Received: from 206-248-156-81.dsl.teksavvy.com (HELO ceviche.home) ([206.248.156.81]) by ironport2-out.teksavvy.com with ESMTP; 27 May 2009 10:36:34 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 8380FB40E5; Wed, 27 May 2009 10:36:34 -0400 (EDT) From: Stefan Monnier To: Adrian Robert Cc: David Reitter , 3303@debbugs.gnu.org Subject: Re: delete-frame raises old (invisible) frame Message-ID: References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> <2C80B262-1E12-4786-90C9-B7F44494AD9E@gmail.com> Date: Wed, 27 May 2009 10:36:34 -0400 In-Reply-To: <2C80B262-1E12-4786-90C9-B7F44494AD9E@gmail.com> (Adrian Robert's message of "Wed, 27 May 2009 11:51:48 +0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > The symptom I observed that led me to add that section of code was that, > when two frames are open, both displaying different buffers, and you hold > the cursor-down or page-down key down in one, the focus would shift back > and forth between the windows, and the cursor would do some movement in > each. It's possible this no longer occurs due to other changes in focus > handling both on NS and core sides, but it's worth testing. Then it's good to remove the workaround, even if the symptom re-appears: it should be fixed elsewhere. Stefan From reitter@cmu.edu Wed May 27 08:28:11 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 27 May 2009 15:28:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4RFS7Zd030417 for <3303@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 08:28:08 -0700 Received: from SCARLETT.PSY.CMU.EDU (SCARLETT.PSY.CMU.EDU [128.2.249.106]) (user=reitter mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.3/8.13.8) with ESMTP id n4RFS10g026087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 May 2009 11:28:01 -0400 Cc: Stefan Monnier , 3303@debbugs.gnu.org Message-Id: <636427BA-CF6A-4142-9B88-C6C604CC5983@cmu.edu> From: David Reitter To: Adrian Robert In-Reply-To: <2C80B262-1E12-4786-90C9-B7F44494AD9E@gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-76-990392529; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: delete-frame raises old (invisible) frame Date: Wed, 27 May 2009 11:28:01 -0400 References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> <2C80B262-1E12-4786-90C9-B7F44494AD9E@gmail.com> X-Mailer: Apple Mail (2.935.3) X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.5.27.151331 X-SMTP-Spam-Clean: 10% ( CTYPE_MULTIPART_NO_QUOTE 0.5, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __TO_MALFORMED_2 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 --Apple-Mail-76-990392529 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 27, 2009, at 12:51 AM, Adrian Robert wrote: > The symptom I observed that led me to add that section of code was > that, when two frames are open, both displaying different buffers, > and you hold the cursor-down or page-down key down in one, the focus > would shift back and forth between the windows, and the cursor would > do some movement in each. It's possible this no longer occurs due > to other changes in focus handling both on NS and core sides, but > it's worth testing. OK. This has not cropped up after my changes, so that's good. We should test if the workaround as a whole is still needed (but many of the bugs on the long list for package NS are more important now). > Regarding the history question, there was no use of CVS during my > maintainership (or before, I believe), but there was a ChangeLog. > It got removed in the merge, but I'm attaching it here. Thanks for sending this. --Apple-Mail-76-990392529 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGODCCAvEw ggJaoAMCAQICEEUTODS9VcXIOFaPH+ApeTwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyNzAwMzgxNloXDTA5MDgyNzAwMzgx NlowWjEQMA4GA1UEBBMHUmVpdHRlcjEOMAwGA1UEKhMFRGF2aWQxFjAUBgNVBAMTDURhdmlkIFJl aXR0ZXIxHjAcBgkqhkiG9w0BCQEWD3JlaXR0ZXJAY211LmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJW3Pr3O1TOI9MTahUDKcJkkoZQOmnQVYtchDAALotmkjxNO/wC2b+CiDGGg +8TbJ/EwdMD2IOh1TilL/SXKk2txTgduV5yBrYXk04z1cGxNcCCTRiSZY1A5I3rvnP2jhUf8I49O WXFs8v8XvcJ0o1wFoPITU7b9KBLg22kl+DqNuj10fCLQldlNfe4o5PX/TWFE/NqI+//Ooehr+5hY B1XtAXQXU3/DC6M8l6Sqsm0vw5OO44K7KceG85zQchZ60LOJnGWA2UKcfNTIZGr18LUJMdl6kiU2 TEwy1H/3JAOMmekIbiQ7AWDiVYlkY6QUXBmgAPizQ81yOL3u/sUolt0CAwEAAaMsMCowGgYDVR0R BBMwEYEPcmVpdHRlckBjbXUuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAuxCV 2UwfCwGkNBLsntGFfOObkWhvGLwol+lIdGLGBUll1A1QXdL279qMr2Nk1yR8tVgxx36z3p29itxu jRI7e5WA/devk3WIZwjK4MrWmC/TS5FAbR5PD/Q8iUXaiqQJR39kOdokEVAS3R8wYnHDSV/eQkUx OhDWpDhMbdCgtk4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HO AdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIAC ZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB /wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVBy aXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FD lpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2p nDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEUTODS9VcXI OFaPH+ApeTwwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDkwNTI3MTUyODAxWjAjBgkqhkiG9w0BCQQxFgQUfzf0WGwpT+SMmBcUB+2oa719 1ugwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBFEzg0vVXFyDhWjx/gKXk8MA0GCSqGSIb3 DQEBAQUABIIBACyKM2RKStTvq1xv3xjTQLuBsgQn81Wp/DG/82W/GwS9oXZPwoR4pwwxmA8GvWv9 g8qH5rWTfcr8lkLPG6/+f8dtqRQVuVaGHrJ/RWwmANwe6131VA31jXKy/MN6nDbTiSQjusCAKTse 8aVyjyX25SieUA46I4ho0apyKmWdy+f79O1PTa6M1yYAjaS+r+ixuo9p8HoZVMav8e4fSpiQ64kG LVfsAGqmgbMijcTBktuRIvt/I6YMy7KgtZtu/kCt/9fM62+HdyZBegUdRIkZgQLJZzJLlrVHlr2C mxd4wDD0IRoODtVnBsxFThFfmLTzD36/KaoaejWzUBwiwoik7wsAAAAAAAA= --Apple-Mail-76-990392529-- From adrian.b.robert@gmail.com Mon Jun 1 02:37:36 2009 Received: (at 3303) by emacsbugs.donarmstrong.com; 1 Jun 2009 09:37:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-px0-f108.google.com (mail-px0-f108.google.com [209.85.216.108]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n519bWkS001298 for <3303@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 02:37:33 -0700 Received: by pxi6 with SMTP id 6so5424780pxi.19 for <3303@emacsbugs.donarmstrong.com>; Mon, 01 Jun 2009 02:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=GKleExed21ZlqcbD7FsWWNsiBOAD1Y62vhJuf8FKHG8=; b=FmTpD4mmMNtB3cW33VZoMAADgJIyrfpn99NrwgUrRQFJbOp6iisz5MaAmAdMhohsLy csmrnpN0mL8bEemDP/V+pPQGnaU6PSgFclt4OUDwnl9O7PswdW7s+iXjriOi5MKAE8le 12pSowqHUFelwrZxk8OQ3oYx1/x3zxPQy/SCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=I0DL8W7PxEHJPeS+3d749MQH6NIXmJu7u6TMeEF1hJqOte02G7/YZ4Svp4UgbZGwsD U8Nnanq73jtBrq9Qsa9RcCwpMb6HKBuoEQVpEi1W13czSkogygoVLoAu1ziKladyjCVR eDW+PWuFfgJnhGSQgyp6L1e3zeFi57oBeq8Oc= Received: by 10.142.225.20 with SMTP id x20mr1830535wfg.292.1243849046638; Mon, 01 Jun 2009 02:37:26 -0700 (PDT) Received: from ?119.31.26.53? ([119.31.26.53]) by mx.google.com with ESMTPS id v9sm5395977wah.1.2009.06.01.02.37.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 02:37:25 -0700 (PDT) In-Reply-To: References: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> <10D37A53-45B3-46C2-8F2B-C38534094A93@cmu.edu> <2C80B262-1E12-4786-90C9-B7F44494AD9E@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David Reitter , 3303@debbugs.gnu.org Content-Transfer-Encoding: 7bit From: Adrian Robert Subject: Re: delete-frame raises old (invisible) frame Date: Mon, 1 Jun 2009 16:37:51 +0700 To: Stefan Monnier X-Mailer: Apple Mail (2.753.1) On May 27, 2009, at 9:36 PM, Stefan Monnier wrote: >> The symptom I observed that led me to add that section of code was >> that, >> when two frames are open, both displaying different buffers, and >> you hold >> the cursor-down or page-down key down in one, the focus would >> shift back >> and forth between the windows, and the cursor would do some >> movement in >> each. It's possible this no longer occurs due to other changes >> in focus >> handling both on NS and core sides, but it's worth testing. > > Then it's good to remove the workaround, even if the symptom re- > appears: > it should be fixed elsewhere. I put a FIXME comment in xdisp.c redisplay_internal() (line 11551) at the same time I made my workaround. I thought the problem originated there, but wasn't certain enough to pursue it further. (consider_all_windows set true causes each FRAME to be temporarily selected in turn later in this function.) Since the problem seems to be gone, I'll take a look through the history once savannah is back to see what might have changed. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 15:11:29 2011 Received: (at control) by debbugs.gnu.org; 5 Oct 2011 19:11:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBWsL-00051i-An for submit@debbugs.gnu.org; Wed, 05 Oct 2011 15:11:29 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBWsJ-00051b-TF for control@debbugs.gnu.org; Wed, 05 Oct 2011 15:11:28 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RBWsF-0007Qy-CH for control@debbugs.gnu.org; Wed, 05 Oct 2011 15:11:23 -0400 Date: Wed, 05 Oct 2011 15:11:23 -0400 Message-Id: Subject: control message for bug 3303 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 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.4 (------) unarchive 3204 forcemerge 3204 3303 From unknown Fri Aug 15 04:03:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 03 Nov 2011 11:24:02 +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