bug#59306: 29.0.50; Resurrected bug?

bug#59306: 29.0.50; Resurrected bug?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 5256 bytes --]

I'm on Emacs29, compiled every 1 or two days, using

(set-face-attribute 'default nil :family "whatever" :height my-height)

to set my default font in ~/init.el and I've started needing

(define-key special-event-map [config-changed-event] 'ignore)

to avoid seeing it changed to the default mono font in my system... I've
learned the trick from

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25228#152

Proof-of-concept init.el file:
------------------------------------------------------------------------------------------------
;;
;; GUI
;;
(defun set-font (font-family font-size &optional line-space)
  "Set font, size and, optionally line-spacing"
  (message "using '%s' font" font-family)
  (setq-default line-spacing line-space) ; reset line-spacing when it is
not indicated
  (set-face-attribute 'default nil
                      :family font-family
                      :height font-size))

(set-font "Liberation Mono" 110 2)
;; (define-key special-event-map [config-changed-event] 'ignore)
(setq default-frame-alist '((width . 110) (height . 30)))
(message "That's it folks!")
------------------------------------------------------------------------------------------------
Like this it will reset the font to whatever the default monotype font is
defined in the system.
If you uncomment the (define-key line, you get the right font..

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.20, cairo version 1.16.0) of 2022-11-14 built on d0752a8af10b
Repository revision: 83a497ee879959cd1b052fa9138adb79b480394d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.5 LTS

Configured using:
 'configure --prefix=/usr --program-suffix=29 --with-json --with-x
 --with-x-toolkit=gtk3 --with-cairo --with-compress-install
 --with-modules=yes --with-threads --with-included-regex --with-zlib
 --with-native-compilation 'CFLAGS=-g -O2
 -fdebug-prefix-map=/home/paag/emacs=. -fstack-protector-strong -Wformat
 -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

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

Important settings:
  value of $LC_MONETARY: es_ES.UTF-8
  value of $LC_NUMERIC: es_ES.UTF-8
  value of $LC_TIME: es_ES.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides
/usr/share/emacs/29.0.50/lisp/language/thai-word

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 78712 6045)
 (symbols 48 7113 0)
 (strings 32 19577 1968)
 (string-bytes 1 574200)
 (vectors 16 15742)
 (vector-slots 8 325249 11599)
 (floats 8 28 48)
 (intervals 56 234 0)
 (buffers 984 12))

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 7180 bytes --]

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Repository revision: 83a497ee879959cd1b052fa9138adb79b480394d

What if you update to c63d77ac6b10dc453d08afc852debc6a9a3cde36 or later?

bug#59306: 29.0.50; Resurrected bug?

[Dmitry Gutov]

On 16.11.2022 15:59, Po Lu via Bug reports for GNU Emacs, the Swiss army 
knife of text editors wrote:
> Pedro Andres Aranda Gutierrez<paaguti@gmail.com>  writes:
> 
>> Repository revision: 83a497ee879959cd1b052fa9138adb79b480394d
> What if you update to c63d77ac6b10dc453d08afc852debc6a9a3cde36 or later?

Since this bug sounds similar or at least related to bug#58912, I 
probably should comment:

Rebuilding from the latest master makes the scenario in bug#58912 much 
better, in that the font size is applied correctly at the end.

It's still different from Emacs 28 in that the frame size goes through 
an extra transition at the end of loading. And sometimes through 1 more 
(the last one the same as the -2nd one). So sometimes I end up with a 
window of 84x37, and sometimes (less frequently) 80x35. All according to 
window-height and window-width.

Emacs 28 and an older build of master both end up at 80x35.

But at least the font size and family are ok now.

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Since this bug sounds similar or at least related to bug#58912, I
> probably should comment:
>
> Rebuilding from the latest master makes the scenario in bug#58912 much
> better, in that the font size is applied correctly at the end.
>
> It's still different from Emacs 28 in that the frame size goes through
> an extra transition at the end of loading. And sometimes through 1
> more (the last one the same as the -2nd one). So sometimes I end up
> with a window of 84x37, and sometimes (less frequently) 80x35. All
> according to window-height and window-width.
>
> Emacs 28 and an older build of master both end up at 80x35.
>
> But at least the font size and family are ok now.

I guess Cairo just refuses to tell us what the DPI it defaults to using
is, so Emacs always ends up having to redraw the fonts at startup.

Please give me a while to think up a solution.

bug#59306: 29.0.50; Resurrected bug?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

I do confirm that with a build around 20:00 pm yesterday CET, the font is
OK, but there are a couple more transitions than with emacs28...

/PA

On Thu, 17 Nov 2022 at 02:28, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 16.11.2022 15:59, Po Lu via Bug reports for GNU Emacs, the Swiss army
> knife of text editors wrote:
> > Pedro Andres Aranda Gutierrez<paaguti@gmail.com>  writes:
> >
> >> Repository revision: 83a497ee879959cd1b052fa9138adb79b480394d
> > What if you update to c63d77ac6b10dc453d08afc852debc6a9a3cde36 or later?
>
> Since this bug sounds similar or at least related to bug#58912, I
> probably should comment:
>
> Rebuilding from the latest master makes the scenario in bug#58912 much
> better, in that the font size is applied correctly at the end.
>
> It's still different from Emacs 28 in that the frame size goes through
> an extra transition at the end of loading. And sometimes through 1 more
> (the last one the same as the -2nd one). So sometimes I end up with a
> window of 84x37, and sometimes (less frequently) 80x35. All according to
> window-height and window-width.
>
> Emacs 28 and an older build of master both end up at 80x35.
>
> But at least the font size and family are ok now.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2132 bytes --]

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Since this bug sounds similar or at least related to bug#58912, I
>> probably should comment:
>>
>> Rebuilding from the latest master makes the scenario in bug#58912 much
>> better, in that the font size is applied correctly at the end.
>>
>> It's still different from Emacs 28 in that the frame size goes through
>> an extra transition at the end of loading. And sometimes through 1
>> more (the last one the same as the -2nd one). So sometimes I end up
>> with a window of 84x37, and sometimes (less frequently) 80x35. All
>> according to window-height and window-width.
>>
>> Emacs 28 and an older build of master both end up at 80x35.
>>
>> But at least the font size and family are ok now.
>
> I guess Cairo just refuses to tell us what the DPI it defaults to using
> is, so Emacs always ends up having to redraw the fonts at startup.
>
> Please give me a while to think up a solution.

