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: Sat, 21 Sep 2019 12:14:16 +0300 Message-ID: <83r24aqadz.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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="129546"; 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 Sat Sep 21 11:15:19 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 1iBbU5-000XZ3-Mo for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Sep 2019 11:15:17 +0200 Original-Received: from localhost ([::1]:40416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBbU4-0002oU-CC for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Sep 2019 05:15:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40088) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBbTr-0002kC-UV for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 05:15:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iBbTq-00011p-It for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 05:15:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50295) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iBbTq-00011j-EG for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 05:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iBbTq-0002Yv-7E for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 05:15: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: Sat, 21 Sep 2019 09:15: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.15690572569777 (code B ref 37415); Sat, 21 Sep 2019 09:15:02 +0000 Original-Received: (at 37415) by debbugs.gnu.org; 21 Sep 2019 09:14:16 +0000 Original-Received: from localhost ([127.0.0.1]:59116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBbT5-0002Xd-OA for submit@debbugs.gnu.org; Sat, 21 Sep 2019 05:14:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBbT4-0002XQ-Vh for 37415@debbugs.gnu.org; Sat, 21 Sep 2019 05:14:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iBbSz-0000fu-Mk; Sat, 21 Sep 2019 05:14:09 -0400 Original-Received: from [176.228.60.248] (port=3970 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iBbSz-00035x-23; Sat, 21 Sep 2019 05:14:09 -0400 In-reply-to: <7b896377-d546-b428-adba-797ec988c4fa@gmx.at> (message from martin rudalics on Sat, 21 Sep 2019 10:51:49 +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:166858 Archived-At: > Cc: lekktu@gmail.com, 37415@debbugs.gnu.org > From: martin rudalics > Date: Sat, 21 Sep 2019 10:51:49 +0200 > > I get a similar backtrace when I try the more reasonable > > (setq default-frame-alist '((left . (- 100)))) > > in my early-init.el (more reasonable because, after all, > > (setq default-frame-alist '((left . (+ 0)))) > > is equivalent to > > (setq default-frame-alist '((left . 0))) > > which _can_ be handled from within early-init.el). Do we agree so > far? If so, then obviously > > if (EQ (left, Qunbound)) > coords[0] = CW_USEDEFAULT; > else > coords[0] = XFIXNUM (left); > > will choke when 'left' is something like '(+ 0)' or '(- 100)' since > neither of these pass the > > eassert (FIXNUMP (a)) > > check we have in XFIXNUM. Still agreed? Then doing something like > > if (FIXNUMP (left)) > coords[0] = XFIXNUM (left); > else > coords[0] = CW_USEDEFAULT; > > should fix the assertion failure if my poor understanding of C doesn't > let me down completely (the 'top' parameter needing a similar fix). > Does that reasoning still make sense to you? > > And finally, with the sole evidence of my poor eyesight, > > (setq default-frame-alist '((left . (- 100)))) > > seems to work here too, despite of the fact that for the first frame > the defaults are used. Maybe you can try to verify (I attach the > patch for easier use this time). Thanks, but I probably should have explain the nature of my confusion better (and would have done that, should I know you will act upon it so seriously). Sorry about that. Here's what confused me in this problem: . the FIXNUMP assertion is probably there for a reason; what is that reason? . how come we don't hit this assertion when the same expression is in the init file, only in the early-init file? . why doesn't the X build hit the same assertion in the same scenario? I'm probably missing something because I don't find answers to these questions anywhere in what you wrote. I do understand the "mechanics" of the patch, I just cannot convince myself it's the right fix, without being able to answer these questions, and then assess the fix with that knowledge in hand. Which shouldn't prevent you from installing it, of course: I don't have to understand everything in what's going on in Emacs development. > So do you still think that we should signal an error? A red herring: I only proposed to signal an error if we cannot find a better solution for this use case.