GNU bug report logs - #60585
30.0.50; global-text-scale-adjust shrinks window (was not before)

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Thu, 5 Jan 2023 22:30:02 UTC

Severity: normal

Found in version 30.0.50

Full log


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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 60585 <at> debbugs.gnu.org, rpluim <at> gmail.com
Subject: Re: bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was
 not before), was: Re: bug#52493: 29.0.50;
 Setting Inconsolata up in init.el makes default face rendered wrong
Date: Wed, 22 Feb 2023 03:42:04 +0200
On 20/02/2023 11:05, martin rudalics wrote:
>  > It becomes ever more difficult to remember the context. E.g. which
>  > operations I should do with each build before looking up this or that
>  > value.
> 
> Same here.  In fact, I think we have investigated most of what can be
> done here.  So unless someone has a better idea I'll try to come up with
> a patch that comprises most of what I sent you so far and some further
> fixes - size hints on xfwm have become off by one here and I don't yet
> know what causes it.
> 
> So as a general guideline I plan to cook up something like:
> 
> - Make the base size hints handle any irregularities caused by increment
>    hints not being integral multiples of our line/column sizes.
> 
> - Implement correct minimum size hints and make them independent from
>    the base sizes.
> 
> - Do away with our attempts to override GTK which means to get rid of
>    emacsgtkfixed.c/.h.

Sounds promising! Especially the last part.

> All this will take some time and testing.
> 
>  > These logs are of 'emacs -Q' followed by evaluating
>  >
>  >    (set-face-attribute 'default nil :height 110 :family 
> "InconsolataLGC")
> 
> FWIW, it would be nice to get the 80x36 and 84x36 below
> 
> adjust_frame_size old native pixels 1728x1620 new native pixels 
> 1408x1332 old text pixels 1680x1620 new text pixels 1360x1332 old text 
> chars 80x36 new text chars 80x36
>      base_size 32x84 size increments 8x18 WM hint 84x36
> 
> in synch but I have no clear idea yet how to do that.  IIRC I added the 
> last
> line to that comment in gtkutil.c
> 
>    /* Use one row/col here so base_height/width does not become zero.
>       Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
>       Obviously this makes the row/col value displayed off by 1.  */
> 
> some time ago but am not sure whether it explains the problem in its
> entirety or something else has to be done too.
> 
>  >> I see.  BTW, your Lucid scroll bar doesn't seem to have a ruler (or
>  >> thumb, or whatever you call it) nor the arrows at top and bottom.
>  >
>  > Indeed. Not sure if it's supposed to.
>  >
>  > The scrollbar itself is not very functional: it shows the scroll
>  > progress of the buffer, but to scroll back using the mouse clicks
>  > seems impossible (all scrolling proceeds in one direction).
> 
> Are these toolkit scroll bars?  What are your build options for Lucid?

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11
XDBE XIM XINPUT2 XPM LUCID ZLIB

> Whatever it is, this behavior deserves a separate bug report.

Actually, it seems like I just didn't understand how to use it at first: 
when I hover the mouse over the scrollbar, a two-sided arrow appears.

With that, clicking the left mouse button scrolls the buffer in one 
direction, and clicking the right mouse button (anywhere) scrolls the 
buffer in another direction. I've very little experience with 
Lucid/Motif applications, so this took some experimentation.

And it does have a thumb when the buffer is taller than the window. 
Sometimes the thumb gets bigger and sometimes smaller, though. That's a 
little odd. Perhaps it works off the number of visible characters rather 
than lines.

>  > The second and all subsequent ones look like this:
>  >
>  > x_new_font old char size 17x37 new char size 17x37 text chars 80x36 
> old text pixels 1360x1332 new text pixels 1360x1332
>  >
>  > x_new_font old char size 17x37 new char size 17x37 text chars 80x36 
> old text pixels 1360x1332 new text pixels 1360x1332
>  >
>  > (This is while keeping the frame in its default size; no resizing 
> with the mouse.)
> 
> All these show no differences between the two Inconsolatas.  So the
> reason why one keeps your frame shrinking and the other doesn't still
> remains a mystery.
> 
>  > It looks like both trigger two x_new_fonts calls the first time. And 
> maybe resize the frame twice, which could be hard to register with the 
> human eye. But then one continues to do that (under certain conditions), 
> and another stops.
>  >
>  >> It should be something like not finding a suitable
>  >> font with "InconsolataLGC" or at least one that does not ask for
>  >> changing the height
>  >
>  > That's what I was thinking: "InconsolataLGC" falls back to
>  > "Inconsolata LGC", but that's not registered in some internal data
>  > structure, so whenever a new set-face-attribute call arrives, the
>  > comparison fails, and the search is repeated.
> 
> You could try with two separate 'set-face-attribute' calls.  That is: Do
> the below for both Inconsolata fonts
> 
>  > InconsolataLGC:
>  >
>  > first hit:
>  >
>  > (gdb) p font->average_width
>  > $1 = 21
>  > (gdb) p font_ascent
>  > $2 = 37
>  > (gdb) p font_descent
>  > $3 = 8
>  >
>  > second hit:
>  >
>  > (gdb) p font->average_width
>  > $4 = 17
>  > (gdb) p font_ascent
>  > $5 = 31
>  > (gdb) p font_descent
>  > $6 = 6
>  >
>  > Inconsolata LGC:
>  >
>  > Exactly the same.
> 
> first with only :family set leaving :height alone and then with only
> :height set leaving :family alone.  Then do the reverse - that is first
> with only :height set leaving :family alone and then with only :family
> set leaving :height alone.

Okay.

InconsolataLGC:

(set-face-attribute 'default nil :family "InconsolataLGC")

(gdb) p font->average_width
$1 = 21
(gdb) p font_ascent
$2 = 37
(gdb) p font_descent
$3 = 8

(set-face-attribute 'default nil :height 110)

(gdb) p font->average_width
$7 = 17
(gdb) p font_ascent
$8 = 31
(gdb) p font_descent
$9 = 6

Now the reverse:

(set-face-attribute 'default nil :height 110)

(gdb) p font->average_width
$10 = 15
(gdb) p font_ascent
$11 = 25
(gdb) p font_descent
$12 = 5

(set-face-attribute 'default nil :family "InconsolataLGC")

(gdb) p font->average_width
$13 = 17
(gdb) p font_ascent
$14 = 31
(gdb) p font_descent
$15 = 6

(I did restart Emacs between tries, just not GDB.)

Inconsolata LGC:

All exactly the same. Omitted to save space.




This bug report was last modified 2 years and 205 days ago.

Previous Next


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