Please see whether or not Emacs now behaves satisfactorily wrt this.

bug#59306: 29.0.50; Resurrected bug?

[Pedro Andres Aranda Gutierrez]

I think it’s solved!
/PA
PS:, dirty fit the late answer… life came in between…

Enviado desde mi iPhone

> El 19 nov 2022, a las 7:03, Po Lu <luangruo@yahoo.com> escribió:
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> Since this bug sounds similar or at least related to bug#58912, I
>>> probably should comment:
>>> 
>>> Rebuilding from the latest master makes the scenario in bug#58912 much
>>> better, in that the font size is applied correctly at the end.
>>> 
>>> It's still different from Emacs 28 in that the frame size goes through
>>> an extra transition at the end of loading. And sometimes through 1
>>> more (the last one the same as the -2nd one). So sometimes I end up
>>> with a window of 84x37, and sometimes (less frequently) 80x35. All
>>> according to window-height and window-width.
>>> 
>>> Emacs 28 and an older build of master both end up at 80x35.
>>> 
>>> But at least the font size and family are ok now.
>> 
>> I guess Cairo just refuses to tell us what the DPI it defaults to using
>> is, so Emacs always ends up having to redraw the fonts at startup.
>> 
>> Please give me a while to think up a solution.
> 
> Please see whether or not Emacs now behaves satisfactorily wrt this.

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> I think it’s solved!

Thanks.  Dimitry?

bug#59306: 29.0.50; Resurrected bug?

[Dmitry Gutov]

On 19.11.2022 12:03, Po Lu via Bug reports for GNU Emacs, the Swiss army 
knife of text editors wrote:
> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> 
>> I think it’s solved!
> 
> Thanks.  Dimitry?

No change since the last test I tried: fonts seem fine, but the frame 
size is jumping. I even did 'make bootstrap' to be doubly sure.

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dgutov@yandex.ru> writes:

> No change since the last test I tried: fonts seem fine, but the frame
> size is jumping. I even did 'make bootstrap' to be doubly sure.

Thanks.  Could you place a breakpoint on `apply_xft_settings' before
starting "emacs -Q", step through it, and try to find out what causes
the `changed' variable to be set to true?

bug#59306: 29.0.50; Resurrected bug?

[Dmitry Gutov]

On 20.11.2022 02:36, Po Lu via Bug reports for GNU Emacs, the Swiss army 
knife of text editors wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> No change since the last test I tried: fonts seem fine, but the frame
>> size is jumping. I even did 'make bootstrap' to be doubly sure.
> Thanks.  Could you place a breakpoint on `apply_xft_settings' before
> starting "emacs -Q", step through it, and try to find out what causes
> the `changed' variable to be set to true?

Apparently it's this part:

#ifdef FC_HINT_STYLE
   if ((settings->seen & SEEN_HINTSTYLE) != 0
       && oldsettings.hintstyle != settings->hintstyle)
     {
       FcPatternDel (pat, FC_HINT_STYLE);
       FcPatternAddInteger (pat, FC_HINT_STYLE, settings->hintstyle);
       changed = true;
       oldsettings.hintstyle = settings->hintstyle;
     }
#endif

Here's the relevant part of the gdb log, since I don't have much 
experience with it. The assignment statement itself seems to be missing 
from the stepping, but 'changed' became true after:

