martin rudalics writes: >>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56))) >>> >> >> That does nothing, but the following resizes the frame: >> >> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48))) >> >> And has done the right thing: >> >> (frame-parameter nil 'height) => 48 >> (frame-parameter nil 'width) => 100 > > Looks like the missing link. If your window manager refuses to resize > the frame, it probably decides that it would not fit on the screen. > Please increase separately from 48 and 100 till you find the > problematic value and compare it against your workspace size. > 130x56 fits on my screen fine, so Iʼm not sure thatʼs what's happening. Once the initial frame has been created I can modify its size without any problems. >> Good: >> >> (frame-pixel-width) => 1849 >> (frame-pixel-height) => 1680 > > This looks like our bad. Somehow we decide that the window manager > will comply and set the values we asked for. Do these values also > occur with emacs -Q followed by > > (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56))) > > I suppose not since otherwise you would have probably told me so. Yes, I get the same values for frame-pixel-{width,height} if I modify the frame size after startup. Thatʼs not surprising to me, the issue is somewhere during the setup of the initial frame. >>> Can you try with another toolkit or X without any toolkit so we can >>> tell whether this is GTK or window manager specific? >> >> --with-x-toolkit={none,lucid} both work fine (although you can see the >> modeline of the frame appear as if it were 80x36, and then it >> resizes correctly to 130x56). > > This implies that the bug is somewhere in our interception of X > messages and letting GTK not see them (otherwise GTK should have > reported an error). However, it contradicts the assumption that the > window manager refuses to resize our frame since otherwise it would > have done so for the Lucid build too. Rather it seems that GTK itself > decides that the frame is too large to fit on the screen. But without > signalling an error? Youʼre right that the frame is not resized the way we requested, but it doesnʼt seem to be because GTK thinks itʼs too big, since eg src/emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width . 79) (height . 35)))" can result in emacs thinking the frame is *smaller* than what's actually displayed, so the modeline is drawn too high, and the minibuffer has empty lines drawn underneath it. Screenshot: