GNU bug report logs -
#37415
Asserting failure setting frame parameters to non-fixnum values in early-init.el
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 24 Sep 2019 10:41:58 +0300
with message-id <83y2yennsp.fsf <at> gnu.org>
and subject line Re: bug#37415: Asserting failure setting frame parameters to non-fixnum values in early-init.el
has caused the debbugs.gnu.org bug report #37415,
regarding Asserting failure setting frame parameters to non-fixnum values in early-init.el
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
37415: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37415
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
This is with an empty init.el, and the following early-init.el:
D:\...\.emacs.d> type early-init.el
(setq default-frame-alist '((left . (+ 0))))
D:\...\.emacs.d> emacs.exe
lisp.h:1231: Emacs fatal error: assertion failed: FIXNUMP (a)
Setting the same value on init.el works.
In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32)
of 2019-09-16 built on ODIEFAST
Repository revision: b3e4b50578778e03327b049f7a595981bfbf3713
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.18362
System Description: Microsoft Windows 10 Home (v10.0.1903.18362.356)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --prefix=/d/Devel/emacs/repo/trunk --with-modules
--enable-checking=yes
--enable-locallisppath=%emacs_dir%/../site-lisp:%emacs_dir%/share/emacs/@VER@
/site-lisp:%emacs_dir%/share/emacs/site-lisp
'CFLAGS=-Og -ggdb3'
PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'
[Message part 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
> Cc: lekktu <at> gmail.com, 37415 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 24 Sep 2019 08:45:43 +0200
>
> >> 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?
>
> Size hints. In particular the 'user-position' frame parameter.
Well, that has been working for far too long to be bothered now, I
think.
> > 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 but don't bother. Better leave a short note in a comment
> explaining how this is supposed to behave.
Done.
> On a related note: Do you have any ideas what the window_prompting
> argument of w32_window is or was for?
It's unused, and was unused since the initial revision of that
function. I think it's there just to keep the signature compatible
with that of x_window (which itself only keeps that compatibility in
toolkit versions).
This bug report was last modified 5 years and 246 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.