(gdb) n
842       FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi);
(gdb) p changed
$2 = false
(gdb) n
844       if ((settings->seen & SEEN_AA) != 0 && oldsettings.aa != 
settings->aa)
(gdb) n
852       if ((settings->seen & SEEN_HINTING) != 0
(gdb) n
860       if ((settings->seen & SEEN_RGBA) != 0 && oldsettings.rgba != 
settings->rgba)
(gdb) n
869       if ((settings->seen & SEEN_LCDFILTER) != 0
(gdb) n
879       if ((settings->seen & SEEN_HINTSTYLE) != 0
(gdb) n
882           FcPatternDel (pat, FC_HINT_STYLE);
(gdb) n
883           FcPatternAddInteger (pat, FC_HINT_STYLE, settings->hintstyle);
(gdb) n
885           oldsettings.hintstyle = settings->hintstyle;
(gdb) n
894       oldsettings.dpi = dpyinfo->resx;
(gdb) p changed
$3 = true

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 20.11.2022 02:36, Po Lu via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> No change since the last test I tried: fonts seem fine, but the frame
>>> size is jumping. I even did 'make bootstrap' to be doubly sure.
>> Thanks.  Could you place a breakpoint on `apply_xft_settings' before
>> starting "emacs -Q", step through it, and try to find out what causes
>> the `changed' variable to be set to true?
>
> Apparently it's this part:
>
> #ifdef FC_HINT_STYLE
>   if ((settings->seen & SEEN_HINTSTYLE) != 0
>       && oldsettings.hintstyle != settings->hintstyle)
>     {
>       FcPatternDel (pat, FC_HINT_STYLE);
>       FcPatternAddInteger (pat, FC_HINT_STYLE, settings->hintstyle);
>       changed = true;
>       oldsettings.hintstyle = settings->hintstyle;
>     }
> #endif
>
> Here's the relevant part of the gdb log, since I don't have much
> experience with it. The assignment statement itself seems to be
> missing from the stepping, but 'changed' became true after:
>
> (gdb) n
> 842       FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi);
> (gdb) p changed
> $2 = false
> (gdb) n
> 844       if ((settings->seen & SEEN_AA) != 0 && oldsettings.aa !=
> settings->aa)
> (gdb) n
> 852       if ((settings->seen & SEEN_HINTING) != 0
> (gdb) n
> 860       if ((settings->seen & SEEN_RGBA) != 0 && oldsettings.rgba !=
> settings->rgba)
> (gdb) n
> 869       if ((settings->seen & SEEN_LCDFILTER) != 0
> (gdb) n
> 879       if ((settings->seen & SEEN_HINTSTYLE) != 0
> (gdb) n
> 882           FcPatternDel (pat, FC_HINT_STYLE);
> (gdb) n
> 883           FcPatternAddInteger (pat, FC_HINT_STYLE, settings->hintstyle);
> (gdb) n
> 885           oldsettings.hintstyle = settings->hintstyle;
> (gdb) n
> 894       oldsettings.dpi = dpyinfo->resx;
> (gdb) p changed
> $3 = true

Thanks.  That's quite annoying, I guess Cairo isn't reporting the
default hint style to us either.

I can't think of a good solution off-hand, please give me some more
time.

bug#59306: 29.0.50; Resurrected bug?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

It definitely looks like that, because it doesn't happen on my macOS Emacs
(compiled from the same git as for Linux). When I return home, I was
thinking about compiling Emacs on Linuux for GTK3 but disabling CAIRO...
would that make eny sense?

/PA

On Mon, 21 Nov 2022 at 01:35, Po Lu <luangruo@yahoo.com> wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 20.11.2022 02:36, Po Lu via Bug reports for GNU Emacs, the Swiss
> > army knife of text editors wrote:
> >> Dmitry Gutov<dgutov@yandex.ru>  writes:
> >>
> >>> No change since the last test I tried: fonts seem fine, but the frame
> >>> size is jumping. I even did 'make bootstrap' to be doubly sure.
> >> Thanks.  Could you place a breakpoint on `apply_xft_settings' before
> >> starting "emacs -Q", step through it, and try to find out what causes
> >> the `changed' variable to be set to true?
> >
> > Apparently it's this part:
> >
> > #ifdef FC_HINT_STYLE
> >   if ((settings->seen & SEEN_HINTSTYLE) != 0
> >       && oldsettings.hintstyle != settings->hintstyle)
> >     {
> >       FcPatternDel (pat, FC_HINT_STYLE);
> >       FcPatternAddInteger (pat, FC_HINT_STYLE, settings->hintstyle);
> >       changed = true;
> >       oldsettings.hintstyle = settings->hintstyle;
> >     }
> > #endif
> >
> > Here's the relevant part of the gdb log, since I don't have much
> > experience with it. The assignment statement itself seems to be
> > missing from the stepping, but 'changed' became true after:
> >
> > (gdb) n
> > 842       FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi);
> > (gdb) p changed
> > $2 = false
> > (gdb) n
> > 844       if ((settings->seen & SEEN_AA) != 0 && oldsettings.aa !=
> > settings->aa)
> > (gdb) n
> > 852       if ((settings->seen & SEEN_HINTING) != 0
> > (gdb) n
> > 860       if ((settings->seen & SEEN_RGBA) != 0 && oldsettings.rgba !=
> > settings->rgba)
> > (gdb) n
> > 869       if ((settings->seen & SEEN_LCDFILTER) != 0
> > (gdb) n
> > 879       if ((settings->seen & SEEN_HINTSTYLE) != 0
> > (gdb) n
> > 882           FcPatternDel (pat, FC_HINT_STYLE);
> > (gdb) n
> > 883           FcPatternAddInteger (pat, FC_HINT_STYLE,
> settings->hintstyle);
> > (gdb) n
> > 885           oldsettings.hintstyle = settings->hintstyle;
> > (gdb) n
> > 894       oldsettings.dpi = dpyinfo->resx;
> > (gdb) p changed
> > $3 = true
>
> Thanks.  That's quite annoying, I guess Cairo isn't reporting the
> default hint style to us either.
>
> I can't think of a good solution off-hand, please give me some more
> time.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 3996 bytes --]

bug#59306: 29.0.50; Resurrected bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> It definitely looks like that, because it doesn't happen on my macOS
> Emacs (compiled from the same git as for Linux). When I return home, I
> was thinking about compiling Emacs on Linuux for GTK3 but disabling
> CAIRO... would that make eny sense?

Yes, that would eliminate the bug.

bug#59306: 29.0.50; Resurrected bug?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

I tried, there is an improvement but I loose all the nice fonts :-( Trying
with pgtk now...

BR,/PA

On Fri, 25 Nov 2022 at 10:11, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > It definitely looks like that, because it doesn't happen on my macOS
> > Emacs (compiled from the same git as for Linux). When I return home, I
> > was thinking about compiling Emacs on Linuux for GTK3 but disabling
> > CAIRO... would that make eny sense?
>
> Yes, that would eliminate the bug.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1388 bytes --]