GNU bug report logs - #31745
default-frame-alist sizing parameters set in ~/.emacs are not applied correctly

Previous Next

Full log

Message #76 received at 31745 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 31745 <at> debbugs.gnu.org,
 刘力铭 <mark.liu.li.ming <at> foxmail.com>
Subject: Re: bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's
 bug whenwindow-system
Date: Thu, 28 Jun 2018 16:15:59 +0200

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> 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:

[Selection_029.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.