From unknown Sat Aug 09 15:51:54 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#1348 <1348@debbugs.gnu.org> To: bug#1348 <1348@debbugs.gnu.org> Subject: Status: set-frame-width and set-frame-position seem buggy on at least MSWindows Reply-To: bug#1348 <1348@debbugs.gnu.org> Date: Sat, 09 Aug 2025 22:51:54 +0000 retitle 1348 set-frame-width and set-frame-position seem buggy on at least = MSWindows reassign 1348 emacs submitter 1348 "Themba Fletcher" severity 1348 normal thanks From themba@shirleymachine.com Fri Nov 14 14:46:45 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.9 required=4.0 tests=BAYES_00,FOURLA, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Nov 2008 22:46:45 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAEMkgb1005178 for ; Fri, 14 Nov 2008 14:46:43 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L17R3-0004cs-Uj for bug-gnu-emacs@gnu.org; Fri, 14 Nov 2008 17:46:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L17R3-0004bg-5H for bug-gnu-emacs@gnu.org; Fri, 14 Nov 2008 17:46:41 -0500 Received: from [199.232.76.173] (port=49933 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L17R3-0004bM-0h for bug-gnu-emacs@gnu.org; Fri, 14 Nov 2008 17:46:41 -0500 Received: from smtp100.biz.mail.re2.yahoo.com ([206.190.52.46]:26146) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L17R2-00036Y-ET for bug-gnu-emacs@gnu.org; Fri, 14 Nov 2008 17:46:40 -0500 Received: (qmail 29295 invoked from network); 14 Nov 2008 22:46:36 -0000 Received: from unknown (HELO cadstation01) (themba@76.252.62.121 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 14 Nov 2008 22:46:36 -0000 X-YMail-OSG: JyrFhXEVM1lvNS6IbftNaCHlhL8GnOV33Y9WHq7caz.sHIRJYVhLjf8MuVWLs0Fa3d8mGr1ml50KmGlvygIrALfYxQTY9Lf9Fy2BmHl_k67ehGL8tCFAEtu5BhAKz8geQR1D14bCBY5dARNI.Iyk3Mz. X-Yahoo-Newman-Property: ymail-3 From: "Themba Fletcher" To: Subject: set-frame-width and set-frame-position seem buggy on at least MSWindows Date: Fri, 14 Nov 2008 17:46:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AclGqqqe2rB3F/FoSdii7Kcsp7b/Cg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) Message-Id: When migrating to Emacs 22.3.1 on microsoft windows, the following lines in my .emacs file do not behave as expected: (set-frame-position (selected-frame) 0 0) (sleep-for 2) ; not originally in my .emacs -- testing only (set-frame-width (selected-frame) 150) (sleep-for 2) (set-frame-height (selected-frame) 55) (sleep-for 2)) This used to leave me with a 150 X 55 frame located at 0,0 on my display but it instead now leaves me with a default size frame still located at 0,0 as expected. Please note that when I said M-x ielm and pasted in the set-frame-width and -height lines as above after emacs finished loading they did as I expected, ie. resized the frame without problem. I replaced these lines with the following in my .emacs as a workaround: (let ((destructo-target (selected-frame))) (make-frame (list '(top . 0) '(left . 0) '(width . 150) '(height . 55))) (delete-frame destructo-target)) In GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600) of 2008-09-06 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Lisp Minor modes in effect: icomplete-mode: t partial-completion-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x l i s p SPC m o d e M-x f i l e SPC b u r e p o r Recent messages: Loading goto-addr...done top.org has auto save data; consider M-x recover-this-file Loading c:/Program Files/emacs-22.3/site-lisp/org-6.12b/lisp/org.el (source)... Loading easy-mmode...done Loading derived...done Loading c:/Program Files/emacs-22.3/site-lisp/org-6.12b/lisp/org.el (source)...done OVERVIEW For information about GNU Emacs and the GNU system, type C-h C-a. Loading url-util...done Loading emacsbug...done From eliz@gnu.org Sat Nov 15 01:40:44 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-9.2 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 15 Nov 2008 09:40:45 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAF9egWj007634 for ; Sat, 15 Nov 2008 01:40:43 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1Hdx-0000qH-OG for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 04:40:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1Hdv-0000oR-5p for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 04:40:40 -0500 Received: from [199.232.76.173] (port=36565 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1Hdv-0000oO-0C for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 04:40:39 -0500 Received: from mtaout7.012.net.il ([84.95.2.19]:9253) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L1Hdu-0003Mi-JU for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 04:40:38 -0500 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KAD00A00C8YOS00@i-mtaout7.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 11:42:31 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.205.49]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KAD006LUCAUNY40@i-mtaout7.012.net.il>; Sat, 15 Nov 2008 11:42:31 +0200 (IST) Date: Sat, 15 Nov 2008 11:40:39 +0200 From: Eli Zaretskii Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows In-reply-to: X-012-Sender: halo1@inter.net.il To: Themba Fletcher , 1348@debbugs.gnu.org Cc: bug-gnu-emacs@gnu.org Reply-to: Eli Zaretskii Message-id: References: X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) > From: "Themba Fletcher" > Date: Fri, 14 Nov 2008 17:46:19 -0500 > Cc: > > When migrating to Emacs 22.3.1 on microsoft windows, the following > lines in my .emacs file do not behave as expected: > > (set-frame-position (selected-frame) 0 0) > (sleep-for 2) ; not originally in my .emacs -- testing only > (set-frame-width (selected-frame) 150) > (sleep-for 2) > (set-frame-height (selected-frame) 55) > (sleep-for 2)) ^ (Extra paren here.) > This used to leave me with a 150 X 55 frame located at 0,0 on my > display but it instead now leaves me with a default size frame still > located at 0,0 as expected. This leaves me with a 80x55 frame located at (0,0), not a default size frame. I see this both in Emacs 22.3.1 and in the current CVS trunk. So, while still not entirely correct, the behavior I see is different, and I wonder why. Is the above the _only_ contents of your .emacs? From eliz@gnu.org Sat Nov 15 02:04:36 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-9.3 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 15 Nov 2008 10:04:36 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAFA4XmV012524 for ; Sat, 15 Nov 2008 02:04:35 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1I13-0005ck-Jt for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 05:04:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1I12-0005cW-Vl for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 05:04:33 -0500 Received: from [199.232.76.173] (port=44892 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1I12-0005cJ-PR for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 05:04:32 -0500 Received: from mtaout4.012.net.il ([84.95.2.10]:35734) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L1I12-0004x5-4K for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 05:04:32 -0500 Received: from conversion-daemon.i_mtaout4.012.net.il by i_mtaout4.012.net.il (HyperSendmail v2004.12) id <0KAD00200D7E7700@i_mtaout4.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 15 Nov 2008 12:06:24 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.205.49]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KAD00BO3DEN56H0@i_mtaout4.012.net.il>; Sat, 15 Nov 2008 12:06:24 +0200 (IST) Date: Sat, 15 Nov 2008 12:04:32 +0200 From: Eli Zaretskii Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows In-reply-to: X-012-Sender: halo1@inter.net.il To: 1348@debbugs.gnu.org Cc: themba@shirleymachine.com, bug-gnu-emacs@gnu.org Reply-to: Eli Zaretskii Message-id: References: X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 > Date: Sat, 15 Nov 2008 11:40:39 +0200 > From: Eli Zaretskii > Cc: bug-gnu-emacs@gnu.org > > This leaves me with a 80x55 frame located at (0,0), not a default size > frame. I see this both in Emacs 22.3.1 and in the current CVS trunk. I think this might be because of the code in w32term.c:x_set_window_size that was ifdef'ed away to solve a more grave problem. From rudalics@gmx.at Sat Nov 15 06:15:19 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 15 Nov 2008 14:15:19 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAFEFFY6012715 for <1348@emacsbugs.donarmstrong.com>; Sat, 15 Nov 2008 06:15:17 -0800 Received: (qmail invoked by alias); 15 Nov 2008 14:15:10 -0000 Received: from 62-47-55-18.adsl.highway.telekom.at (EHLO [62.47.55.18]) [62.47.55.18] by mail.gmx.net (mp025) with SMTP; 15 Nov 2008 15:15:10 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX182rG8Xpao2LIo1uD6cGXDR8BvakvceUrE622ejgQ S9FUyve4TS30if Message-ID: <491ED8E1.9050705@gmx.at> Date: Sat, 15 Nov 2008 15:12:49 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eli Zaretskii CC: 1348@debbugs.gnu.org, themba@shirleymachine.com Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 >> This leaves me with a 80x55 frame located at (0,0), not a default size >> frame. I see this both in Emacs 22.3.1 and in the current CVS trunk. > > I think this might be because of the code in > w32term.c:x_set_window_size that was ifdef'ed away to solve a more > grave problem. Yes. But why does `set-frame-height' work after loading .emacs? The menubar lines problem can bite whenever we resize a single-frame Emacs. So what am I missing? BTW, is this related to Bugs#117 and #201? martin From grishka@gmx.de Mon Nov 17 07:07:06 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-9.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_MED,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Nov 2008 15:07:06 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAHF73VZ013713 for ; Mon, 17 Nov 2008 07:07:04 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L25gs-0007qX-UP for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 10:07:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L25gq-0007qC-Ql for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 10:07:01 -0500 Received: from [199.232.76.173] (port=42796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L25gq-0007q9-N5 for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 10:07:00 -0500 Received: from mail.gmx.net ([213.165.64.20]:60265) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L25gq-0002j4-0J for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 10:07:00 -0500 Received: (qmail invoked by alias); 17 Nov 2008 15:06:56 -0000 Received: from 1Cust183.tnt5.ber2.deu.da.uu.net (EHLO [149.225.86.183]) [149.225.86.183] by mail.gmx.net (mp068) with SMTP; 17 Nov 2008 16:06:56 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX19Tjjckr3VTqp2L6yEXKb7D8MSODgoMKQcYzUe4t3 29YJ+yHUuqTunc Message-ID: <49218888.7080400@gmx.de> Date: Mon, 17 Nov 2008 16:06:48 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: E1L17R3-0004bg-5H@lists.gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > From: "Themba Fletcher" > > When migrating to Emacs 22.3.1 on microsoft windows, the following > lines in my .emacs file do not behave as expected: > > (set-frame-position (selected-frame) 0 0) > (sleep-for 2) ; not originally in my .emacs -- testing only > (set-frame-width (selected-frame) 150) > (sleep-for 2) > (set-frame-height (selected-frame) 55) > (sleep-for 2)) > Actually it doesn't work on X/GTK either. From themba@shirleymachine.com Mon Nov 17 12:50:34 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-8.2 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, NEXTPART,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Nov 2008 20:50:34 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAHKoUxh003013 for ; Mon, 17 Nov 2008 12:50:32 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2B3G-0007Q6-8v for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 15:50:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2B3F-0007Oj-EX for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 15:50:29 -0500 Received: from [199.232.76.173] (port=50651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2B3F-0007OV-3W for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 15:50:29 -0500 Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]:22392) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L2B3E-0005zr-Jx for bug-gnu-emacs@gnu.org; Mon, 17 Nov 2008 15:50:28 -0500 Received: (qmail 67875 invoked from network); 17 Nov 2008 20:50:23 -0000 Received: from unknown (HELO cadstation01) (themba@76.252.62.121 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 17 Nov 2008 20:50:23 -0000 X-YMail-OSG: OvrzUokVM1l1Xzgvr_6tMo9mKsQ87CmlgHdMusvtr3i4EtuQoKKJiyR5xcfGTpN9Bt1q9lejEoCNTwUZHAoOjfU9tsrQ6gwPNaKgRugyRQtr1NhidWE5crZPOPU8MAg_vdOQQMtb.kXVz5RheuW5DCei X-Yahoo-Newman-Property: ymail-3 From: "Themba Fletcher" To: "'Eli Zaretskii'" Cc: Subject: RE: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Date: Mon, 17 Nov 2008 15:50:06 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C948CC.2A2EACC0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclHBjdNBKtX2ZYiRQC1VBajr49IUgB7caiQ X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C948CC.2A2EACC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Eli Zaretskii [mailto:eliz@gnu.org] > Sent: Saturday, November 15, 2008 4:41 AM > To: Themba Fletcher; 1348@emacsbugs.donarmstrong.com > Cc: bug-gnu-emacs@gnu.org > > From: "Themba Fletcher" > > Date: Fri, 14 Nov 2008 17:46:19 -0500 > > Cc: > > When migrating to Emacs 22.3.1 on microsoft windows, the following > > lines in my .emacs file do not behave as expected: > > (set-frame-position (selected-frame) 0 0) > > (sleep-for 2) ; not originally in my .emacs -- testing only > > (set-frame-width (selected-frame) 150) > > (sleep-for 2) > > (set-frame-height (selected-frame) 55) > > (sleep-for 2)) > (Extra paren here^) Whoops, this was nested in an expression while I was testing. > > This used to leave me with a 150 X 55 frame located at 0,0 on my > > display but it instead now leaves me with a default size frame still > > located at 0,0 as expected. > This leaves me with a 80x55 frame located at (0,0), not a default size > frame. I see this both in Emacs 22.3.1 and in the current CVS trunk. > So, while still not entirely correct, the behavior I see is different, > and I wonder why. Is the above the _only_ contents of your .emacs? No, but the behavior held even when the rest of my .emacs was commented out. Please feel free to play with my original .emacs file, attached. I was upgrading, due to standard windows problems (ie I had to reformat and reinstall), from Emacs 22.1 when I found this. Over the weekend I moved my home machine from Emacs 22.2 to 22.3 and discovered two things: 1. The bug is present in 22.2 2. (set-frame-size) is not affected, and is probably a better work-around than I gave in my previous message. ------=_NextPart_000_0006_01C948CC.2A2EACC0 Content-Type: application/octet-stream; name="dot-emacs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dot-emacs" (server-start) ;; = *************************************************************************= ** (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(column-number-mode t) '(org-agenda-files (quote ("c:/Documents and = Settings/tif/Desktop/top.org"))) '(scroll-bar-mode nil) '(size-indication-mode t) '(tool-bar-mode nil)) (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ) ;; = *************************************************************************= ** (set-frame-position (selected-frame) 0 0) (set-frame-height (selected-frame) 66) (set-frame-width (selected-frame) 178) (set-frame-name "emacs") (set-default-font "-outline-Bitstream Vera Sans = Mono-normal-r-normal-normal-12-90-96-96-c-*-iso8859-1") (iconify-frame) ;; my global settings (put 'upcase-region 'disabled nil) (transient-mark-mode)=20 (global-font-lock-mode 1) (partial-completion-mode 1) (icomplete-mode 1) (setq inhibit-splash-screen t) ;; colors (require 'color-theme) (color-theme-select) ; bullshit (kill-buffer "*Color Theme Selection*") ; bullshit (color-theme-jsc-dark) ;; print to dell laser, shared by local machine ;; M-x eshell, then net view cadstation01 to see shares list=20 (setq printer-name "//cadstation01/dell1710") ;; programming modes (require 'generic-x) (add-to-list 'auto-mode-alist '("\\.el$" . emacs-lisp-mode)) (add-to-list 'auto-mode-alist '("\\.elisp$" . emacs-lisp-mode)) ;; sql-mode settings for local oracle installation (require 'sql) (defalias 'sql-get-login 'ignore) ;; org-mode (require 'org-install) (add-to-list 'auto-mode-alist '("\\.org$" . org-mode)) (define-key global-map "\C-cl" 'org-store-link) (define-key global-map "\C-ca" 'org-agenda) (setq org-log-done t) (setq org-agenda-custom-commands '(("n" occur-tree ":next:"))) (setq org-hide-leading-stars t) ;; NC-MODE !!! (require 'nc) (add-to-list 'auto-mode-alist '("\\.nc$" . nc-mode)) (defun edit-dot-emacs () (interactive) (find-file "c:\.emacs")) (put 'downcase-region 'disabled nil) ;; startup (find-file "c:/Documents and Settings/tif/Desktop/top.org") ------=_NextPart_000_0006_01C948CC.2A2EACC0-- From rudalics@gmx.at Tue Nov 18 05:05:58 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.2 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MIXEDBDN,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 18 Nov 2008 13:05:58 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAID5sHR022144 for <1348@emacsbugs.donarmstrong.com>; Tue, 18 Nov 2008 05:05:55 -0800 Received: (qmail invoked by alias); 18 Nov 2008 13:05:48 -0000 Received: from 62-47-49-27.adsl.highway.telekom.at (EHLO [62.47.49.27]) [62.47.49.27] by mail.gmx.net (mp021) with SMTP; 18 Nov 2008 14:05:48 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/aNNAJe5LafDtGl23M8Rv6KcnIetH8ZxKa2SoYSd qtzGeli8SY/Nxl Message-ID: <4922BD1F.2080604@gmx.at> Date: Tue, 18 Nov 2008 14:03:27 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Themba Fletcher CC: 1348@debbugs.gnu.org, "'Eli Zaretskii'" Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050206010601090607060303" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.72,0.55 This is a multi-part message in MIME format. --------------050206010601090607060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >>> When migrating to Emacs 22.3.1 on microsoft windows, the following >>> lines in my .emacs file do not behave as expected: > >>> (set-frame-position (selected-frame) 0 0) >>> (sleep-for 2) ; not originally in my .emacs -- testing only >>> (set-frame-width (selected-frame) 150) >>> (sleep-for 2) >>> (set-frame-height (selected-frame) 55) >>> (sleep-for 2)) [...] > 1. The bug is present in 22.2 > 2. (set-frame-size) is not affected, and is probably a better work-around > than I gave in my previous message. Interesting. Does the attached patch give better results? martin --------------050206010601090607060303 Content-Type: text/plain; name="dispnew.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dispnew.diff" *** dispnew.c.~1.424.~ 2008-10-28 07:22:51.656250000 +0100 --- dispnew.c 2008-11-18 13:57:27.546875000 +0100 *************** *** 6305,6310 **** --- 6305,6316 ---- int new_frame_total_cols; int count = SPECPDL_INDEX (); + /* If an argument is zero, set it to the current value. */ + if (newheight == 0) + newheight = FRAME_LINES (f); + if (newwidth == 0) + newwidth = FRAME_COLS (f); + /* If we can't deal with the change now, queue it for later. */ if (delay || (redisplaying_p && !safe)) { *************** *** 6318,6329 **** f->new_text_lines = 0; f->new_text_cols = 0; - /* If an argument is zero, set it to the current value. */ - if (newheight == 0) - newheight = FRAME_LINES (f); - if (newwidth == 0) - newwidth = FRAME_COLS (f); - /* Compute width of windows in F. This is the width of the frame without vertical scroll bars. */ new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth); --- 6324,6329 ---- --------------050206010601090607060303-- From grishka@gmx.de Wed Nov 26 13:22:48 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.0 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 26 Nov 2008 21:22:48 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAQLMiZ9024946 for <1348@emacsbugs.donarmstrong.com>; Wed, 26 Nov 2008 13:22:46 -0800 Received: (qmail invoked by alias); 26 Nov 2008 21:22:38 -0000 Received: from 1Cust9.tnt6.ber2.deu.da.uu.net (EHLO [149.225.88.9]) [149.225.88.9] by mail.gmx.net (mp018) with SMTP; 26 Nov 2008 22:22:38 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1+f5LsZFZuf0PTFLldFPCrdRpk2krKH2PTJ9jkEtg qpN83zwuf/DjE9 Message-ID: <492DBE0C.1030707@gmx.de> Date: Wed, 26 Nov 2008 22:22:20 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 martin rudalics wrote: > Interesting. Does the attached patch give better results? Why waste time with looking for "better results" instead of a correct solution? Which is obviously that these set-frame-xxx functions need to wait for the ConfigureNotify event and to handle it before they return. From rudalics@gmx.at Thu Nov 27 05:46:55 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 27 Nov 2008 13:46:55 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mARDkqe7018820 for <1348@emacsbugs.donarmstrong.com>; Thu, 27 Nov 2008 05:46:53 -0800 Received: (qmail invoked by alias); 27 Nov 2008 13:46:46 -0000 Received: from 62-47-58-151.adsl.highway.telekom.at (EHLO [62.47.58.151]) [62.47.58.151] by mail.gmx.net (mp047) with SMTP; 27 Nov 2008 14:46:46 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+uokFj3Q+uGvGFCD+JVcVaCULcizfbqRrEqKOfEu 6We0jBkD/INpd4 Message-ID: <492EA390.1020206@gmx.at> Date: Thu, 27 Nov 2008 14:41:36 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka , 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> In-Reply-To: <492DBE0C.1030707@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 > Why waste time with looking for "better results" instead of a > correct solution? > > Which is obviously that these set-frame-xxx functions need to wait > for the ConfigureNotify event and to handle it before they return. I doubt such a solution would be generally feasible. A command might try to set the height and width of a couple of frames. It can't wait for a ConfigureNotify event to arrive for each of these. martin From grishka@gmx.de Thu Nov 27 09:51:47 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.0 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 27 Nov 2008 17:51:47 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mARHpgvJ017534 for <1348@emacsbugs.donarmstrong.com>; Thu, 27 Nov 2008 09:51:44 -0800 Received: (qmail invoked by alias); 27 Nov 2008 17:51:36 -0000 Received: from 1Cust21.tnt8.ber2.deu.da.uu.net (EHLO [149.225.152.21]) [149.225.152.21] by mail.gmx.net (mp040) with SMTP; 27 Nov 2008 18:51:36 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/UJUw5J5rUSc+/Lqg2uPuw+9dg2R0GdIn9u62kBY NuaAUS08N9ZnLW Message-ID: <492EDCC9.7070806@gmx.de> Date: Thu, 27 Nov 2008 18:45:45 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> In-Reply-To: <492EA390.1020206@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 martin rudalics wrote: > > Why waste time with looking for "better results" instead of a > > correct solution? > > > > Which is obviously that these set-frame-xxx functions need to wait > > for the ConfigureNotify event and to handle it before they return. > > I doubt such a solution would be generally feasible. A command might > try to set the height and width of a couple of frames. It can't wait > for a ConfigureNotify event to arrive for each of these. Why can't it wait? A couple of frames doesn't sound like thousands and also you probably would not start editing your files while your frames are still moving around. So it wouldn't make any difference on the user level, except that you'd get correct results by design. And then it can of course (and probably should) handle other events while waiting for the ConfigureNotify. In GUI apps it is normal that "wait" doesn't mean just sleep or block. Btw, on ms-windows such serialization is built-in actually. With a call like "SetWindowPos" you'd get the WM_WINDOWPOSCHANGED message with the new coordinates and sizes before the call returns. From rudalics@gmx.at Thu Nov 27 11:50:35 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 27 Nov 2008 19:50:35 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mARJoV4a016003 for <1348@emacsbugs.donarmstrong.com>; Thu, 27 Nov 2008 11:50:33 -0800 Received: (qmail invoked by alias); 27 Nov 2008 19:50:25 -0000 Received: from 62-47-35-39.adsl.highway.telekom.at (EHLO [62.47.35.39]) [62.47.35.39] by mail.gmx.net (mp018) with SMTP; 27 Nov 2008 20:50:25 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19QnyRvlKZQd2tQDSBTfSM+FjCva1WtWca/d+Kzny arR3+v8eND7cqD Message-ID: <492EF976.1070108@gmx.at> Date: Thu, 27 Nov 2008 20:48:06 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> In-Reply-To: <492EDCC9.7070806@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 > Why can't it wait? A couple of frames doesn't sound like thousands > and also you probably would not start editing your files while your > frames are still moving around. So it wouldn't make any difference > on the user level, except that you'd get correct results by design. I have never looked into that code. IIUC one problem is flickering when a frame gets redrawn too often. Moreover, it's not always safe to redraw frames. > And then it can of course (and probably should) handle other events > while waiting for the ConfigureNotify. In GUI apps it is normal that > "wait" doesn't mean just sleep or block. Sounds rather like an additional complication. At the time we call `set-frame-height' we want to execute Lisp code. > Btw, on ms-windows such serialization is built-in actually. With > a call like "SetWindowPos" you'd get the WM_WINDOWPOSCHANGED message > with the new coordinates and sizes before the call returns. Isn't this WM_WINDOWPOSCHANGING? In any case, it seems we still wouldn't know how many lines the menubar occupies, or am I missing something? I'm currently aware of the following bugs WRT frame management on Windows: - One can set the frame size only once in a command - that's the bug we're talking about here. - It may take some time to redraw an Emacs frame after removing another frame that obscured it (see also Bug#117 and Bug#950). - All sorts of problems reported by Drew Adams in Bug#117. Contributions to fix any of these are most welcome ;-) martin From grishka@gmx.de Sat Nov 29 11:44:03 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.4 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MDO_CABLE_TV3,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 29 Nov 2008 19:44:03 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mATJhxgP007991 for <1348@emacsbugs.donarmstrong.com>; Sat, 29 Nov 2008 11:44:01 -0800 Received: (qmail invoked by alias); 29 Nov 2008 19:43:52 -0000 Received: from 1Cust245.tnt5.ber2.deu.da.uu.net (EHLO [149.225.86.245]) [149.225.86.245] by mail.gmx.net (mp026) with SMTP; 29 Nov 2008 20:43:52 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/brtpktzPbvn57byfFan03HY5tMyDPDnahQnxpD0 03eREJBmBaXgeq Message-ID: <49319B2E.20006@gmx.de> Date: Sat, 29 Nov 2008 20:42:38 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> In-Reply-To: <492EF976.1070108@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 martin rudalics wrote: > > Why can't it wait? A couple of frames doesn't sound like thousands > > and also you probably would not start editing your files while your > > frames are still moving around. So it wouldn't make any difference > > on the user level, except that you'd get correct results by design. > > I have never looked into that code. IIUC one problem is flickering when > a frame gets redrawn too often. Moreover, it's not always safe to > redraw frames. Redraw? Isn't this about resize rather than redraw? > > And then it can of course (and probably should) handle other events > > while waiting for the ConfigureNotify. In GUI apps it is normal that > > "wait" doesn't mean just sleep or block. > > Sounds rather like an additional complication. At the time we call > `set-frame-height' we want to execute Lisp code. Complication is not additional if it allows you to get rid of other complication, in particular such that causes inexplicable misbehavior. > ... In any case, it seems we still > wouldn't know how many lines the menubar occupies, or am I missing > something? Well, whatever the answer to this question is, I'm afraid it wouldn't help to understand the bug. It happens with no menubar as well. From rudalics@gmx.at Sun Nov 30 01:23:22 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.8 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 09:23:22 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAU9NIOY024164 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 01:23:20 -0800 Received: (qmail invoked by alias); 30 Nov 2008 09:23:12 -0000 Received: from 88-117-46-34.adsl.highway.telekom.at (EHLO [88.117.46.34]) [88.117.46.34] by mail.gmx.net (mp046) with SMTP; 30 Nov 2008 10:23:12 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19QOC51X9lQEIQg05jniOPYldkmHy5VcMrrgVNPBz eFRkFQQONwdboY Message-ID: <49325AAA.5090606@gmx.at> Date: Sun, 30 Nov 2008 10:19:38 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> In-Reply-To: <49319B2E.20006@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.72 >> I have never looked into that code. IIUC one problem is flickering when >> a frame gets redrawn too often. Moreover, it's not always safe to >> redraw frames. > > Redraw? Isn't this about resize rather than redraw? You can, in one command, issue a number of resize requests. I doubt we want each of them cause a redisplay/redraw before the command completes. >> ... In any case, it seems we still >> wouldn't know how many lines the menubar occupies, or am I missing >> something? > > Well, whatever the answer to this question is, I'm afraid it wouldn't > help to understand the bug. It happens with no menubar as well. The wrapping menubar problem is one of the w32 API - it's nothing we can do about. Personally, I considered Jason's reaction too drastic. So maybe we should make it conditional on the presence of a menubar. Also, I see other applications truncate the menubar in a similar situation. Anyway - I don't have much of an idea what to do here. If you can provide any patches I'll be happy to test them. martin From grishka@gmx.de Sun Nov 30 09:40:44 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.4 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 17:40:44 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAUHeeIY023424 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 09:40:42 -0800 Received: (qmail invoked by alias); 30 Nov 2008 17:40:33 -0000 Received: from 1Cust98.tnt3.ber2.deu.da.uu.net (EHLO [149.225.56.98]) [149.225.56.98] by mail.gmx.net (mp021) with SMTP; 30 Nov 2008 18:40:33 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX18Kfd5C5L8K0dKbX0uoADL7DADXbTErZIPipj2NSp LrHGoHFCtQv7W5 Message-ID: <4932CFFF.6000204@gmx.de> Date: Sun, 30 Nov 2008 18:40:15 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> In-Reply-To: <49325AAA.5090606@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 martin rudalics wrote: > >> I have never looked into that code. IIUC one problem is flickering > when > >> a frame gets redrawn too often. Moreover, it's not always safe to > >> redraw frames. > > > > Redraw? Isn't this about resize rather than redraw? > > You can, in one command, issue a number of resize requests. I doubt we > want each of them cause a redisplay/redraw before the command completes. But who said anything about redisplay/redraw? What it needs to wait for is the notification from the window system or toolkit that the resize request was carried out. Otherwise emacs runs into situations where the state of it's internal variables w.r.t. frame size/position is not consistent with the state of the GUI, and in consequence the inconsistent GUI state works back on these variables. (by means of the logic meant for mouse sizing/dragging) I guess that is the basic problem. There may be additional aspects like toolkit differences or race conditions. From rudalics@gmx.at Sun Nov 30 12:04:28 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 20:04:28 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAUK4Nei026660 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 12:04:25 -0800 Received: (qmail invoked by alias); 30 Nov 2008 20:04:17 -0000 Received: from 62-47-55-245.adsl.highway.telekom.at (EHLO [62.47.55.245]) [62.47.55.245] by mail.gmx.net (mp044) with SMTP; 30 Nov 2008 21:04:17 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/PRPVJVNHPXK4y67hsbUnjFiWJmk2lWIN/aH5StN b9/ZoUzR6byX06 Message-ID: <4932F14B.9030701@gmx.at> Date: Sun, 30 Nov 2008 21:02:19 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <4932CFFF.6000204@gmx.de> In-Reply-To: <4932CFFF.6000204@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 > But who said anything about redisplay/redraw? What it needs to > wait for is the notification from the window system or toolkit > that the resize request was carried out. The WM_WINDOWPOSCHANGED message is sent after the window is shown (redisplayed, redrawn, ...). martin From grishka@gmx.de Sun Nov 30 14:05:11 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.3 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 22:05:11 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAUM57uV025195 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 14:05:08 -0800 Received: (qmail invoked by alias); 30 Nov 2008 22:05:01 -0000 Received: from 1Cust194.tnt1.ber2.deu.da.uu.net (EHLO [149.225.52.194]) [149.225.52.194] by mail.gmx.net (mp008) with SMTP; 30 Nov 2008 23:05:01 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/H6jlBEKPHQpK+i2HZEhA484Jy6h88Zqu0iHIDVu qBg4s6i3jk48ms Message-ID: <49330DFD.7060209@gmx.de> Date: Sun, 30 Nov 2008 23:04:45 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <4932CFFF.6000204@gmx.de> <4932F14B.9030701@gmx.at> In-Reply-To: <4932F14B.9030701@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 martin rudalics wrote: > > But who said anything about redisplay/redraw? What it needs to > > wait for is the notification from the window system or toolkit > > that the resize request was carried out. > > The WM_WINDOWPOSCHANGED message is sent after the window is shown > (redisplayed, redrawn, ...). > > martin > How this? Say if I click the "maximise" button, you think that emacs first redraws itself and later then sets the new row/col count? From rudalics@gmx.at Sun Nov 30 14:52:51 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 22:52:51 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAUMqlEg005364 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 14:52:49 -0800 Received: (qmail invoked by alias); 30 Nov 2008 22:52:42 -0000 Received: from 62-47-53-190.adsl.highway.telekom.at (EHLO [62.47.53.190]) [62.47.53.190] by mail.gmx.net (mp005) with SMTP; 30 Nov 2008 23:52:42 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/9y9YU4ZX9P5ylARy4IqchSfsAG1C3THrDsy6qXW Jb2LBSj2wq6Wa1 Message-ID: <493318C5.9010007@gmx.at> Date: Sun, 30 Nov 2008 23:50:45 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <4932CFFF.6000204@gmx.de> <4932F14B.9030701@gmx.at> <49330DFD.7060209@gmx.de> In-Reply-To: <49330DFD.7060209@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 >> > But who said anything about redisplay/redraw? What it needs to >> > wait for is the notification from the window system or toolkit >> > that the resize request was carried out. >> >> The WM_WINDOWPOSCHANGED message is sent after the window is shown >> (redisplayed, redrawn, ...). >> > How this? Say if I click the "maximise" button, you think that > emacs first redraws itself and later then sets the new row/col > count? I don't. But how does this relate to what I said above? It's one thing what Emacs does by itself and another thing what it's asked to do. martin From grishka@gmx.de Sun Nov 30 15:08:54 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.3 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 23:08:54 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mAUN8oHg009769 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 15:08:52 -0800 Received: (qmail invoked by alias); 30 Nov 2008 23:08:44 -0000 Received: from 1Cust204.tnt2.ber2.deu.da.uu.net (EHLO [149.225.54.204]) [149.225.54.204] by mail.gmx.net (mp037) with SMTP; 01 Dec 2008 00:08:44 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1986AJIC7Z8GO0xn49I+hJaB+FEQ+Wptp2d2AxsUC Zhq80Y7nN0eQba Message-ID: <49331CEC.1040905@gmx.de> Date: Mon, 01 Dec 2008 00:08:28 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <4932CFFF.6000204@gmx.de> <4932F14B.9030701@gmx.at> <49330DFD.7060209@gmx.de> <493318C5.9010007@gmx.at> In-Reply-To: <493318C5.9010007@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 martin rudalics wrote: > ... It's > one thing what Emacs does by itself and another thing what it's > asked to do. We know that. That's why people write bug reports. From jasonr@f2s.com Sun Nov 30 15:54:34 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER, SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 30 Nov 2008 23:54:34 +0000 Received: from mk-outboundfilter-5-a-2.mail.uk.tiscali.com (mk-outboundfilter-5-a-2.mail.uk.tiscali.com [212.74.114.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mAUNsU4q020838 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 15:54:32 -0800 X-Trace: 112713116/mk-outboundfilter-5.mail.uk.tiscali.com/F2S/$F2S-MX-ACCEPTED/f2s-freedom2surf-infrastructure/194.106.33.239/None/jasonr@f2s.com X-SBRS: None X-RemoteIP: 194.106.33.239 X-IP-MAIL-FROM: jasonr@f2s.com X-MUA: Internet Messaging Program (IMP) 3.2.3 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEDAPO1MknCaiHv/2dsb2JhbACSNLoKgn0 X-IronPort-AV: E=Sophos;i="4.33,691,1220223600"; d="scan'208";a="112713116" X-IP-Direction: IN Received: from mail5.freedom2surf.net (HELO webmail1.freedom2surf.net) ([194.106.33.239]) by smtp.f2s.tiscali.co.uk with ESMTP; 30 Nov 2008 23:54:24 +0000 Received: from localhost (i-194-106-33-239 [127.0.0.1]) by webmail1.freedom2surf.net (Postfix) with ESMTP id 82270228539; Sun, 30 Nov 2008 23:54:24 +0000 (GMT) Received: from 61.4.103.130 ([61.4.103.130]) by webmail.freedom2surf.net (IMP) with HTTP for ; Sun, 30 Nov 2008 23:54:24 +0000 Message-ID: <1228089264.493327b06fd4e@webmail.freedom2surf.net> Date: Sun, 30 Nov 2008 23:54:24 +0000 From: jasonr@f2s.com To: martin rudalics , 1348@debbugs.gnu.org Cc: grischka Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> In-Reply-To: <49325AAA.5090606@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 61.4.103.130 Quoting martin rudalics : > The wrapping menubar problem is one of the w32 API - it's nothing we can > do about. Personally, I considered Jason's reaction too drastic. Please explain. This is my first contribution to this thread, so obviously you are talking about something in the distant past which my memory cannot recall. From rudalics@gmx.at Sun Nov 30 23:34:34 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 1 Dec 2008 07:34:34 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB17YUul008532 for <1348@emacsbugs.donarmstrong.com>; Sun, 30 Nov 2008 23:34:31 -0800 Received: (qmail invoked by alias); 01 Dec 2008 07:30:36 -0000 Received: from 62-47-35-202.adsl.highway.telekom.at (EHLO [62.47.35.202]) [62.47.35.202] by mail.gmx.net (mp033) with SMTP; 01 Dec 2008 08:30:36 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19RtpskK2BR3u6RNljzCuPcn9vbCgLRKh4DsYatDa kkcr4LHjE7+prR Message-ID: <49339200.7080603@gmx.at> Date: Mon, 01 Dec 2008 08:28:00 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: jasonr@f2s.com CC: 1348@debbugs.gnu.org, grischka Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> In-Reply-To: <1228089264.493327b06fd4e@webmail.freedom2surf.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 >> The wrapping menubar problem is one of the w32 API - it's nothing we can >> do about. Personally, I considered Jason's reaction too drastic. > > Please explain. This is my first contribution to this thread, so obviously you > are talking about something in the distant past which my memory cannot recall. As Eli explained earlier, this thread is a consequence of your change 2007-10-09 Jason Rumney * w32term.c (x_set_window_size): Disable code that attempts to tell Lisp code about a size change before it actually happens. which causes, according to the OP, a sequence of frame changes like (set-frame-position (selected-frame) 0 0) (sleep-for 2) ; not originally in my .emacs -- testing only (set-frame-width (selected-frame) 150) (sleep-for 2) (set-frame-height (selected-frame) 55) (sleep-for 2)) to virtually do the first operation only. According to grischka something similar happens on X/GTK as well, but he never told us what he sees there. IIUC your change is motivated as /* The following mirrors what is done in xterm.c. It appears to be for informing lisp of the new size immediately, while the actual resize will happen asynchronously. But on Windows, the menu bar automatically wraps when the frame is too narrow to contain it, and that causes any calculations made here to come out wrong. The end is some nasty buggy behavior, including the potential loss of the minibuffer. Disabling this code is either not sufficient to fix the problems completely, or it causes fresh problems, but at least it removes the most problematic symptom of the minibuffer becoming unusable. [...] */ Given that wrapping menubars are not very frequent, it seems to me that by now the "fresh problems" outweigh the "menubar problem", but YMMV. martin From jasonr@f2s.com Mon Dec 1 00:22:28 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.0 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 1 Dec 2008 08:22:28 +0000 Received: from mk-outboundfilter-6-a-2.mail.uk.tiscali.com (mk-outboundfilter-6-a-2.mail.uk.tiscali.com [212.74.114.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB18MOm7021512 for <1348@emacsbugs.donarmstrong.com>; Mon, 1 Dec 2008 00:22:26 -0800 X-Trace: 57216976/mk-outboundfilter-6.mail.uk.tiscali.com/F2S/$F2S-MX-ACCEPTED/f2s-freedom2surf-infrastructure/194.106.33.239 X-SBRS: None X-RemoteIP: 194.106.33.239 X-IP-MAIL-FROM: jasonr@f2s.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEDAP8sM0nCaiHv/2dsb2JhbACSNbsPgn0 X-IronPort-AV: E=Sophos;i="4.33,694,1220223600"; d="scan'208";a="57216976" X-IP-Direction: IN Received: from mail5.freedom2surf.net (HELO webmail1.freedom2surf.net) ([194.106.33.239]) by smtp.f2s.tiscali.co.uk with ESMTP; 01 Dec 2008 08:22:17 +0000 Received: from localhost (i-194-106-33-239 [127.0.0.1]) by webmail1.freedom2surf.net (Postfix) with ESMTP id 82DAE228539; Mon, 1 Dec 2008 08:22:17 +0000 (GMT) Received: from 61.4.103.130 ([61.4.103.130]) by webmail.freedom2surf.net (IMP) with HTTP for ; Mon, 1 Dec 2008 08:22:17 +0000 Message-ID: <1228119737.49339eb964cc6@webmail.freedom2surf.net> Date: Mon, 1 Dec 2008 08:22:17 +0000 From: jasonr@f2s.com To: martin rudalics Cc: 1348@debbugs.gnu.org, grischka Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> In-Reply-To: <49339200.7080603@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 61.4.103.130 Quoting martin rudalics : > IIUC your change is motivated as > > Disabling this code is either not sufficient to fix the problems > completely, or it causes fresh problems, but at least it removes > the most problematic symptom of the minibuffer becoming unusable. > > Given that wrapping menubars are not very frequent, it seems to me that > by now the "fresh problems" outweigh the "menubar problem", but YMMV. Which of the fresh problems outweighs an unusable minibuffer? From rudalics@gmx.at Mon Dec 1 01:37:20 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 1 Dec 2008 09:37:20 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB19bGqr007988 for <1348@emacsbugs.donarmstrong.com>; Mon, 1 Dec 2008 01:37:17 -0800 Received: (qmail invoked by alias); 01 Dec 2008 09:37:10 -0000 Received: from 62-47-54-82.adsl.highway.telekom.at (EHLO [62.47.54.82]) [62.47.54.82] by mail.gmx.net (mp033) with SMTP; 01 Dec 2008 10:37:10 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18xlLltXTExcNlM1+a4Wz9iDWXXbhBpLfQYplyTFY lVKU6C+Dd/QfNI Message-ID: <4933AFA5.5020109@gmx.at> Date: Mon, 01 Dec 2008 10:34:29 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: jasonr@f2s.com CC: 1348@debbugs.gnu.org, grischka Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> In-Reply-To: <1228119737.49339eb964cc6@webmail.freedom2surf.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 > Which of the fresh problems outweighs an unusable minibuffer? The one that a resize request has no effect. But as I stated before that's just my personal opinion. martin From grishka@gmx.de Mon Dec 1 22:12:26 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.2 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 2 Dec 2008 06:12:26 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB26CMw4032249 for <1348@emacsbugs.donarmstrong.com>; Mon, 1 Dec 2008 22:12:23 -0800 Received: (qmail invoked by alias); 02 Dec 2008 06:12:15 -0000 Received: from 1Cust45.tnt1.ber2.deu.da.uu.net (EHLO [149.225.52.45]) [149.225.52.45] by mail.gmx.net (mp057) with SMTP; 02 Dec 2008 07:12:15 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1+nRfZB6renHeR4Y0HblJCA+zKKEv9et1XYvAgBEG lZby7rArRCjLSg Message-ID: <4934D1AF.50905@gmx.de> Date: Tue, 02 Dec 2008 07:11:59 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> In-Reply-To: <4933AFA5.5020109@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Below is a patch that fixes the problem on windows. As to X, it turned out that there is actually something similar, it calls itself "x_sync_with_move". Have fun. ######################################## --- w32term-old.c Mon Dec 01 17:50:28 2008 +++ w32term.c Tue Dec 02 06:21:48 2008 @@ -4519,6 +4519,7 @@ w32_read_socket (sd, expected, hold_quit f = x_window_to_frame (dpyinfo, msg.msg.hwnd); /* Inform lisp of whether frame has been iconified etc. */ + if (-100 != sd) if (f) { switch (msg.msg.wParam) @@ -5384,6 +5385,7 @@ x_set_offset (f, xoff, yoff, change_grav 0, 0, SWP_NOZORDER | SWP_NOSIZE | SWP_NOACTIVATE); UNBLOCK_INPUT; + w32_read_socket(-100, 0, NULL); } @@ -5509,6 +5511,7 @@ x_set_window_size (f, change_gravity, co #endif UNBLOCK_INPUT; + w32_read_socket(-100, 0, NULL); } /* Mouse warping. */ ######################################## From jasonr@f2s.com Mon Dec 1 23:42:53 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MDO_CABLE_TV3,MURPHY_DRUGS_REL8,SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 2 Dec 2008 07:42:53 +0000 Received: from mk-outboundfilter-5-a-2.mail.uk.tiscali.com (mk-outboundfilter-5-a-2.mail.uk.tiscali.com [212.74.114.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB27gn5F022509 for <1348@emacsbugs.donarmstrong.com>; Mon, 1 Dec 2008 23:42:51 -0800 X-Trace: 113234936/mk-outboundfilter-5.mail.uk.tiscali.com/F2S/$F2S-MX-ACCEPTED/f2s-freedom2surf-infrastructure/194.106.33.239/None/jasonr@f2s.com X-SBRS: None X-RemoteIP: 194.106.33.239 X-IP-MAIL-FROM: jasonr@f2s.com X-MUA: Internet Messaging Program (IMP) 3.2.3 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosDAJZ1NEnCaiHv/2dsb2JhbACSNr5Rgn0 X-IronPort-AV: E=Sophos;i="4.33,701,1220223600"; d="scan'208";a="113234936" X-IP-Direction: IN Received: from mail5.freedom2surf.net (HELO webmail1.freedom2surf.net) ([194.106.33.239]) by smtp.f2s.tiscali.co.uk with ESMTP; 02 Dec 2008 07:42:43 +0000 Received: from localhost (i-194-106-33-239 [127.0.0.1]) by webmail1.freedom2surf.net (Postfix) with ESMTP id 951E6228539; Tue, 2 Dec 2008 07:42:43 +0000 (GMT) Received: from 61.4.103.130 ([61.4.103.130]) by webmail.freedom2surf.net (IMP) with HTTP for ; Tue, 2 Dec 2008 07:42:43 +0000 Message-ID: <1228203763.4934e6f38c1b2@webmail.freedom2surf.net> Date: Tue, 2 Dec 2008 07:42:43 +0000 From: jasonr@f2s.com To: grischka , 1348@debbugs.gnu.org Cc: martin rudalics Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> In-Reply-To: <4934D1AF.50905@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 61.4.103.130 Quoting grischka : > Below is a patch that fixes the problem on windows. I believe this patch is incorrect, as it will result in the message handling code running in the context of the Lisp thread, which will result in a whole host of unreproducable crashing bugs if left like that. Probably the reason it seems to work is that it introduces a delay that is generally long enough for the real resizing or moving to take place before the Lisp thread continues. Inter-thread synchronization is what is needed here to fix this safely and deterministically. From grishka@gmx.de Tue Dec 2 06:11:52 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-4.9 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MDO_CABLE_TV3,MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 2 Dec 2008 14:11:52 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB2EBmpv023891 for <1348@emacsbugs.donarmstrong.com>; Tue, 2 Dec 2008 06:11:49 -0800 Received: (qmail invoked by alias); 02 Dec 2008 14:11:40 -0000 Received: from 1Cust123.tnt5.ber2.deu.da.uu.net (EHLO [149.225.86.123]) [149.225.86.123] by mail.gmx.net (mp031) with SMTP; 02 Dec 2008 15:11:40 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/kxZg3q3XkzSQVlTqzNgN1exkkCx+Q9QkVXHPSqL Wyn4NCYWQZthUF Message-ID: <4935420B.5060706@gmx.de> Date: Tue, 02 Dec 2008 15:11:23 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: jasonr@f2s.com CC: 1348@debbugs.gnu.org, martin rudalics Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <1228203763.4934e6f38c1b2@webmail.freedom2surf.net> In-Reply-To: <1228203763.4934e6f38c1b2@webmail.freedom2surf.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 jasonr wrote: > Quoting grischka: > >> Below is a patch that fixes the problem on windows. > > I believe this patch is incorrect, as it will result in the message handling > code running in the context of the Lisp thread, which will result in a whole > host of unreproducable crashing bugs if left like that. Probably the reason it > seems to work is that it introduces a delay that is generally long enough for > the real resizing or moving to take place before the Lisp thread continues. Believes are not an approach to code, coincidentally none of the above do apply. > Inter-thread synchronization is what is needed here to fix this safely and > deterministically. Nicely put. This is the theory. (As to practical things that need fixing: HRGN orig_clip; GetClipRgn(s->hdc, orig_clip); Or: for (i = 0; i < len; i++) ExtTextOutW (s->hdc, x + i, y, options, NULL, s->char2b + from + i, 1, NULL); ) From rudalics@gmx.at Tue Dec 2 07:58:23 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 2 Dec 2008 15:58:24 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB2FwJS7018014 for <1348@emacsbugs.donarmstrong.com>; Tue, 2 Dec 2008 07:58:21 -0800 Received: (qmail invoked by alias); 02 Dec 2008 15:58:14 -0000 Received: from 62-47-63-5.adsl.highway.telekom.at (EHLO [62.47.63.5]) [62.47.63.5] by mail.gmx.net (mp029) with SMTP; 02 Dec 2008 16:58:14 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19f1s1nbbZfEr+4xtbn0/tqfyZop0ehwNXHPQ3NVB 72P6QqqzWeCYlR Message-ID: <49355A23.8030001@gmx.at> Date: Tue, 02 Dec 2008 16:54:11 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> In-Reply-To: <4934D1AF.50905@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 > Below is a patch that fixes the problem on windows. > > As to X, it turned out that there is actually something > similar, it calls itself "x_sync_with_move". > > Have fun. Thanks. I'm running Emacs now with your patch and will inform you if and when I find any problems. But please be a bit less cryptic, at least when talking to illiterate people like me ;-) > + if (-100 != sd) [....] > + w32_read_socket(-100, 0, NULL); I suppose the -100 means to not handle "some" asynchronous resize requests while the WM handles ours. So - if a maximize, iconify, restore group request is enqueued we'd drop most (or some) of it? - if another asynchronous (not in the maximize, iconify, restore group) size-related request is enqueued, we'd honor it - "instead" of ours? - if a non-size-related request is in the queue we'd honor it - even it has some of our code re-resize frames? - if there's another frame we don't care about the record_asynch_buffer_change (); stuff? martin From eliz@gnu.org Tue Dec 2 12:05:43 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-9.4 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 2 Dec 2008 20:05:43 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB2K5bJh017119 for ; Tue, 2 Dec 2008 12:05:38 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7bV3-0004gx-02 for bug-gnu-emacs@gnu.org; Tue, 02 Dec 2008 15:05:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7bV1-0004gW-Vs for bug-gnu-emacs@gnu.org; Tue, 02 Dec 2008 15:05:36 -0500 Received: from [199.232.76.173] (port=40012 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7bV1-0004gQ-QN for bug-gnu-emacs@gnu.org; Tue, 02 Dec 2008 15:05:35 -0500 Received: from mtaout4.012.net.il ([84.95.2.10]:60450) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L7bV1-0003g6-AX for bug-gnu-emacs@gnu.org; Tue, 02 Dec 2008 15:05:35 -0500 Received: from conversion-daemon.i_mtaout4.012.net.il by i_mtaout4.012.net.il (HyperSendmail v2004.12) id <0KB900700M0XKW00@i_mtaout4.012.net.il> for bug-gnu-emacs@gnu.org; Tue, 02 Dec 2008 22:06:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.156.246]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KB9008JVMJIC590@i_mtaout4.012.net.il>; Tue, 02 Dec 2008 22:06:55 +0200 (IST) Date: Tue, 02 Dec 2008 22:04:46 +0200 From: Eli Zaretskii Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows In-reply-to: <49355A23.8030001@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics , 1348@debbugs.gnu.org Cc: grishka@gmx.de, jasonr@f2s.com, bug-gnu-emacs@gnu.org Reply-to: Eli Zaretskii Message-id: References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 > Date: Tue, 02 Dec 2008 16:54:11 +0100 > From: martin rudalics > Cc: 1348@emacsbugs.donarmstrong.com, jasonr@f2s.com > > > Below is a patch that fixes the problem on windows. > > > > As to X, it turned out that there is actually something > > similar, it calls itself "x_sync_with_move". > > > > Have fun. > > Thanks. I'm running Emacs now with your patch I'd advise against it: as Jason wrote, that patch mixes two different threads, which is asking for trouble. It'd be a pity to waste your valuable time on using and debugging incorrect code. From grishka@gmx.de Tue Dec 2 16:09:55 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.1 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 3 Dec 2008 00:09:55 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB309p7d013342 for <1348@emacsbugs.donarmstrong.com>; Tue, 2 Dec 2008 16:09:53 -0800 Received: (qmail invoked by alias); 03 Dec 2008 00:09:44 -0000 Received: from 1Cust174.tnt7.ber2.deu.da.uu.net (EHLO [149.225.150.174]) [149.225.150.174] by mail.gmx.net (mp002) with SMTP; 03 Dec 2008 01:09:44 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1+zVipHx+CzpuNqfwXPX9Q2Tuj7exkraPUYSnLpFj ubigKqpKbNVO04 Message-ID: <4935CE37.4010206@gmx.de> Date: Wed, 03 Dec 2008 01:09:27 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> In-Reply-To: <49355A23.8030001@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 martin rudalics wrote: > > Below is a patch that fixes the problem on windows. > > > > As to X, it turned out that there is actually something > > similar, it calls itself "x_sync_with_move". > > > > Have fun. > > Thanks. I'm running Emacs now with your patch and will inform you if > and when I find any problems. But please be a bit less cryptic, at > least when talking to illiterate people like me ;-) > > > + if (-100 != sd) > [....] > > + w32_read_socket(-100, 0, NULL); > > I suppose the -100 means to not handle "some" asynchronous resize > requests while the WM handles ours. So > Actually -100 doesn't mean anything except to let the "async_visible" flag alone, because otherwise no frame showed at all, for some reason. (okay, that WAS cryptic) > - if a maximize, iconify, restore group request is enqueued we'd drop > most (or some) of it? > No, nothing is dropped. > - if another asynchronous (not in the maximize, iconify, restore group) > size-related request is enqueued, we'd honor it - "instead" of ours? > There is no "instead" with a queue. What's in comes out, sooner or later. > - if a non-size-related request is in the queue we'd honor it - even it > has some of our code re-resize frames? > Sure, as always. > - if there's another frame we don't care about the > record_asynch_buffer_change (); stuff? > What buffer change? Resize doesn't change buffers, does it? Btw, here is another incarnation of the issue: http://lists.gnu.org/archive/html/help-gnu-emacs/2008-12/msg00034.html ("It doesn't work very well ...") From rudalics@gmx.at Wed Dec 3 02:19:23 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-8.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 3 Dec 2008 10:19:24 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB3AJKgI008833 for ; Wed, 3 Dec 2008 02:19:21 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7opD-0002ON-Lh for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 05:19:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7opC-0002OB-3D for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 05:19:19 -0500 Received: from [199.232.76.173] (port=50795 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7opB-0002O8-Mf for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 05:19:17 -0500 Received: from mail.gmx.net ([213.165.64.20]:50014) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L7opB-0002P5-5V for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 05:19:17 -0500 Received: (qmail invoked by alias); 03 Dec 2008 10:19:14 -0000 Received: from 62-47-52-242.adsl.highway.telekom.at (EHLO [62.47.52.242]) [62.47.52.242] by mail.gmx.net (mp002) with SMTP; 03 Dec 2008 11:19:14 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19yyCpt6fhy0EmuY+LKCLlLb9H9pP9kPaQ0zFBe+l MuMu7kFTA+yfQT Message-ID: <49365CA9.8080302@gmx.at> Date: Wed, 03 Dec 2008 11:17:13 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eli Zaretskii CC: 1348@debbugs.gnu.org, grishka@gmx.de, jasonr@f2s.com, bug-gnu-emacs@gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > I'd advise against it: as Jason wrote, that patch mixes two different > threads, which is asking for trouble. It'd be a pity to waste your > valuable time on using and debugging incorrect code. I understand. But earlier I stated that I would test proposed patches, so that's what I'm doing now. If we think that grischka's patch is wrong, we should be able to give an (at least hypothetical) example why. martin From rudalics@gmx.at Wed Dec 3 02:19:39 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 3 Dec 2008 10:19:39 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB3AJZRm008847 for <1348@emacsbugs.donarmstrong.com>; Wed, 3 Dec 2008 02:19:37 -0800 Received: (qmail invoked by alias); 03 Dec 2008 10:19:30 -0000 Received: from 62-47-52-242.adsl.highway.telekom.at (EHLO [62.47.52.242]) [62.47.52.242] by mail.gmx.net (mp004) with SMTP; 03 Dec 2008 11:19:30 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19OcHMzOcRO2NejeZATLT+god2teIzjPk7M7z6Weq et6cUJqlVsqYaT Message-ID: <49365CB8.5050800@gmx.at> Date: Wed, 03 Dec 2008 11:17:28 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> In-Reply-To: <4935CE37.4010206@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 > Actually -100 doesn't mean anything except to let the "async_visible" > flag alone, because otherwise no frame showed at all, for some reason. But your patch skips more than just the async_visible assignments. >> - if a non-size-related request is in the queue we'd honor it - even it >> has some of our code re-resize frames? >> > Sure, as always. Not really, because the current code doesn't call w32_read_socket until input gets unblocked. >> - if there's another frame we don't care about the >> record_asynch_buffer_change (); stuff? >> > What buffer change? Resize doesn't change buffers, does it? I suppose resizing a frame might do all sorts of nasty things like resizing and deleting windows within the resized frame, switching buffers, showing another menu-/tool-bar, ... martin From grishka@gmx.de Wed Dec 3 09:25:25 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.1 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 3 Dec 2008 17:25:25 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB3HPKb6022271 for <1348@emacsbugs.donarmstrong.com>; Wed, 3 Dec 2008 09:25:22 -0800 Received: (qmail invoked by alias); 03 Dec 2008 17:25:13 -0000 Received: from 1Cust219.tnt4.ber2.deu.da.uu.net (EHLO [149.225.58.219]) [149.225.58.219] by mail.gmx.net (mp052) with SMTP; 03 Dec 2008 18:25:13 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX18G5itL7HMGWoXbkFa83+AabGp55N2sh4UK8jIdI6 xekxdirt51bZKg Message-ID: <4936C0E6.9050200@gmx.de> Date: Wed, 03 Dec 2008 18:24:54 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> <49365CB8.5050800@gmx.at> In-Reply-To: <49365CB8.5050800@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 martin rudalics wrote: > > Actually -100 doesn't mean anything except to let the "async_visible" > > flag alone, because otherwise no frame showed at all, for some reason. > > But your patch skips more than just the async_visible assignments. Saved me one line to type. Anyway, I found the reason: case SIZE_MAXIMIZED: case SIZE_RESTORED: f->async_visible = 1; Basically RESTORED or MAXIMIZED don't necessarily mean visible in the windows sense. I replaced it with f->async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0; I also replaced w32_read_socket() by a less suspicious looking gobble_input (0); I'm not so into emacs internals to tell whether this is the finally ideal function to use. You might know better. > >> - if a non-size-related request is in the queue we'd honor it - even it > >> has some of our code re-resize frames? > >> > > Sure, as always. > > Not really, because the current code doesn't call w32_read_socket until > input gets unblocked. Now not sure what you meant. Probably something not good. But what? Size wrong? Events lost? Example? > >> - if there's another frame we don't care about the > >> record_asynch_buffer_change (); stuff? > >> > > What buffer change? Resize doesn't change buffers, does it? > > I suppose resizing a frame might do all sorts of nasty things like > resizing and deleting windows within the resized frame, switching > buffers, showing another menu-/tool-bar, ... Only with at least two frames? Sounds cryptic ;) > > martin > New patch: ######################################## --- w32term-old.c Mon Dec 01 17:50:28 2008 +++ w32term.c Wed Dec 03 17:39:21 2008 @@ -4533,7 +4533,7 @@ w32_read_socket (sd, expected, hold_quit case SIZE_MAXIMIZED: case SIZE_RESTORED: - f->async_visible = 1; + f->async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0; f->async_iconified = 0; /* wait_reading_process_output will notice this and update @@ -5384,6 +5384,7 @@ x_set_offset (f, xoff, yoff, change_grav 0, 0, SWP_NOZORDER | SWP_NOSIZE | SWP_NOACTIVATE); UNBLOCK_INPUT; + gobble_input (0); } @@ -5509,6 +5510,7 @@ x_set_window_size (f, change_gravity, co #endif UNBLOCK_INPUT; + gobble_input (0); } /* Mouse warping. */ ######################################## From eliz@gnu.org Wed Dec 3 10:32:53 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-9.4 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 3 Dec 2008 18:32:53 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB3IWo3B006759 for ; Wed, 3 Dec 2008 10:32:51 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7wWo-0002ia-6Q for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 13:32:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7wWn-0002i6-EV for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 13:32:49 -0500 Received: from [199.232.76.173] (port=60837 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7wWn-0002hw-6n for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 13:32:49 -0500 Received: from mtaout5.012.net.il ([84.95.2.13]:63007) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L7wWm-0007Zv-Pc for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 13:32:49 -0500 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KBB00600CQ4Q300@i_mtaout5.012.net.il> for bug-gnu-emacs@gnu.org; Wed, 03 Dec 2008 20:34:57 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.111.178]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KBB00DH8CY77WG1@i_mtaout5.012.net.il>; Wed, 03 Dec 2008 20:34:57 +0200 (IST) Date: Wed, 03 Dec 2008 20:32:50 +0200 From: Eli Zaretskii Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows In-reply-to: <49365CA9.8080302@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Cc: 1348@debbugs.gnu.org, grishka@gmx.de, jasonr@f2s.com, bug-gnu-emacs@gnu.org Reply-to: Eli Zaretskii Message-id: References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <49365CA9.8080302@gmx.at> X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 > Date: Wed, 03 Dec 2008 11:17:13 +0100 > From: martin rudalics > CC: 1348@emacsbugs.donarmstrong.com, grishka@gmx.de, jasonr@f2s.com, > bug-gnu-emacs@gnu.org > > If we think that grischka's patch is wrong, we should be able to > give an (at least hypothetical) example why. I don't see a need for giving an example for something that is so blatantly wrong: it calls one thread's code from within another. Since the Emacs input thread was written _specifically_ to overcome problems with delivering input asynchronously, it should be clear to anyone that mixing such threads is dead wrong, period. From monnier@iro.umontreal.ca Wed Dec 3 13:41:12 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.8 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 3 Dec 2008 21:41:13 +0000 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 mB3Lf9TX022820 for <1348@emacsbugs.donarmstrong.com>; Wed, 3 Dec 2008 13:41:11 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EAAaMNknO+Jkl/2dsb2JhbACBbdEEgwGBIw X-IronPort-AV: E=Sophos;i="4.33,710,1220241600"; d="scan'208";a="30613655" Received: from 206-248-153-37.dsl.teksavvy.com (HELO pastel.home) ([206.248.153.37]) by ironport2-out.teksavvy.com with ESMTP; 03 Dec 2008 16:41:04 -0500 Received: by pastel.home (Postfix, from userid 20848) id 41D458BAF; Wed, 3 Dec 2008 16:41:04 -0500 (EST) From: Stefan Monnier To: grischka Cc: 1348@debbugs.gnu.org, martin rudalics , jasonr@f2s.com Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Message-ID: References: <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> <49365CB8.5050800@gmx.at> <4936C0E6.9050200@gmx.de> Date: Wed, 03 Dec 2008 16:41:04 -0500 In-Reply-To: <4936C0E6.9050200@gmx.de> (grischka's message of "Wed, 03 Dec 2008 18:24:54 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > f-> async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0; This is an eta-expression (See http://en.wikipedia.org/wiki/Lambda_calculus#.CE.B7-conversion although it only talks about the case of eta for functions rather than for booleans), so you should probably rewrite it as f-> async_visible = IsWindowVisible(msg.msg.hwnd); -- Stefan From grishka@gmx.de Wed Dec 3 13:43:55 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.1 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 3 Dec 2008 21:43:56 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB3Lhqbp022851 for <1348@emacsbugs.donarmstrong.com>; Wed, 3 Dec 2008 13:43:53 -0800 Received: (qmail invoked by alias); 03 Dec 2008 21:43:45 -0000 Received: from 1Cust63.tnt9.ber2.deu.da.uu.net (EHLO [149.225.160.63]) [149.225.160.63] by mail.gmx.net (mp068) with SMTP; 03 Dec 2008 22:43:45 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/o1C5NZOvoHHrlfAdloK199L+r49AhSAdWo+6d2e g99N0i7xb7EgEm Message-ID: <4936FD7F.4070900@gmx.de> Date: Wed, 03 Dec 2008 22:43:27 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: eliz@gnu.org CC: 1348@debbugs.gnu.org, jasonr@f2s.com, martin rudalics Subject: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: uk5ahnm7h.fsf@gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Eli Zaretskii wrote: > I don't see a need for giving an example for something that is so > blatantly wrong: it calls one thread's code from within another. > Since the Emacs input thread was written _specifically_ to overcome > problems with delivering input asynchronously, it should be clear to > anyone that mixing such threads is dead wrong, period. Clear to anyone who? Doesn't see a need or is able to read? Actually, w32_read_socket() calls change_frame_size() at w32term:4596 which finally calls run_window_configuration_change_hook() at dispnew:6414 which runs lisp code. You will maybe agree that it makes sense to run this hook as a consequence from a lisp call to "set-frame-width". From eliz@gnu.org Wed Dec 3 20:08:12 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.5 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 4 Dec 2008 04:08:12 +0000 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB44886X024804 for <1348@emacsbugs.donarmstrong.com>; Wed, 3 Dec 2008 20:08:10 -0800 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KBC00J0030WKG00@i-mtaout6.012.net.il> for 1348@emacsbugs.donarmstrong.com; Thu, 04 Dec 2008 06:10:02 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.111.178]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KBC00EX53KOFN60@i-mtaout6.012.net.il>; Thu, 04 Dec 2008 06:10:01 +0200 (IST) Date: Thu, 04 Dec 2008 06:07:53 +0200 From: Eli Zaretskii Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows In-reply-to: <4936FD7F.4070900@gmx.de> X-012-Sender: halo1@inter.net.il To: grischka Cc: 1348@debbugs.gnu.org, jasonr@f2s.com, rudalics@gmx.at Reply-to: Eli Zaretskii Message-id: References: "uk5ahnm7h.fsf@gnu.org" <4936FD7F.4070900@gmx.de> > Date: Wed, 03 Dec 2008 22:43:27 +0100 > From: grischka > CC: 1348@emacsbugs.donarmstrong.com, jasonr@f2s.com, > martin rudalics > > You will maybe agree that it makes sense to run this hook as > a consequence from a lisp call to "set-frame-width". No, I don't agree. In Emacs, Lisp calls don't call redisplay directly. They change variables and objects that affect the next redisplay. Redisplay itself is triggered by other events. Any change that doesn't follow this pattern is wrong. From rudalics@gmx.at Thu Dec 4 10:03:13 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.8 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 4 Dec 2008 18:03:13 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB4I38En012070 for <1348@emacsbugs.donarmstrong.com>; Thu, 4 Dec 2008 10:03:10 -0800 Received: (qmail invoked by alias); 04 Dec 2008 18:03:02 -0000 Received: from 88-117-47-114.adsl.highway.telekom.at (EHLO [88.117.47.114]) [88.117.47.114] by mail.gmx.net (mp011) with SMTP; 04 Dec 2008 19:03:02 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/A9MJ7raPA+KBYyBxuWWRRLckgh+bBtPujbg/SJz qycYJcpngI4nBB Message-ID: <49381A5C.2030903@gmx.at> Date: Thu, 04 Dec 2008 18:58:52 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: grischka CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> <49365CB8.5050800@gmx.at> <4936C0E6.9050200@gmx.de> In-Reply-To: <4936C0E6.9050200@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 > Now not sure what you meant. Probably something not good. > But what? Size wrong? Events lost? Example? Consider the following silly fragment: (progn (sleep-for 10) (set-frame-height nil 20)) C-x C-e it and resize the frame with the WM. The results here are not very predictable, neither with no without your patch. If you manually make the window smaller than 20 lines it gets resized after 10 secs. Otherwise it remains larger. In any case, the point is what gets processed by Emacs after the 10 seconds elapsed. >> I suppose resizing a frame might do all sorts of nasty things like >> resizing and deleting windows within the resized frame, switching >> buffers, showing another menu-/tool-bar, ... > > Only with at least two frames? Sounds cryptic ;) With one frame. Emacs reacts to frame resizing requests by adjusting the windows within the frame accordingly. If a window gets too small, Emacs has to delete one (note that Emacs implements a tiling window manager within each frame). Eventually, all that remains is the menubar or, if there's none, just the title line. And, deleting a window may change the menubar because another buffer may become current. martin From rudalics@gmx.at Thu Dec 4 10:03:20 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-6.8 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 4 Dec 2008 18:03:20 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB4I3Gab012074 for <1348@emacsbugs.donarmstrong.com>; Thu, 4 Dec 2008 10:03:18 -0800 Received: (qmail invoked by alias); 04 Dec 2008 18:03:11 -0000 Received: from 88-117-47-114.adsl.highway.telekom.at (EHLO [88.117.47.114]) [88.117.47.114] by mail.gmx.net (mp030) with SMTP; 04 Dec 2008 19:03:11 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18s0UF7CkYsfUbsZijSYtEu5zLW3wARaShHuVh+lG N1R/CSZsa7L0ET Message-ID: <49381AB9.3030602@gmx.at> Date: Thu, 04 Dec 2008 19:00:25 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eli Zaretskii CC: 1348@debbugs.gnu.org, grishka@gmx.de, jasonr@f2s.com Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <49365CA9.8080302@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 > I don't see a need for giving an example for something that is so > blatantly wrong: it calls one thread's code from within another. > Since the Emacs input thread was written _specifically_ to overcome > problems with delivering input asynchronously, it should be clear to > anyone that mixing such threads is dead wrong, period. I can only _speculate_ on how Emacs is supposed to handle a frame size change requested by a Lisp routine. (1) Calculate (and internally store) the new size and send the WM (window manager) an appropriate request. (2) Continue the calling routine with the size calculated in (1). (3) When the WM confirmation finally arrives treat it as a resize request initiated by the WM. The idea seems that the sizes calculated in (1) and the size request in (3) coincide and no further resizing is necessary thereafter. Apparently Jason changed (1) on Windows in the sense that it does not internally store the new size. So if a Lisp routine issues another resize request before (3) is handled, (1) starts calculations with the values as they were before the Lisp routine started. The request that eventually gets processed by the Windows WM is the last resize/positioning request issued by the Lisp routine, with the values valid before the Lisp routine started. Now grischka's proposal seems to wait for the WM's confirmation within (1), that is embed (3) in (1), and have (2) proceed with the values promised (or confirmed) by the WM. This apparently runs counter to the ideology that the processing of asynchronous input should not happen in certain occasions and apparently a step like (1) is one of these. So the first thing we'd have to agree upon is whether we want a function like `set-frame-height' process messages of the WM. If we don't want that, we have to find another way to make `set-frame-height' DTRT which seems non-trivial to me. If we want that, we have to decide how to synchronize the handling of a confirmation message with the rest of system messages arriving around that time. For this purpose, we have to determine what can be safely processed and what must be processed to ensure liveness while waiting for the confirmation. (I suppose that's what Jason's "inter-thread synchronization" amounts to, though I don't understand the term "thread" in the present context - sorry. But maybe that's what ATTACH_THREADS was about.) Till we agree on something here I can test grischka's patches to know whether his approach can handle the problem at all - that is whether the confirmation gets through and is handled. martin From grishka@gmx.de Thu Dec 4 15:25:08 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.0 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1348) by emacsbugs.donarmstrong.com; 4 Dec 2008 23:25:09 +0000 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB4NP4DR000304 for <1348@emacsbugs.donarmstrong.com>; Thu, 4 Dec 2008 15:25:06 -0800 Received: (qmail invoked by alias); 04 Dec 2008 23:24:58 -0000 Received: from 1Cust130.tnt3.ber2.deu.da.uu.net (EHLO [149.225.56.130]) [149.225.56.130] by mail.gmx.net (mp009) with SMTP; 05 Dec 2008 00:24:58 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX18DnBZpsSwDCD9q6Qun1c1bns17u6NgGqEkIgadyP A7HCVdwTy/uwVp Message-ID: <493866B8.6050408@gmx.de> Date: Fri, 05 Dec 2008 00:24:40 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: jasonr@f2s.com, 1348@debbugs.gnu.org Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: 4922BD1F.2080604@gmx.at <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> <49365CB8.5050800@gmx.at> <4936C0E6.9050200@gmx.de> <49381A5C.2030903@gmx.at> In-Reply-To: <49381A5C.2030903@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 martin rudalics wrote: > > Now not sure what you meant. Probably something not good. > > But what? Size wrong? Events lost? Example? > > Consider the following silly fragment: > > (progn > (sleep-for 10) > (set-frame-height nil 20)) > > C-x C-e it and resize the frame with the WM. The results here are not > very predictable, neither with no without your patch. If you manually > make the window smaller than 20 lines it gets resized after 10 secs. > Otherwise it remains larger. In any case, the point is what gets > processed by Emacs after the 10 seconds elapsed. Okay, I could reproduce this (although not the larger/smaller part) One/The reason is in Fset_frame_height() at frame.c:2695 if (XINT (lines) != FRAME_LINES (f)) x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines)); Basically if the window has 20 lines on enter-freeze, then our thing wouldn't even start, because between "sleep-for" and "set-frame-height" there is nothing to read the WM_SIZE messages from the mouse-dragging. Works for me if I disable this line: // if (XINT (lines) ... It is a natural problem which happens only too often with such "micro-optimizations". Next case ? From eliz@gnu.org Thu Dec 4 22:20:07 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-9.4 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Dec 2008 06:20:08 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB56K4w3020479 for ; Thu, 4 Dec 2008 22:20:05 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8U2m-0003fb-3M for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 01:20:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8U2k-0003eD-7n for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 01:20:03 -0500 Received: from [199.232.76.173] (port=53385 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8U2j-0003e0-Up for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 01:20:01 -0500 Received: from mtaout1.012.net.il ([84.95.2.1]:12637) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L8U2j-0001RG-K3 for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 01:20:01 -0500 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KBE00M0042GF600@i-mtaout1.012.net.il> for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 08:22:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.111.178]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KBE00MV04D0ZJA0@i-mtaout1.012.net.il>; Fri, 05 Dec 2008 08:22:13 +0200 (IST) Date: Fri, 05 Dec 2008 08:20:04 +0200 From: Eli Zaretskii Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows In-reply-to: <493866B8.6050408@gmx.de> X-012-Sender: halo1@inter.net.il To: grischka , 1348@debbugs.gnu.org Cc: rudalics@gmx.at, jasonr@f2s.com, bug-gnu-emacs@gnu.org Reply-to: Eli Zaretskii Message-id: References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> <49365CB8.5050800@gmx.at> <4936C0E6.9050200@gmx.de> <49381A5C.2030903@gmx.at> <493866B8.6050408@gmx.de> X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 > Date: Fri, 05 Dec 2008 00:24:40 +0100 > From: grischka > Cc: 1348@emacsbugs.donarmstrong.com, jasonr@f2s.com > > if (XINT (lines) != FRAME_LINES (f)) > x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines)); > > Basically if the window has 20 lines on enter-freeze, then our > thing wouldn't even start, because between "sleep-for" and > "set-frame-height" there is nothing to read the WM_SIZE messages > from the mouse-dragging. > > Works for me if I disable this line: > // if (XINT (lines) ... > > It is a natural problem which happens only too often with > such "micro-optimizations". This is not a "micro-optimization". Emacs deliberately avoids unnecessary calls to display routines, because frequent redisplay that doesn't really change anything causes flickering that is quite annoying. Therefore, your "solution" is wrong. From monnier@iro.umontreal.ca Fri Dec 5 07:58:44 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.8 required=4.0 tests=AWL,BAYES_00,FOURLA, HAS_BUG_NUMBER,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Dec 2008 15:58:45 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB5FwfFD004393 for ; Fri, 5 Dec 2008 07:58:43 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8d4j-0000bf-Ki for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 10:58:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8d4h-0000bI-VX for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 10:58:41 -0500 Received: from [199.232.76.173] (port=59101 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8d4h-0000bF-T9 for bug-gnu-emacs@gnu.org; Fri, 05 Dec 2008 10:58:39 -0500 Received: from ironport2-out.pppoe.ca ([206.248.154.182]:32007 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L8d4g-0007vE-LU; Fri, 05 Dec 2008 10:58:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoEABveOEnO+Jkl/2dsb2JhbACBbc1xgwWBJg X-IronPort-AV: E=Sophos;i="4.33,721,1220241600"; d="scan'208";a="30696770" Received: from 206-248-153-37.dsl.teksavvy.com (HELO pastel.home) ([206.248.153.37]) by ironport2-out.teksavvy.com with ESMTP; 05 Dec 2008 10:58:37 -0500 Received: by pastel.home (Postfix, from userid 20848) id AC8D984A9; Fri, 5 Dec 2008 10:58:37 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Cc: 1348@debbugs.gnu.org, grischka , bug-gnu-emacs@gnu.org, jasonr@f2s.com Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Message-ID: References: <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <4935CE37.4010206@gmx.de> <49365CB8.5050800@gmx.at> <4936C0E6.9050200@gmx.de> <49381A5C.2030903@gmx.at> <493866B8.6050408@gmx.de> Date: Fri, 05 Dec 2008 10:58:37 -0500 In-Reply-To: (Eli Zaretskii's message of "Fri, 05 Dec 2008 08:20:04 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. >> if (XINT (lines) != FRAME_LINES (f)) >> x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines)); >> >> Basically if the window has 20 lines on enter-freeze, then our >> thing wouldn't even start, because between "sleep-for" and >> "set-frame-height" there is nothing to read the WM_SIZE messages >> from the mouse-dragging. >> >> Works for me if I disable this line: >> // if (XINT (lines) ... >> >> It is a natural problem which happens only too often with >> such "micro-optimizations". > This is not a "micro-optimization". Emacs deliberately avoids > unnecessary calls to display routines, because frequent redisplay that > doesn't really change anything causes flickering that is quite > annoying. Therefore, your "solution" is wrong. Maybe it's not the right fix, but since it appears to fix the original problem, we should look into why it fixes the problem. Stefan From grishka@gmx.de Tue Dec 16 09:12:16 2008 Received: (at 1348) by emacsbugs.donarmstrong.com; 16 Dec 2008 17:12:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) 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.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,THUNDERB autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mBGHCCcC024811 for <1348@emacsbugs.donarmstrong.com>; Tue, 16 Dec 2008 09:12:14 -0800 Received: (qmail invoked by alias); 16 Dec 2008 17:12:05 -0000 Received: from 1Cust139.tnt6.ber2.deu.da.uu.net (EHLO [149.225.88.139]) [149.225.88.139] by mail.gmx.net (mp011) with SMTP; 16 Dec 2008 18:12:05 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1+tYl82SLCtziI5TDSQaU8D5muggGlLjBumsHiI7Z qggR6Mh3BB3a6R Message-ID: <4947E14E.7080601@gmx.de> Date: Tue, 16 Dec 2008 18:11:42 +0100 From: grischka User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin rudalics CC: Eli Zaretskii , 1348@debbugs.gnu.org, jasonr@f2s.com Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <49365CA9.8080302@gmx.at> <49381AB9.3030602@gmx.at> In-Reply-To: <49381AB9.3030602@gmx.at> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 martin rudalics wrote: > ... > If we want that, we have to decide how to synchronize the handling of a > confirmation message with the rest of system messages arriving around > that time. For this purpose, we have to determine what can be safely > processed and what must be processed to ensure liveness while waiting > for the confirmation. (I suppose that's what Jason's "inter-thread > synchronization" amounts to, though I don't understand the term "thread" > in the present context - sorry. But maybe that's what ATTACH_THREADS > was about.) Note that the suggested patch handles all that perfectly well. Doing anything in addition like what you mention above is unnecessary, in fact likely contra-productive. Instead I'd suggest to look into the X and GTK part of this issue (frame-positioning/resizing that is) now. On that platforms it is still broken in several aspects and considerations are spent much more usefully there. Then after having fixed X and GTK you can still come back to Windows and try to do better than the suggested 3-line patch. Maybe you can, who knows. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 21 14:02:11 2014 Received: (at 1348-done) by debbugs.gnu.org; 21 Sep 2014 18:02:11 +0000 Received: from localhost ([127.0.0.1]:47650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XVlSc-00056p-NI for submit@debbugs.gnu.org; Sun, 21 Sep 2014 14:02:11 -0400 Received: from mout.gmx.net ([212.227.17.20]:55869) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XVlSa-00056g-80 for 1348-done@debbugs.gnu.org; Sun, 21 Sep 2014 14:02:09 -0400 Received: from [93.82.76.172] ([93.82.76.172]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LgdBZ-1Y899O0fCf-00o2bk for <1348-done@debbugs.gnu.org>; Sun, 21 Sep 2014 20:02:07 +0200 Message-ID: <541F129D.3000402@gmx.at> Date: Sun, 21 Sep 2014 20:02:05 +0200 From: martin rudalics MIME-Version: 1.0 To: 1348-done@debbugs.gnu.org Subject: Re: set-frame-width and set-frame-position seem buggy on at least MSWindows Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sFxCRK6rzeAnVRuenQ8JvDFyqX2HXNwsH2e/kuzHd/2ZJwdTQUi fgSNVMfkpPU66kHONhEfZ87KPAdeI4ZhM78RG+lg+cYofwnJM00rmrw4U2OK8l2BtrKvxoW 5idZbXggsumxOL72eWdSwMsy2qSiIWIu6uNP+GDTMqj9poqE8nBjGtf1MzV1rps97NRZBJW uaahhgJhKsZGHw3W67LaA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 1348-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > When migrating to Emacs 22.3.1 on microsoft windows, the following > lines in my .emacs file do not behave as expected: > > (set-frame-position (selected-frame) 0 0) > (sleep-for 2) ; not originally in my .emacs -- testing only > (set-frame-width (selected-frame) 150) > (sleep-for 2) > (set-frame-height (selected-frame) 55) > (sleep-for 2)) > > This used to leave me with a 150 X 55 frame located at 0,0 on my > display but it instead now leaves me with a default size frame still > located at 0,0 as expected. Please note that when I said M-x ielm and > pasted in the set-frame-width and -height lines as above after emacs > finished loading they did as I expected, ie. resized the frame > without problem. Should work in emacs-24 as intended. Closing this bug. Thanks, martin From unknown Sat Aug 09 15:51:54 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 20 Oct 2014 11:24:04 +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