GNU bug report logs -
#76935
31.0.50; New frame ignores default-frame-alist
Previous Next
To reply to this bug, email your comments to 76935 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Tue, 11 Mar 2025 09:14:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 11 Mar 2025 09:14:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Dear all,
on Emacs master (see below for details), `default-frame-alist' does
not seem to work any more. From emacs -Q, new frames (C-x 5 2)
appear in small windows (dimensions are shown as 15x7 when I click
on a window corner for resizing).
After executing the following (from the doc string of
`default-frame-alist'), nothing changes when creating new frames,
new windows are still at 15x7:
(setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
Not sure when this is relevant: On the command line, I see the
following message when creating new frames and when moving focus
into them:
(emacs:20227): Gtk-CRITICAL **: 10:05:43.824: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
Best wishes,
Jens
In GNU Emacs 31.0.50 (build 14, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0) of 2025-03-10 built on D-3170L03
Repository revision: 7a72589847107f26d0ebdc22f9cfa61962d02af4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302006
System Description: Ubuntu 24.04.2 LTS
Configured using:
'configure --with-imagemagick'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT
MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM
XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug lisp-mnt message mailcap
yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache
epa derived epg rfc6068 epg-config gnus-util text-property-search
time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)
Memory information:
((conses 16 67175 12991) (symbols 48 6827 2) (strings 32 17251 2527)
(string-bytes 1 549419) (vectors 16 10683)
(vector-slots 8 149522 8428) (floats 8 23 3) (intervals 56 283 26)
(buffers 992 13))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Tue, 11 Mar 2025 13:30:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76935 <at> debbugs.gnu.org (full text, mbox):
> From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
> Date: Tue, 11 Mar 2025 10:12:47 +0100
>
> on Emacs master (see below for details), `default-frame-alist' does
> not seem to work any more. From emacs -Q, new frames (C-x 5 2)
> appear in small windows (dimensions are shown as 15x7 when I click
> on a window corner for resizing).
>
> After executing the following (from the doc string of
> `default-frame-alist'), nothing changes when creating new frames,
> new windows are still at 15x7:
>
> (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
I cannot reproduce this. Maybe this is specific to GTK?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Tue, 11 Mar 2025 14:07:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 76935 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-11, Eli Zaretskii wrote:
>> From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
>> Date: Tue, 11 Mar 2025 10:12:47 +0100
>>
>> on Emacs master (see below for details), `default-frame-alist' does
>> not seem to work any more. From emacs -Q, new frames (C-x 5 2)
>> appear in small windows (dimensions are shown as 15x7 when I click
>> on a window corner for resizing).
>>
>> After executing the following (from the doc string of
>> `default-frame-alist'), nothing changes when creating new frames,
>> new windows are still at 15x7:
>>
>> (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
>
> I cannot reproduce this. Maybe this is specific to GTK?
Indeed. With "./configure --with-x-toolkit=lucid" the problem does
not arise.
Best wishes,
Jens
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Tue, 11 Mar 2025 17:09:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 76935 <at> debbugs.gnu.org (full text, mbox):
> From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
> CC: <76935 <at> debbugs.gnu.org>
> Date: Tue, 11 Mar 2025 15:06:34 +0100
>
> On 2025-03-11, Eli Zaretskii wrote:
>
> >> From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
> >> Date: Tue, 11 Mar 2025 10:12:47 +0100
> >>
> >> on Emacs master (see below for details), `default-frame-alist' does
> >> not seem to work any more. From emacs -Q, new frames (C-x 5 2)
> >> appear in small windows (dimensions are shown as 15x7 when I click
> >> on a window corner for resizing).
> >>
> >> After executing the following (from the doc string of
> >> `default-frame-alist'), nothing changes when creating new frames,
> >> new windows are still at 15x7:
> >>
> >> (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
> >
> > I cannot reproduce this. Maybe this is specific to GTK?
>
> Indeed. With "./configure --with-x-toolkit=lucid" the problem does
> not arise.
Martin and Po Lu, any ideas what could cause this? Some recent
changes, perhaps?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Tue, 11 Mar 2025 17:52:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76935 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-03-11, Eli Zaretskii wrote:
>> From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
>> CC: <76935 <at> debbugs.gnu.org>
>> Date: Tue, 11 Mar 2025 15:06:34 +0100
>>
>> On 2025-03-11, Eli Zaretskii wrote:
>>
>> >> From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
>> >> Date: Tue, 11 Mar 2025 10:12:47 +0100
>> >>
>> >> on Emacs master (see below for details), `default-frame-alist' does
>> >> not seem to work any more. From emacs -Q, new frames (C-x 5 2)
>> >> appear in small windows (dimensions are shown as 15x7 when I click
>> >> on a window corner for resizing).
>> >>
>> >> After executing the following (from the doc string of
>> >> `default-frame-alist'), nothing changes when creating new frames,
>> >> new windows are still at 15x7:
>> >>
>> >> (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
>> >
>> > I cannot reproduce this. Maybe this is specific to GTK?
>>
>> Indeed. With "./configure --with-x-toolkit=lucid" the problem does
>> not arise.
>
> Martin and Po Lu, any ideas what could cause this? Some recent
> changes, perhaps?
One additional note: I did not only update Emacs but at the same
time I updated Ubuntu from 20.04 to 24.04.
Best wishes,
Jens
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Tue, 11 Mar 2025 18:45:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 76935 <at> debbugs.gnu.org (full text, mbox):
>>>> (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
I doubt it would change anything but why do you set 'menu-bar-lines'?
>> With "./configure --with-x-toolkit=lucid" the problem does
>> not arise.
Is this with the GNOME desktop and the mutter window manager? If so, it
sounds like Bug#73244 and Bug#72986. People seem to work around it by
setting the frame size once more in 'after-make-frame-functions'
sometimes even using a timer. BTW, does the initial frame have
reasonable size?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Wed, 12 Mar 2025 08:40:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 76935 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-03-11, martin rudalics wrote:
>>>>> (setq default-frame-alist '((width . 80) (height . 55) (menu-bar-lines . 1)))
>
> I doubt it would change anything but why do you set 'menu-bar-lines'?
No particular reason, I just copied from the doc string.
Correct, its presence or absence does not change anything.
>>> With "./configure --with-x-toolkit=lucid" the problem does
>>> not arise.
>
> Is this with the GNOME desktop and the mutter window manager?
I did not change the default. My display manager is gdm3 with
Xwayland. So, I guess: Yes. (I also see a process
/usr/libexec/mutter-x11-frames.)
> If so, it
> sounds like Bug#73244 and Bug#72986. People seem to work around it by
> setting the frame size once more in 'after-make-frame-functions'
> sometimes even using a timer. BTW, does the initial frame have
> reasonable size?
Ah, yes, this seems to be Bug#73244. In fact, the dimensions from
the doc string do not work:
(defun resize-me (frame)
(set-frame-size frame 80 55))
(add-hook 'after-make-frame-functions 'resize-me)
I still get small frames/windows.
Using (set-frame-size frame 80 54) does work, though.
Yes, the initial frame is of reasonable size.
Best wishes,
Jens
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Wed, 12 Mar 2025 09:49:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 76935 <at> debbugs.gnu.org (full text, mbox):
> Ah, yes, this seems to be Bug#73244. In fact, the dimensions from
> the doc string do not work:
But that was about specifying the frame size in .Xresources and below
you say that "the initial frame is of reasonable size". Can you try
setting the size in .Xresources?
> (defun resize-me (frame)
> (set-frame-size frame 80 55))
>
> (add-hook 'after-make-frame-functions 'resize-me)
>
> I still get small frames/windows.
>
> Using (set-frame-size frame 80 54) does work, though.
Remarkable. Can you try with a few other sizes? And what happens when
you use the "54" in 'default-frame-alist'?
> Yes, the initial frame is of reasonable size.
Can you move the 'default-frame-alist' setting to an early-init.el file
to find out whether it affects the initial size then?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76935; Package
emacs.
(Wed, 12 Mar 2025 16:39:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76935 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-12, martin rudalics wrote:
>> Ah, yes, this seems to be Bug#73244. In fact, the dimensions from
>> the doc string do not work:
>
> But that was about specifying the frame size in .Xresources and below
> you say that "the initial frame is of reasonable size". Can you try
> setting the size in .Xresources?
Maybe I’m not doing that correctly but the following line in
~/.Xresources does not have an effect (xrdb -query shows the
setting, though; using “.” instead “*” does not work either):
Emacs*geometry: 80x40+0+0
>> (defun resize-me (frame)
>> (set-frame-size frame 80 55))
>>
>> (add-hook 'after-make-frame-functions 'resize-me)
>>
>> I still get small frames/windows.
>>
>> Using (set-frame-size frame 80 54) does work, though.
>
> Remarkable. Can you try with a few other sizes?
Hmm. I cannot reproduce the issue with “80 55” any longer. Will
try again tomorrow. If I find something interesting I will report
back.
> And what happens when you use the "54" in 'default-frame-alist'?
The new frame is still small.
>> Yes, the initial frame is of reasonable size.
>
> Can you move the 'default-frame-alist' setting to an early-init.el file
> to find out whether it affects the initial size then?
Yes, that changes the initial frame (but it also does so in
~/.emacs). Subsequent frames are still small, though.
Best wishes,
Jens
This bug report was last modified 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.