GNU bug report logs -
#31745
default-frame-alist sizing parameters set in ~/.emacs are not applied correctly
Previous Next
Full log
View this message in rfc822 format
> 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.
Maybe it does not fit with the initial window position chosen by the
window manager.
> Thatʼs not surprising to me, the issue
> is somewhere during the setup of the initial frame.
Window managers can be more picky to make sure a new frame fits on the
screen. For an already existing frame they usually accept that it
moves off-screen. Can you position any other application's first
window off-screen?
> 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:
If you continue to work with this frame without (implicitly)
triggering a frame resize, does Emacs keep on thinking so forever?
Does the buggy behavior trigger also when you do not set the 'left'
and 'top' parameters, that is, if you purely resize the frame and not
move it at the same time? If so, we maybe should try to use
gdk_window_move_resize or whatever there is now. ISTR that I tried it
once and it seemed to work but dropped the idea later because I had
difficulties figuring out a suitable interface.
Also, does setting 'x-gtk-use-window-move' change anything? It could
conceptually, for GTK 3.18.
martin
This bug report was last modified 3 years and 53 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.