GNU bug report logs - #46827
Broken initial size of GTK3 frame

Previous Next

Package: emacs;

Reported by: martin rudalics <rudalics <at> gmx.at>

Date: Sun, 28 Feb 2021 09:32:01 UTC

Severity: normal

Tags: fixed

Fixed in version 28.1

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46827 <at> debbugs.gnu.org
Subject: Re: bug#46827: Broken initial size of GTK3 frame
Date: Sun, 28 Feb 2021 20:09:16 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 28 Feb 2021 10:31:30 +0100
> 
> With a GTK3 build I start Emacs with the following initial file
> contents:
> 
> (customize-set-variable
>   'default-frame-alist
>   '((cursor-color . "red3")
>     (width . 80)
>     (height . 32)))
> 
> Here this results in a frame that is 36 lines high, has a root window of
> 31 lines and a minibuffer window of 1 line.  The remaining four lines at
> the bottom of the frame are (more or less) empty.
> 
> I traced this behavior back to
> 
> Fix redisplay performance problems with some fonts
> * src/font.c (font_list_entities): Revert part of the changes
> introduced on Apr 2, 2014 to fix bug#17125.  It turns out having
> zero_vector in the font-cache is an important indication that
> cannot be removed.  (Bug#21028)

This is very strange, that commit was not supposed to affect frame
dimensions.

Could you please step through the relevant frame-sizing code, and see
how that zero_vector entry in the font-cache causes this problem?




This bug report was last modified 4 years and 11 days ago.

Previous Next


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