From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#37415: Asserting failure setting frame parameters to non-fixnum values in early-init.el Date: Mon, 23 Sep 2019 19:35:35 +0300 Message-ID: <83ef07otrc.fsf@gnu.org> References: <83v9tqvrm7.fsf@gnu.org> <9aae1b2e-bb5f-8634-5501-9aaff9f51266@gmx.at> <83imppvl9r.fsf@gnu.org> <14d4a455-254e-fdc2-0b64-791cfb0f7724@gmx.at> <83o8zgtlvq.fsf@gnu.org> <0936d492-c2bc-d4d3-7fcf-272d0fdbe087@gmx.at> <83a7ayss4b.fsf@gnu.org> <7b896377-d546-b428-adba-797ec988c4fa@gmx.at> <83r24aqadz.fsf@gnu.org> <83ftkprfzx.fsf@gnu.org> <83y2ygp9hz.fsf@gnu.org> <83pnjsp50y.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="12905"; mail-complaints-to="usenet@blaine.gmane.org" Cc: lekktu@gmail.com, 37415@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 23 18:42:21 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iCRPp-0003Gw-AG for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Sep 2019 18:42:21 +0200 Original-Received: from localhost ([::1]:59580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iCRPn-0007mR-Gh for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Sep 2019 12:42:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33499) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iCRJk-0002WU-9h for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 12:36:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iCRJi-0002Lf-LG for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 12:36:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56317) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iCRJi-0002LX-Hh for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 12:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iCRJi-00037u-Cs for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2019 12:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Sep 2019 16:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37415 X-GNU-PR-Package: emacs Original-Received: via spool by 37415-submit@debbugs.gnu.org id=B37415.156925655211994 (code B ref 37415); Mon, 23 Sep 2019 16:36:02 +0000 Original-Received: (at 37415) by debbugs.gnu.org; 23 Sep 2019 16:35:52 +0000 Original-Received: from localhost ([127.0.0.1]:36905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iCRJY-00037O-7f for submit@debbugs.gnu.org; Mon, 23 Sep 2019 12:35:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iCRJV-000377-Rx for 37415@debbugs.gnu.org; Mon, 23 Sep 2019 12:35:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iCRJP-0002G6-FH; Mon, 23 Sep 2019 12:35:44 -0400 Original-Received: from [176.228.60.248] (port=3536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iCRJO-0001Od-04; Mon, 23 Sep 2019 12:35:42 -0400 In-reply-to: (message from martin rudalics on Mon, 23 Sep 2019 09:32:23 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:167016 Archived-At: > Cc: lekktu@gmail.com, 37415@debbugs.gnu.org > From: martin rudalics > Date: Mon, 23 Sep 2019 09:32:23 +0200 > > > If it's fragile, then we must take a look at gui_figure_window_size, I > > think. It should handle all those cases which you are afraid of. > > What bothers me more is that we base the Windows code on a concept > that it can neither understand nor control. Which concept is that? > > I prefer using the hint flags as the indicator because that explicitly > > tells us we can use f->top and f->left. > > But we do not use them in my_create_window with your patch. my_create_window just prepares the coordinates for w32_createwindow, and the latter does use f->top_pos and f->left_pos when appropriate. > We just use left and top which are zero when a notation like (- 100) > is used. When such a notation is used, gui_figure_window_size will have already computed the coordinates in f->top_pos and f->left_pos, and set the hint flags, before my_create_window is called. Which is why we don't need to do anything in my_create_window when the hint flags are set. But if you will feel safer with the alternative patch below, I don't mind: diff --git a/src/w32fns.c b/src/w32fns.c index 34abd02..4581015 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -5421,20 +5421,33 @@ my_create_window (struct frame * f) Lisp_Object left, top; struct w32_display_info *dpyinfo = &one_w32_display_info; - /* When called with RES_TYPE_NUMBER, gui_display_get_arg will return - zero for anything that is not a number and is not Qunbound. */ - left = gui_display_get_arg (dpyinfo, Qnil, Qleft, "left", "Left", - RES_TYPE_NUMBER); - top = gui_display_get_arg (dpyinfo, Qnil, Qtop, "top", "Top", - RES_TYPE_NUMBER); - if (EQ (left, Qunbound)) - coords[0] = CW_USEDEFAULT; - else - coords[0] = XFIXNUM (left); - if (EQ (top, Qunbound)) - coords[1] = CW_USEDEFAULT; + if (!(f->size_hint_flags & USPosition || f->size_hint_flags & PPosition)) + { + /* When called with RES_TYPE_NUMBER, and there's no 'top' or + 'left' parameters in the frame's parameter alist, + gui_display_get_arg will return zero for anything that is + neither a number nor Qunbound. If frame parameter alist does + have 'left' or 'top', they are interpreted by + gui_figure_window_size, which was already called, and which + sets f->size_hint_flags. */ + left = gui_display_get_arg (dpyinfo, Qnil, Qleft, "left", "Left", + RES_TYPE_NUMBER); + top = gui_display_get_arg (dpyinfo, Qnil, Qtop, "top", "Top", + RES_TYPE_NUMBER); + if (EQ (left, Qunbound)) + coords[0] = CW_USEDEFAULT; + else + coords[0] = XFIXNUM (left); + if (EQ (top, Qunbound)) + coords[1] = CW_USEDEFAULT; + else + coords[1] = XFIXNUM (top); + } else - coords[1] = XFIXNUM (top); + { + coords[0] = f->left_pos; + coords[1] = f->top_pos; + } if (!PostThreadMessage (dwWindowsThreadId, WM_EMACS_CREATEWINDOW, (WPARAM)f, (LPARAM)coords)) The 'else' block is redundant, because when the hint flags are set, w32_createwindow will disregard coords[]. But it does no harm, so if you are more comfortable with it, fine. Thanks.