bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

Hi,

just get a bug report from an user and I've verified that: using
(custom-set-faces) is ignored from ~/.emacs.  Using eval-expression
in minibuffer after start shows that the function its self does work.

The example was
(custom-set-faces '(default ((t (:family "B&H
LucidaTypewriter" :foundry "B&H" :slant normal :weight normal :height 90
:width normal)))))

I've tried direct in ~/.emacs as well as with a separate defined custom
file in ~/.emacs with

  (setq custom-file "~/.gnu-emacs-custom")
  (load custom-file t t)

and I've verified that ~/.emacs as well as ~/.gnu-emacs-custom will be
loaded as strace shows.

In GNU Emacs 25.1.1 (x86_64-suse-linux-gnu, GTK+ Version 3.16.7)
 of 2016-09-21 built on lamb20
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	openSUSE Leap 42.1 (x86_64)

Configured using:
 'configure --with-pop --without-hesiod --with-kerberos --with-kerberos5
 --with-xim --with-wide-int --with-file-notification=inotify
 --with-modules --enable-autodepend --prefix=/usr
 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
 --localstatedir=/var --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --enable-locallisppath=/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-x --with-sound --with-xpm --with-jpeg --with-tiff --with-gif
 --with-png --with-rsvg --with-dbus --with-xft --without-gpm
 --with-x-toolkit=gtk3 --with-xwidgets --x-includes=/usr/include
 --x-libraries=/usr/lib64 --with-libotf --with-m17n-flt
 --build=x86_64-suse-linux 'CFLAGS=-fmessage-length=0
 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
 -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE
 -DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS
 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
 -Wno-unprototyped-calls -fno-optimize-sibling-calls -fno-PIE
 -DSYSTEM_PURESIZE_EXTRA=55000 -DSITELOAD_PURESIZE_EXTRA=10000 '
 LDFLAGS=-Wl,-O2'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS

Important settings:
  value of $LC_CTYPE: de_DE.UTF-8
  value of $LC_NUMERIC: POSIX
  value of $LANG: POSIX
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  TeX-PDF-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
funcall-interactively: End of buffer [3 times]

Load-path shadows:
~/lib/site-lisp/rmime hides /usr/share/emacs/site-lisp/rmime

Features:
(shadow sort mail-extr warnings emacsbug message dired format-spec
rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mail-utils font-latex byte-opt bytecomp byte-compile cl-extra help-mode
cl-loaddefs pcase cl-lib cconv tex dbus xml advice easymenu xfonts
rmailgen paren preview-latex tex-site auto-loads ispell time-date
mule-util delsel lpr tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 108858 11724)
 (symbols 48 22141 0)
 (miscs 40 145 193)
 (strings 32 22181 5006)
 (string-bytes 1 672385)
 (vectors 16 14980)
 (vector-slots 8 495866 4807)
 (floats 8 183 129)
 (intervals 56 275 0)
 (buffers 976 19)
 (heap 1024 29223 918))

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

On Mon, Dec 19, 2016 at 11:03:06AM +0100, Werner Fink wrote:
> 
> Hi,
> 
> just get a bug report from an user and I've verified that: using
> (custom-set-faces) is ignored from ~/.emacs.  Using eval-expression
> in minibuffer after start shows that the function its self does work.
> 
> The example was
> (custom-set-faces '(default ((t (:family "B&H
> LucidaTypewriter" :foundry "B&H" :slant normal :weight normal :height 90
> :width normal)))))
> 
> I've tried direct in ~/.emacs as well as with a separate defined custom
> file in ~/.emacs with
> 
>   (setq custom-file "~/.gnu-emacs-custom")
>   (load custom-file t t)
> 
> and I've verified that ~/.emacs as well as ~/.gnu-emacs-custom will be
> loaded as strace shows.
> 


Using the line 

  (defalias 'dynamic-setting-handle-config-changed-event 'ignore)

in ~/.emacs or the custom-file does avoid the problem. The question rises
which event does trigger this even and wyh the custom settings are
expanded before this even.

Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> From: werner@suse.de (Dr. Werner Fink)
> Date: Mon, 19 Dec 2016 11:03:06 +0100
> 
> just get a bug report from an user and I've verified that: using
> (custom-set-faces) is ignored from ~/.emacs.  Using eval-expression
> in minibuffer after start shows that the function its self does work.
> 
> The example was
> (custom-set-faces '(default ((t (:family "B&H
> LucidaTypewriter" :foundry "B&H" :slant normal :weight normal :height 90
> :width normal)))))
> 
> I've tried direct in ~/.emacs as well as with a separate defined custom
> file in ~/.emacs with
> 
>   (setq custom-file "~/.gnu-emacs-custom")
>   (load custom-file t t)
> 
> and I've verified that ~/.emacs as well as ~/.gnu-emacs-custom will be
> loaded as strace shows.

I cannot reproduce this.  I put the above (with a different font, as I
don't have that one) in my .emacs, and it did have the expected
effect.

Is there anything else in that .emacs?

Thanks.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > I cannot reproduce this.  I put the above (with a different font, as I
 > don't have that one) in my .emacs, and it did have the expected
 > effect.
 >
 > Is there anything else in that .emacs?

Compare

https://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00557.html

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Mon, 19 Dec 2016 19:36:11 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 25228@debbugs.gnu.org
> 
>  > I cannot reproduce this.  I put the above (with a different font, as I
>  > don't have that one) in my .emacs, and it did have the expected
>  > effect.
>  >
>  > Is there anything else in that .emacs?
> 
> Compare
> 
> https://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00557.html

Somebody with access to an effected system should debug this some day.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > Somebody with access to an effected system should debug this some day.

Back then that idea stalled after

 > OK.  Below you'll get more than you asked for.  The breakpoint is hit
 > four times, the third (with a value of 15) when my .emacs is read and
 > the fourth (with a value of 18 again) when the
 > ‘dynamic-setting-handle-config-changed-event’ is processed (the fourth
 > is the one I posted before).

and your answer

 > Thanks, I will look into that and see what it tells.

IIUC all this ‘dynamic-setting-handle-config-changed-event’ mechanism is
about detecting changes applied to GConf and/or GSettings on the fly and
applying them to the running Emacs session.  Such configuration settings
should never override anything specified by the user in her .emacs.  The
mechanism was virtually inoperative for four years until Paul changed an
innocuous parameter descriptor.  So this mechanism has never been tested
in all those years ...

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Mon, 19 Dec 2016 21:20:49 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: werner@suse.de, 25228@debbugs.gnu.org
> 
> IIUC all this ‘dynamic-setting-handle-config-changed-event’ mechanism is
> about detecting changes applied to GConf and/or GSettings on the fly and
> applying them to the running Emacs session.  Such configuration settings
> should never override anything specified by the user in her .emacs.  The
> mechanism was virtually inoperative for four years until Paul changed an
> innocuous parameter descriptor.  So this mechanism has never been tested
> in all those years ...

Can you describe how that mechanism is triggered by the offending
change?

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > Can you describe how that mechanism is triggered by the offending
 > change?

Which one is "the offending change"?  If you reread the thread, you will
see that there are controversial opinions.  Anyway, here we go.

I use a file /home/martin/temp/default-face.el with the following
contents:

(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
  '(default ((t (:inherit nil :stipple nil :background "grey92" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 98 :width normal :foundry "unknown" :family "Droid Sans Mono")))))

The ":height 98" entry in this form before the offending change did set
the "height of the default face in 1/10 pt" to 98.  After the offending
change it is set to 113.  I have no idea what a "pt" is (and I have no
idea what an "inch" is).  But from experience I know that the value of
`window-font-height' for the root window of the initial frame is 15 for
a default face height of 98 and 18 for a default face height of 113.

As a consequence of the offending change, the frame character height of
my initial frame is now 18 instead of the desired 15.  In the following
I will try to explain how this happened here.

[Werner - if you read this, please try to repeat it, maybe you get a
completely different behavior.  I gdb one of my current versions of a
GTK build of master, so the line numbers may be off wrt what you have
(unfortunately, debugging the release version freezes GNU/Linux
completely here and I have to turn off the power in order to restart
it).]

I first visit the file xsettings.c in the .src directory and start the
debugger via M-x gdb completing it to

gdb -i=mi /home/martin/emacs-git/quick/obj-gtk/src/emacs

which includes the path of my GTK executable.  Next in xsettings.c I
move to line 611 which reads as

   memset (&oldsettings, 0, sizeof (oldsettings));

and set a breakpoint there.  Then I run the executable via

run -Q --load /home/martin/temp/default-face.el

and wait till the breakpoint is hit.  In the function where I set the
breakpoint (apply_xft_settings) I now want to trigger the setting of the
variable

       changed = true;

I do this by stepping via "n" and find that it happens on line 675
because of oldsettings.dpi != settings->dpi: The old value was
96.281588447653434 while the new value is 96.  As a consequence, on line
701 a

       store_config_changed_event (Qfont_render,
				  XCAR (dpyinfo->name_list_element));

will store an event in my event queue whose execution will eventually
trigger the offending change.  The backtrace till here is:

#0  apply_xft_settings (dpyinfo=0xef1230, settings=0x7fffffffb280) at ../../src/xsettings.c:702
#1  0x000000000056bc31 in read_and_apply_settings (dpyinfo=0xef1230, send_event_p=false) at ../../src/xsettings.c:726
#2  0x000000000056c073 in init_xsettings (dpyinfo=0xef1230) at ../../src/xsettings.c:938
#3  0x000000000056c0ae in xsettings_initialize (dpyinfo=0xef1230) at ../../src/xsettings.c:948
#4  0x00000000005508f6 in x_term_init (display_name=..., xrm_option=0x0, resource_name=0xe38010 "emacs") at ../../src/xterm.c:12617
#5  0x000000000055b6bc in Fx_open_connection (display=..., xrm_string=..., must_succeed=...) at ../../src/xfns.c:5257
#6  0x000000000063500e in Ffuncall (nargs=4, args=0x7fffffffba50) at ../../src/eval.c:2722
#7  0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffc458) at ../../src/bytecode.c:639
#8  0x0000000000635993 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffc458) at ../../src/eval.c:2879
#9  0x0000000000635215 in Ffuncall (nargs=1, args=0x7fffffffc450) at ../../src/eval.c:2764
#10 0x0000000000633c4a in Fapply (nargs=2, args=0x7fffffffc450) at ../../src/eval.c:2296
#11 0x0000000000634e71 in Ffuncall (nargs=3, args=0x7fffffffc448) at ../../src/eval.c:2695
#12 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffcbf0) at ../../src/bytecode.c:639
#13 0x0000000000635993 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffcbf0) at ../../src/eval.c:2879
#14 0x0000000000635215 in Ffuncall (nargs=1, args=0x7fffffffcbe8) at ../../src/eval.c:2764
#15 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffda88) at ../../src/bytecode.c:639
#16 0x0000000000635993 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffda88) at ../../src/eval.c:2879
#17 0x0000000000635215 in Ffuncall (nargs=1, args=0x7fffffffda80) at ../../src/eval.c:2764
#18 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffe2c0) at ../../src/bytecode.c:639
#19 0x0000000000635993 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffe2c0) at ../../src/eval.c:2879
#20 0x00000000006355dd in apply_lambda (fun=..., args=..., count=4) at ../../src/eval.c:2816
#21 0x000000000063391b in eval_sub (form=...) at ../../src/eval.c:2233
#22 0x0000000000632d15 in Feval (form=..., lexical=...) at ../../src/eval.c:2010
#23 0x0000000000582abe in top_level_2 () at ../../src/keyboard.c:1127
#24 0x000000000063126a in internal_condition_case (bfun=0x582aa1 <top_level_2>, handlers=..., hfun=0x5824c2 <cmd_error>) at ../../src/eval.c:1314
#25 0x0000000000582aff in top_level_1 (ignore=...) at ../../src/keyboard.c:1135
#26 0x00000000006307f8 in internal_catch (tag=..., func=0x582ac0 <top_level_1>, arg=...) at ../../src/eval.c:1080
#27 0x00000000005829f9 in command_loop () at ../../src/keyboard.c:1096
#28 0x0000000000581fd6 in recursive_edit_1 () at ../../src/keyboard.c:703
#29 0x00000000005821b5 in Frecursive_edit () at ../../src/keyboard.c:774
#30 0x000000000057ff33 in main (argc=4, argv=0x7fffffffe8a8) at ../../src/emacs.c:1659

Lisp Backtrace:
"x-open-connection" (0xffffba58)
0x13cc630 PVEC_COMPILED
"apply" (0xffffc450)
"window-system-initialization" (0xffffcbf0)
"command-line" (0xffffda88)
"normal-top-level" (0xffffe2c0)
(gdb)

Now I set a breakpoint in the function x_new_font of xterm.c at the
beginning of the line

FRAME_LINE_HEIGHT (f) = font_ascent + font_descent;

which is line 9829 here (yours will surely differ) and continue
debugging via "c".  After hitting the breakpoint I do

(gdb) p font_ascent + font_descent
$11 = 18

This is not the value I wanted via my customizations - I want a value of
15.  So I continue until I get the desired value via

(gdb) p font_ascent + font_descent
$13 = 15

The backtrace till here is

#0  x_new_font (f=0x1423860, font_object=..., fontset=21) at ../../src/xterm.c:9829
#1  0x0000000000430a53 in x_set_font (f=0x1423860, arg=..., oldval=...) at ../../src/frame.c:3749
#2  0x000000000042e809 in x_set_frame_parameters (f=0x1423860, alist=...) at ../../src/frame.c:3342
#3  0x000000000042d1b6 in Fmodify_frame_parameters (frame=..., alist=...) at ../../src/frame.c:2801
#4  0x000000000052fe9a in set_font_frame_param (frame=..., lface=...) at ../../src/xfaces.c:3328
#5  0x000000000052f65b in Finternal_set_lisp_face_attribute (face=..., attr=..., value=..., frame=...) at ../../src/xfaces.c:3142
#6  0x0000000000635051 in Ffuncall (nargs=5, args=0x7fffffff7ca0) at ../../src/eval.c:2726
#7  0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=32, args=0x7fffffff84c8) at ../../src/bytecode.c:639
#8  0x0000000000635993 in funcall_lambda (fun=..., nargs=32, arg_vector=0x7fffffff84b8) at ../../src/eval.c:2879
#9  0x0000000000635215 in Ffuncall (nargs=33, args=0x7fffffff84b0) at ../../src/eval.c:2764
#10 0x0000000000634271 in Fapply (nargs=4, args=0x7fffffff87a0) at ../../src/eval.c:2343
#11 0x0000000000634e71 in Ffuncall (nargs=5, args=0x7fffffff8798) at ../../src/eval.c:2695
#12 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=3, args=0x7fffffff8f58) at ../../src/bytecode.c:639
#13 0x0000000000635993 in funcall_lambda (fun=..., nargs=3, arg_vector=0x7fffffff8f40) at ../../src/eval.c:2879
#14 0x0000000000635215 in Ffuncall (nargs=4, args=0x7fffffff8f38) at ../../src/eval.c:2764
#15 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x7fffffff9728) at ../../src/bytecode.c:639
#16 0x0000000000635993 in funcall_lambda (fun=..., nargs=2, arg_vector=0x7fffffff9718) at ../../src/eval.c:2879
#17 0x0000000000635215 in Ffuncall (nargs=3, args=0x7fffffff9710) at ../../src/eval.c:2764
#18 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=3, args=0x7fffffff9eb8) at ../../src/bytecode.c:639
#19 0x0000000000635993 in funcall_lambda (fun=..., nargs=3, arg_vector=0x7fffffff9ea0) at ../../src/eval.c:2879
#20 0x0000000000635215 in Ffuncall (nargs=4, args=0x7fffffff9e98) at ../../src/eval.c:2764
#21 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at ../../src/bytecode.c:639
#22 0x0000000000635e3a in funcall_lambda (fun=..., nargs=2, arg_vector=0xa1a5d5) at ../../src/eval.c:2945
#23 0x0000000000635215 in Ffuncall (nargs=3, args=0x7fffffffa850) at ../../src/eval.c:2764
#24 0x0000000000633cc6 in Fapply (nargs=3, args=0x7fffffffa850) at ../../src/eval.c:2300
#25 0x0000000000634e71 in Ffuncall (nargs=4, args=0x7fffffffa848) at ../../src/eval.c:2695
#26 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at ../../src/bytecode.c:639
#27 0x0000000000635e3a in funcall_lambda (fun=..., nargs=1, arg_vector=0xa1a47d) at ../../src/eval.c:2945
#28 0x00000000006355dd in apply_lambda (fun=..., args=..., count=37) at ../../src/eval.c:2816
#29 0x000000000063391b in eval_sub (form=...) at ../../src/eval.c:2233
#30 0x0000000000669c55 in readevalloop_eager_expand_eval (val=..., macroexpand=...) at ../../src/lread.c:1759
#31 0x000000000066a3ab in readevalloop (readcharfun=..., stream=0x0, sourcename=..., printflag=false, unibyte=..., readfun=..., start=..., end=...) at ../../src/lread.c:1927
#32 0x000000000066a715 in Feval_buffer (buffer=..., printflag=..., filename=..., unibyte=..., do_allow_print=...) at ../../src/lread.c:1993
#33 0x000000000063509f in Ffuncall (nargs=6, args=0x7fffffffb358) at ../../src/eval.c:2731
#34 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at ../../src/bytecode.c:639
#35 0x0000000000635e3a in funcall_lambda (fun=..., nargs=4, arg_vector=0x9d2c5d) at ../../src/eval.c:2945
#36 0x0000000000635215 in Ffuncall (nargs=5, args=0x7fffffffbb90) at ../../src/eval.c:2764
#37 0x0000000000634a2f in call4 (fn=..., arg1=..., arg2=..., arg3=..., arg4=...) at ../../src/eval.c:2599
#38 0x0000000000668641 in Fload (file=..., noerror=..., nomessage=..., nosuffix=..., must_suffix=...) at ../../src/lread.c:1278
#39 0x000000000063509f in Ffuncall (nargs=4, args=0x7fffffffc000) at ../../src/eval.c:2731
#40 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffffffcbf8) at ../../src/bytecode.c:639
#41 0x0000000000635993 in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffffffcbf0) at ../../src/eval.c:2879
#42 0x0000000000635215 in Ffuncall (nargs=2, args=0x7fffffffcbe8) at ../../src/eval.c:2764
#43 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffda88) at ../../src/bytecode.c:639
#44 0x0000000000635993 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffda88) at ../../src/eval.c:2879
#45 0x0000000000635215 in Ffuncall (nargs=1, args=0x7fffffffda80) at ../../src/eval.c:2764
#46 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffe2c0) at ../../src/bytecode.c:639
#47 0x0000000000635993 in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffe2c0) at ../../src/eval.c:2879
#48 0x00000000006355dd in apply_lambda (fun=..., args=..., count=4) at ../../src/eval.c:2816
#49 0x000000000063391b in eval_sub (form=...) at ../../src/eval.c:2233
#50 0x0000000000632d15 in Feval (form=..., lexical=...) at ../../src/eval.c:2010
#51 0x0000000000582abe in top_level_2 () at ../../src/keyboard.c:1127
#52 0x000000000063126a in internal_condition_case (bfun=0x582aa1 <top_level_2>, handlers=..., hfun=0x5824c2 <cmd_error>) at ../../src/eval.c:1314
#53 0x0000000000582aff in top_level_1 (ignore=...) at ../../src/keyboard.c:1135
#54 0x00000000006307f8 in internal_catch (tag=..., func=0x582ac0 <top_level_1>, arg=...) at ../../src/eval.c:1080
#55 0x00000000005829f9 in command_loop () at ../../src/keyboard.c:1096
#56 0x0000000000581fd6 in recursive_edit_1 () at ../../src/keyboard.c:703
#57 0x00000000005821b5 in Frecursive_edit () at ../../src/keyboard.c:774
#58 0x000000000057ff33 in main (argc=4, argv=0x7fffffffe8a8) at ../../src/emacs.c:1659

Lisp Backtrace:
"internal-set-lisp-face-attribute" (0xffff7ca8)
"set-face-attribute" (0xffff84b8)
"apply" (0xffff87a0)
"face-spec-set-2" (0xffff8f40)
"face-spec-recalc" (0xffff9718)
"face-spec-set" (0xffff9ea0)
"custom-theme-set-faces" (0xffffa858)
"apply" (0xffffa850)
"custom-set-faces" (0xffffae90)
"eval-buffer" (0xffffb360)
"load-with-code-conversion" (0xffffbb98)
"load" (0xffffc008)
"command-line-1" (0xffffcbf0)
"command-line" (0xffffda88)
"normal-top-level" (0xffffe2c0)
(gdb)

So it's easy to see that my `custom-set-faces' got applied and I could
be happy.  However, typing "c" again will, unfortunately, reveal that my
customized settings get overruled by the earlier seen

(gdb) p font_ascent + font_descent
$14 = 18

The associated backtrace is now

#0  x_new_font (f=0x1423860, font_object=..., fontset=2) at ../../src/xterm.c:9829
#1  0x0000000000430a53 in x_set_font (f=0x1423860, arg=..., oldval=...) at ../../src/frame.c:3749
#2  0x000000000042e809 in x_set_frame_parameters (f=0x1423860, alist=...) at ../../src/frame.c:3342
#3  0x000000000042d1b6 in Fmodify_frame_parameters (frame=..., alist=...) at ../../src/frame.c:2801
#4  0x000000000052fe9a in set_font_frame_param (frame=..., lface=...) at ../../src/xfaces.c:3328
#5  0x000000000052f65b in Finternal_set_lisp_face_attribute (face=..., attr=..., value=..., frame=...) at ../../src/xfaces.c:3142
#6  0x0000000000635051 in Ffuncall (nargs=5, args=0x7fffffffb760) at ../../src/eval.c:2726
#7  0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=10, args=0x7fffffffbf90) at ../../src/bytecode.c:639
#8  0x0000000000635993 in funcall_lambda (fun=..., nargs=10, arg_vector=0x7fffffffbf80) at ../../src/eval.c:2879
#9  0x0000000000635215 in Ffuncall (nargs=11, args=0x7fffffffbf78) at ../../src/eval.c:2764
#10 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at ../../src/bytecode.c:639
#11 0x0000000000635e3a in funcall_lambda (fun=..., nargs=2, arg_vector=0xb4f7c5) at ../../src/eval.c:2945
#12 0x0000000000635215 in Ffuncall (nargs=3, args=0x7fffffffc748) at ../../src/eval.c:2764
#13 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at ../../src/bytecode.c:639
#14 0x0000000000635e3a in funcall_lambda (fun=..., nargs=1, arg_vector=0xb4f93d) at ../../src/eval.c:2945
#15 0x0000000000635215 in Ffuncall (nargs=2, args=0x7fffffffcfd8) at ../../src/eval.c:2764
#16 0x000000000062afdd in Ffuncall_interactively (nargs=2, args=0x7fffffffcfd8) at ../../src/callint.c:252
#17 0x0000000000634e71 in Ffuncall (nargs=3, args=0x7fffffffcfd0) at ../../src/eval.c:2695
#18 0x000000000062d5a0 in Fcall_interactively (function=..., record_flag=..., keys=...) at ../../src/callint.c:843
#19 0x000000000063500e in Ffuncall (nargs=4, args=0x7fffffffd488) at ../../src/eval.c:2722
#20 0x00000000006829ce in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=4, args=0x7fffffffdce8) at ../../src/bytecode.c:639
#21 0x0000000000635993 in funcall_lambda (fun=..., nargs=4, arg_vector=0x7fffffffdcc8) at ../../src/eval.c:2879
#22 0x0000000000635215 in Ffuncall (nargs=5, args=0x7fffffffdcc0) at ../../src/eval.c:2764
#23 0x0000000000634a2f in call4 (fn=..., arg1=..., arg2=..., arg3=..., arg4=...) at ../../src/eval.c:2599
#24 0x000000000058775d in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffffe21f, end_time=0x0) at ../../src/keyboard.c:2854
#25 0x00000000005975a7 in read_key_sequence (keybuf=0x7fffffffe3b0, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9155
#26 0x0000000000583286 in command_loop_1 () at ../../src/keyboard.c:1376
#27 0x000000000063126a in internal_condition_case (bfun=0x582e50 <command_loop_1>, handlers=..., hfun=0x5824c2 <cmd_error>) at ../../src/eval.c:1314
#28 0x0000000000582a7e in command_loop_2 (ignore=...) at ../../src/keyboard.c:1118
#29 0x00000000006307f8 in internal_catch (tag=..., func=0x582a55 <command_loop_2>, arg=...) at ../../src/eval.c:1080
#30 0x0000000000582a20 in command_loop () at ../../src/keyboard.c:1097
#31 0x0000000000581fd6 in recursive_edit_1 () at ../../src/keyboard.c:703
#32 0x00000000005821b5 in Frecursive_edit () at ../../src/keyboard.c:774
#33 0x000000000057ff33 in main (argc=4, argv=0x7fffffffe8a8) at ../../src/emacs.c:1659

Lisp Backtrace:
"internal-set-lisp-face-attribute" (0xffffb768)
"set-face-attribute" (0xffffbf80)
"font-setting-change-default-font" (0xffffc750)
"dynamic-setting-handle-config-changed-event" (0xffffcfe0)
"funcall-interactively" (0xffffcfd8)
"call-interactively" (0xffffd490)
"command-execute" (0xffffdcc8)
(gdb)

It's easy to spot `dynamic-setting-handle-config-changed-event' as the
source of this.

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Mon, Dec 19, 2016 at 10:43:37PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 19 Dec 2016 21:20:49 +0100
> > From: martin rudalics <rudalics@gmx.at>
> > CC: werner@suse.de, 25228@debbugs.gnu.org
> > 
> > IIUC all this ‘dynamic-setting-handle-config-changed-event’ mechanism is
> > about detecting changes applied to GConf and/or GSettings on the fly and
> > applying them to the running Emacs session.  Such configuration settings
> > should never override anything specified by the user in her .emacs.  The
> > mechanism was virtually inoperative for four years until Paul changed an
> > innocuous parameter descriptor.  So this mechanism has never been tested
> > in all those years ...
> 
> Can you describe how that mechanism is triggered by the offending
> change?

Just play around with eval-region/expression ... that is that I can switch with

  (font-setting-change-default-font ":0" t)

or

  (font-setting-change-default-font ":0" nil)

to the system default font settings and then with

  (custom-set-faces '(default ((t (:family "B&H LucidaTypewriter"
    :foundry "B&H" :slant normal :weight normal :height 110 :width normal)))))

IMHO it would be enough if the API below (custom-set-faces) would set
the default font used by (font-setting-change-default-font) ... or the
otherway around that (font-setting-change-default-font) would respect
the values specified by (custom-set-faces).

Debugging the code (font-setting-change-default-font) function shows with

   (setq frame-list (frames-on-display-list ":0"))
   (setq f (nth 0 frame-list))

to get the frame f that the face attribute is set correct

   (face-attribute 'default :font f 'default)

   #<font-object "-B&H-B&H LucidaTypewriter-normal-normal-normal-Sans-14-*-*-*-m-90-iso10646-1"> [2 times]

but using the outer call of font-get

   (font-get (face-attribute 'default :font f 'default) :user-spec)

results in

   "Monospace 11"

which is *not*  LucidaTypewriter. And as the call

   (frame-parameter f 'font-parameter)

returns nil the full call of the or switch

  (or (font-get (face-attribute 'default :font f 'default)
                               :user-spec)
                     (frame-parameter f 'font-parameter))

does return

   "Monospace 11"



Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 11:59:52 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: werner@suse.de, 25228@debbugs.gnu.org
> 
>  > Can you describe how that mechanism is triggered by the offending
>  > change?
> 
> Which one is "the offending change"?

The one whose commit caused this issue to arise, commit e65c307.

> If you reread the thread, you will
> see that there are controversial opinions.  Anyway, here we go.

Thanks, but that's not what I asked about.  I asked to describe how
the change after which this issue appeared causes it to appear.  IOW,
what does the current code do that wasn't done before e65c307, which
triggers this problem?

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 12:18:58 +0100
> From: "Dr. Werner Fink" <werner@suse.de>
> Cc: martin rudalics <rudalics@gmx.at>, 25228@debbugs.gnu.org
> 
> > Can you describe how that mechanism is triggered by the offending
> > change?
> 
> Just play around with eval-region/expression ... that is that I can switch with
> 
>   (font-setting-change-default-font ":0" t)
> 
> or
> 
>   (font-setting-change-default-font ":0" nil)
> 
> to the system default font settings and then with
> 
>   (custom-set-faces '(default ((t (:family "B&H LucidaTypewriter"
>     :foundry "B&H" :slant normal :weight normal :height 110 :width normal)))))

Thanks.  However, I don't have easy access to systems where this
problem happens, so I must examine the source code instead.  That is
why I asked to describe which code triggers this and how it started
affecting us after commit e65c307.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 >> Which one is "the offending change"?
 >
 > The one whose commit caused this issue to arise, commit e65c307.
 >
 >> If you reread the thread, you will
 >> see that there are controversial opinions.  Anyway, here we go.
 >
 > Thanks, but that's not what I asked about.  I asked to describe how
 > the change after which this issue appeared causes it to appear.  IOW,
 > what does the current code do that wasn't done before e65c307, which
 > triggers this problem?

Before e65c307 the disjunct

          (or (font-get (face-attribute 'default :font f 'default)
                    :user-spec)

in ‘font-setting-change-default-font’ always evaluated to nil.  After
e65c307 it returns some non-nil value and ‘frame-font’ gets set to that.

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

[-- Attachment #1.1: Type: text/plain, Size: 1503 bytes --]

On Tue, Dec 20, 2016 at 06:15:57PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 20 Dec 2016 12:18:58 +0100
> > From: "Dr. Werner Fink" <werner@suse.de>
> > Cc: martin rudalics <rudalics@gmx.at>, 25228@debbugs.gnu.org
> > 
> > > Can you describe how that mechanism is triggered by the offending
> > > change?
> > 
> > Just play around with eval-region/expression ... that is that I can switch with
> > 
> >   (font-setting-change-default-font ":0" t)
> > 
> > or
> > 
> >   (font-setting-change-default-font ":0" nil)
> > 
> > to the system default font settings and then with
> > 
> >   (custom-set-faces '(default ((t (:family "B&H LucidaTypewriter"
> >     :foundry "B&H" :slant normal :weight normal :height 110 :width normal)))))
> 
> Thanks.  However, I don't have easy access to systems where this
> problem happens, so I must examine the source code instead.  That is
> why I asked to describe which code triggers this and how it started
> affecting us after commit e65c307.

The only guess I have is that the correction had now enabled the :user-spec
key/attribute.  For a workaround I've change some lines of code in
lisp/dynamic-setting.el ... compare with the attached patch.

With this patch both the custom font if enabled in ~/.emacs as well as
the system font works here for GNU Emacs with GTK as well as with X11.


Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #1.2: emacs-25.1-custom-fonts.patch --]
[-- Type: text/x-patch, Size: 2479 bytes --]

Work around openSUSE bug #1016172
 
--
 lisp/dynamic-setting.el |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

--- lisp/dynamic-setting.el
+++ lisp/dynamic-setting.el	2016-12-20 16:17:30.100242946 +0000
@@ -33,6 +33,7 @@
 ;;; Customizable variables
 
 (declare-function font-get-system-font "xsettings.c" ())
+(declare-function font-face-attributes "font.c" (font &optional frame))
 
 (defvar font-use-system-font)
 
@@ -42,28 +43,29 @@ If DISPLAY-OR-FRAME is a frame, the disp
 
 If SET-FONT is non-nil, change the font for frames.  Otherwise re-apply the
 current form for the frame (i.e. hinting or somesuch changed)."
-  (let ((new-font (and (fboundp 'font-get-system-font)
-		       (font-get-system-font)))
-	(frame-list (frames-on-display-list display-or-frame)))
-    (when (and new-font (display-graphic-p display-or-frame))
+  (let ((system-font (and (fboundp 'font-get-system-font)
+                       (font-get-system-font)))
+        (frame-list (frames-on-display-list display-or-frame))
+	(user-font (face-attribute 'default :font)))
+    (when (and system-font (display-graphic-p display-or-frame))
       (clear-font-cache)
       (if set-font
 	  ;; Set the font on all current and future frames, as though
 	  ;; the `default' face had been "set for this session":
-	  (set-frame-font new-font nil frame-list)
+	  (if (not user-font)
+	      (set-frame-font system-font nil frame-list)
+	     (set-frame-font user-font nil frame-list))
 	;; Just redraw the existing fonts on all frames:
 	(dolist (f frame-list)
-	  (let ((frame-font
-		 (or (font-get (face-attribute 'default :font f 'default)
-			       :user-spec)
-		     (frame-parameter f 'font-parameter))))
+	  ;; (apply 'font-spec (font-face-attributes (font-get-system-font)))
+	  (let* ((frame-font
+		  (or (face-attribute 'default :font f 'default)
+		      (frame-parameter f 'font-parameter)))
+		 (font-attr (font-face-attributes frame-font)))
 	    (when frame-font
 	      (set-frame-parameter f 'font-parameter frame-font)
-	      (set-face-attribute 'default f
-				  :width 'normal
-				  :weight 'normal
-				  :slant 'normal
-				  :font frame-font))))))))
+	      (apply #'set-face-attribute 'default f 
+	      (set-face-attribute 'default font-attr)))))))))
 
 (defun dynamic-setting-handle-config-changed-event (event)
   "Handle config-changed-event on the display in EVENT.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

[-- Attachment #1.1: Type: text/plain, Size: 741 bytes --]

On Tue, Dec 20, 2016 at 05:41:39PM +0100, Werner Fink wrote:
> > why I asked to describe which code triggers this and how it started
> > affecting us after commit e65c307.
> 
> The only guess I have is that the correction had now enabled the :user-spec
> key/attribute.  For a workaround I've change some lines of code in
> lisp/dynamic-setting.el ... compare with the attached patch.
> 
> With this patch both the custom font if enabled in ~/.emacs as well as
> the system font works here for GNU Emacs with GTK as well as with X11.

Wrong version of the patch, this one seems to be better one ;)

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #1.2: emacs-25.1-custom-fonts.patch --]
[-- Type: text/x-patch, Size: 2439 bytes --]

Work around openSUSE bug #1016172
 
--
 lisp/dynamic-setting.el |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

--- lisp/dynamic-setting.el
+++ lisp/dynamic-setting.el	2016-12-20 16:51:49.533433283 +0000
@@ -33,6 +33,7 @@
 ;;; Customizable variables
 
 (declare-function font-get-system-font "xsettings.c" ())
+(declare-function font-face-attributes "font.c" (font &optional frame))
 
 (defvar font-use-system-font)
 
@@ -42,28 +43,28 @@ If DISPLAY-OR-FRAME is a frame, the disp
 
 If SET-FONT is non-nil, change the font for frames.  Otherwise re-apply the
 current form for the frame (i.e. hinting or somesuch changed)."
-  (let ((new-font (and (fboundp 'font-get-system-font)
-		       (font-get-system-font)))
-	(frame-list (frames-on-display-list display-or-frame)))
-    (when (and new-font (display-graphic-p display-or-frame))
+  (let ((system-font (and (fboundp 'font-get-system-font)
+                       (font-get-system-font)))
+        (frame-list (frames-on-display-list display-or-frame))
+	(user-font (face-attribute 'default :font)))
+    (when (and system-font (display-graphic-p display-or-frame))
       (clear-font-cache)
       (if set-font
 	  ;; Set the font on all current and future frames, as though
 	  ;; the `default' face had been "set for this session":
-	  (set-frame-font new-font nil frame-list)
+	  (if (not user-font)
+	      (set-frame-font system-font nil frame-list)
+	     (set-frame-font user-font nil frame-list))
 	;; Just redraw the existing fonts on all frames:
 	(dolist (f frame-list)
-	  (let ((frame-font
-		 (or (font-get (face-attribute 'default :font f 'default)
-			       :user-spec)
-		     (frame-parameter f 'font-parameter))))
+	  ;; (apply 'font-spec (font-face-attributes (font-get-system-font)))
+	  (let* ((frame-font
+		  (or (face-attribute 'default :font f 'default)
+		      (frame-parameter f 'font-parameter)))
+		 (font-attr (font-face-attributes frame-font)))
 	    (when frame-font
 	      (set-frame-parameter f 'font-parameter frame-font)
-	      (set-face-attribute 'default f
-				  :width 'normal
-				  :weight 'normal
-				  :slant 'normal
-				  :font frame-font))))))))
+	      (apply #'set-face-attribute 'default f font-attr))))))))
 
 (defun dynamic-setting-handle-config-changed-event (event)
   "Handle config-changed-event on the display in EVENT.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 17:25:11 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: werner@suse.de, 25228@debbugs.gnu.org
> 
> Before e65c307 the disjunct
> 
>           (or (font-get (face-attribute 'default :font f 'default)
>                     :user-spec)
> 
> in ‘font-setting-change-default-font’ always evaluated to nil.  After
> e65c307 it returns some non-nil value and ‘frame-font’ gets set to that.

And the value "Monospace 11" you quoted back then -- any idea where
does that come from?

Thanks.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Tue, Dec 20, 2016 at 07:06:50PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 20 Dec 2016 17:25:11 +0100
> > From: martin rudalics <rudalics@gmx.at>
> > CC: werner@suse.de, 25228@debbugs.gnu.org
> > 
> > Before e65c307 the disjunct
> > 
> >           (or (font-get (face-attribute 'default :font f 'default)
> >                     :user-spec)
> > 
> > in ‘font-setting-change-default-font’ always evaluated to nil.  After
> > e65c307 it returns some non-nil value and ‘frame-font’ gets set to that.
> 
> And the value "Monospace 11" you quoted back then -- any idea where
> does that come from?

AFAICS monospace font is used in src/xsettings.c as well as in src/xfns.c
and src/ftfont.c ... also the configure has set HAVE_XFT as well as HAVE_GCONF
to 1 ... and the function font-get-system-font does return the current
mono font and is used in lisp/dynamic-setting.el

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 >> Before e65c307 the disjunct
 >>
 >>            (or (font-get (face-attribute 'default :font f 'default)
 >>                      :user-spec)
 >>
 >> in ‘font-setting-change-default-font’ always evaluated to nil.  After
 >> e65c307 it returns some non-nil value and ‘frame-font’ gets set to that.
 >
 > And the value "Monospace 11" you quoted back then -- any idea where
 > does that come from?

No idea.  But when I run emacs -Q and evaluate

(font-get (face-attribute 'default :font (selected-frame) 'default) :user-spec)

I get "Monospace 11".

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 18:34:19 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: werner@suse.de, 25228@debbugs.gnu.org
> 
>  >> Before e65c307 the disjunct
>  >>
>  >>            (or (font-get (face-attribute 'default :font f 'default)
>  >>                      :user-spec)
>  >>
>  >> in ‘font-setting-change-default-font’ always evaluated to nil.  After
>  >> e65c307 it returns some non-nil value and ‘frame-font’ gets set to that.
>  >
>  > And the value "Monospace 11" you quoted back then -- any idea where
>  > does that come from?
> 
> No idea.  But when I run emacs -Q and evaluate
> 
> (font-get (face-attribute 'default :font (selected-frame) 'default) :user-spec)
> 
> I get "Monospace 11".

So all this disaster happens because 96.281588447653434 compares not
equal to 96, is that right?  Would the problem be solved, both for you
and for Werner, if we compare these values after rounding them to the
nearest integer?  It looks to me that xsettings.c reads the new value
as an integer to begin with, so it makes no sense to compare
fractional values.  And AFAIK about DPI (which is very little, and
nothing about Gsettings and Xft), the DPI values are always integers.

WDYT?

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 17:56:48 +0100
> From: "Dr. Werner Fink" <werner@suse.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 25228@debbugs.gnu.org
> 
> > The only guess I have is that the correction had now enabled the :user-spec
> > key/attribute.  For a workaround I've change some lines of code in
> > lisp/dynamic-setting.el ... compare with the attached patch.
> > 
> > With this patch both the custom font if enabled in ~/.emacs as well as
> > the system font works here for GNU Emacs with GTK as well as with X11.
> 
> Wrong version of the patch, this one seems to be better one ;)

Thanks.  However, this doesn't look like the right fix, because this:

> +  (let ((system-font (and (fboundp 'font-get-system-font)
> +                       (font-get-system-font)))
> +        (frame-list (frames-on-display-list display-or-frame))
> +	(user-font (face-attribute 'default :font)))
> +    (when (and system-font (display-graphic-p display-or-frame))
>        (clear-font-cache)
>        (if set-font
>  	  ;; Set the font on all current and future frames, as though
>  	  ;; the `default' face had been "set for this session":
> -	  (set-frame-font new-font nil frame-list)
> +	  (if (not user-font)
> +	      (set-frame-font system-font nil frame-list)
> +	     (set-frame-font user-font nil frame-list))

effectively disables the system-font feature, because

   (face-attribute 'default :font)

will always return non-nil.

So if my suggestion of rounding the DPI values before comparing them
fixes this for you, it sounds like a better solution to me.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > So all this disaster happens because 96.281588447653434 compares not
 > equal to 96, is that right?

Here ;-)

That's why I wanted Werner to counter-check.  And there was the original
author of this issue - Rostislav Svoboda.  IIRC I tried to contact him
once but he did not respond, anyway let's try again.

 > Would the problem be solved, both for you
 > and for Werner, if we compare these values after rounding them to the
 > nearest integer?  It looks to me that xsettings.c reads the new value
 > as an integer to begin with, so it makes no sense to compare
 > fractional values.  And AFAIK about DPI (which is very little, and
 > nothing about Gsettings and Xft), the DPI values are always integers.

Nothing guarantees that such a silly discrepancy does not show up
somehwere else.  But I certainly won't mind using this as workaround for
Emacs 25.2.

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 19:18:03 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: werner@suse.de, 25228@debbugs.gnu.org, rostislav.svoboda@gmail.com
> 
>  > So all this disaster happens because 96.281588447653434 compares not
>  > equal to 96, is that right?
> 
> Here ;-)
> 
> That's why I wanted Werner to counter-check.  And there was the original
> author of this issue - Rostislav Svoboda.  IIRC I tried to contact him
> once but he did not respond, anyway let's try again.

Thanks.

>  > Would the problem be solved, both for you
>  > and for Werner, if we compare these values after rounding them to the
>  > nearest integer?  It looks to me that xsettings.c reads the new value
>  > as an integer to begin with, so it makes no sense to compare
>  > fractional values.  And AFAIK about DPI (which is very little, and
>  > nothing about Gsettings and Xft), the DPI values are always integers.
> 
> Nothing guarantees that such a silly discrepancy does not show up
> somehwere else.

I'm not sure I understand what discrepancy you had in mind.  Can you
elaborate?

> But I certainly won't mind using this as workaround for Emacs 25.2.

If it works, sure.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 >> Nothing guarantees that such a silly discrepancy does not show up
 >> somehwere else.
 >
 > I'm not sure I understand what discrepancy you had in mind.  Can you
 > elaborate?

A discrepancy in one of the other settings investigated by
apply_xft_settings: Antialias, Hinting, RGBA, LCDFilter, Hintstyle.

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Rostislav Svoboda]

2016-12-20 19:39 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>> That's why I wanted Werner to counter-check.  And there was the original
>> author of this issue - Rostislav Svoboda.  IIRC I tried to contact him
>> once but he did not respond, anyway let's try again.
>
> Thanks.

I'm here!
By coincidence, I have the machine where the bug occurred right next to me
but I'm not sure if it is still reproducible.

Bost

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Rostislav Svoboda]

> I'm here!

Ok, I'm here but what should I do???

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > I'm here!

Glad you are!

 > By coincidence, I have the machine where the bug occurred right next to me
 > but I'm not sure if it is still reproducible.

If you can reproduce it, please tell us.  In either case you might want
to have a look at the thread starting with

https://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00557.html

and at the debugging session I described today in

http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-12/msg00888.html

Thanks, martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Tue, 20 Dec 2016 19:49:52 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: werner@suse.de, 25228@debbugs.gnu.org, rostislav.svoboda@gmail.com
> 
>  >> Nothing guarantees that such a silly discrepancy does not show up
>  >> somehwere else.
>  >
>  > I'm not sure I understand what discrepancy you had in mind.  Can you
>  > elaborate?
> 
> A discrepancy in one of the other settings investigated by
> apply_xft_settings: Antialias, Hinting, RGBA, LCDFilter, Hintstyle.

None of those are floating-point values, so I don't expect similar
problems with them.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
> Date: Tue, 20 Dec 2016 20:24:30 +0100
> Cc: martin rudalics <rudalics@gmx.at>, werner@suse.de, 25228@debbugs.gnu.org
> 
> > I'm here!
> 
> Ok, I'm here but what should I do???

If you have already reproduced the original problem, we'd like you to
apply a small patch and see if the problem goes away.  Is it okay?

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Rostislav Svoboda]

> If you have already reproduced the original problem

Yes! On that particular machine the test still fails on 88cdf14b37
(Sorry it took me while to test it. I was fighting with proxies)

> , we'd like you to
> apply a small patch and see if the problem goes away.  Is it okay?

Yes. Gladly.

Bost

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

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

 > Yes! On that particular machine the test still fails on 88cdf14b37
 > (Sorry it took me while to test it. I was fighting with proxies)
 >
 >> , we'd like you to
 >> apply a small patch and see if the problem goes away.  Is it okay?
 >
 > Yes. Gladly.

Please try the attached.

Thanks, martin

[-- Attachment #2: xsettings.diff --]
[-- Type: text/plain, Size: 668 bytes --]

diff --git a/src/xsettings.c b/src/xsettings.c
index d7af68f..6131f67 100644
--- a/src/xsettings.c
+++ b/src/xsettings.c
@@ -667,8 +667,12 @@ apply_xft_settings (struct x_display_info *dpyinfo,
     }
 #endif
 
-  if ((settings->seen & SEEN_DPI) != 0 && oldsettings.dpi != settings->dpi
-      && settings->dpi > 0)
+  if ((settings->seen & SEEN_DPI) != 0
+      && settings->dpi > 0
+      && ((oldsettings.dpi >= settings->dpi
+	   && (oldsettings.dpi - settings->dpi) > 2)
+	  || ((settings->dpi > oldsettings.dpi)
+	      && (settings->dpi - oldsettings.dpi) > 2)))
     {
       FcPatternDel (pat, FC_DPI);
       FcPatternAddDouble (pat, FC_DPI, settings->dpi);

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Tue, Dec 20, 2016 at 11:59:52AM +0100, martin rudalics wrote:
>  '(default ((t (:inherit nil :stipple nil :background "grey92" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 98 :width normal :foundry "unknown" :family "Droid Sans Mono")))))
> 
> The ":height 98" entry in this form before the offending change did set
> the "height of the default face in 1/10 pt" to 98.  After the offending
> change it is set to 113.  I have no idea what a "pt" is (and I have no
> idea what an "inch" is).  But from experience I know that the value of
> `window-font-height' for the root window of the initial frame is 15 for
> a default face height of 98 and 18 for a default face height of 113.


AFAIK pt are points aka 1/72 of 1 inch or in metric units 0.35278 mm
(and AFAIK the ANSI is member of the ISO but this is na other story:)

> 
> As a consequence of the offending change, the frame character height of
> my initial frame is now 18 instead of the desired 15.  In the following
> I will try to explain how this happened here.
> 
> [Werner - if you read this, please try to repeat it, maybe you get a
> completely different behavior.  I gdb one of my current versions of a
> GTK build of master, so the line numbers may be off wrt what you have
> (unfortunately, debugging the release version freezes GNU/Linux
> completely here and I have to turn off the power in order to restart
> it).]
> 
> I first visit the file xsettings.c in the .src directory and start the
> debugger via M-x gdb completing it to
> 
> gdb -i=mi /home/martin/emacs-git/quick/obj-gtk/src/emacs
> 
> which includes the path of my GTK executable.  Next in xsettings.c I
> move to line 611 which reads as
> 
>   memset (&oldsettings, 0, sizeof (oldsettings));
> 
> and set a breakpoint there.  Then I run the executable via
> 
> run -Q --load /home/martin/temp/default-face.el
> 
> and wait till the breakpoint is hit.  In the function where I set the
> breakpoint (apply_xft_settings) I now want to trigger the setting of the
> variable
> 
>       changed = true;
> 
> I do this by stepping via "n" and find that it happens on line 675
> because of oldsettings.dpi != settings->dpi: The old value was
> 96.281588447653434 while the new value is 96.  As a consequence, on line
> 701 a
> 
>       store_config_changed_event (Qfont_render,
> 				  XCAR (dpyinfo->name_list_element));

Hmmm ... after verifying this I've tried this patch
----------------------------------------------------------------------------
--- src/xsettings.c
+++ src/xsettings.c	2016-12-21 07:25:17.605036477 +0000
@@ -45,6 +45,7 @@ along with GNU Emacs.  If not, see <http
 #endif
 
 #ifdef HAVE_XFT
+#include <math.h>
 #include <X11/Xft/Xft.h>
 #endif
 
@@ -620,7 +621,11 @@ apply_xft_settings (struct x_display_inf
 #endif
   FcPatternGetInteger (pat, FC_LCD_FILTER, 0, &oldsettings.lcdfilter);
   FcPatternGetInteger (pat, FC_RGBA, 0, &oldsettings.rgba);
-  FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi);
+
+  if (FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi) == FcResultMatch)
+    {
+      oldsettings.dpi = round(oldsettings.dpi);
+    }
 
   if ((settings->seen & SEEN_AA) != 0 && oldsettings.aa != settings->aa)
     {
----------------------------------------------------------------------------

and indeed there is a change in the behaviour.  Without the custom font setting
now GNU Emacs window does not a resize anymore at open.  It simply starts with
the system font without changing its size at open its window.

Nevertheless, with the custom font setting and without my change in lisp/dynamic-setting.el
the resize event of the GNU Emacs window is back and still the system font is
used regardless what font has been customized in ~/.emacs

> [backtraces]
> 
> It's easy to spot `dynamic-setting-handle-config-changed-event' as the
> source of this.

Ack

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Wed, Dec 21, 2016 at 09:11:04AM +0100, Werner Fink wrote:
> On Tue, Dec 20, 2016 at 11:59:52AM +0100, martin rudalics wrote:
> 
> Hmmm ... after verifying this I've tried this patch
> ----------------------------------------------------------------------------
> --- src/xsettings.c
> +++ src/xsettings.c	2016-12-21 07:25:17.605036477 +0000
> @@ -45,6 +45,7 @@ along with GNU Emacs.  If not, see <http
>  #endif
>  
>  #ifdef HAVE_XFT
> +#include <math.h>
>  #include <X11/Xft/Xft.h>
>  #endif
>  
> @@ -620,7 +621,11 @@ apply_xft_settings (struct x_display_inf
>  #endif
>    FcPatternGetInteger (pat, FC_LCD_FILTER, 0, &oldsettings.lcdfilter);
>    FcPatternGetInteger (pat, FC_RGBA, 0, &oldsettings.rgba);
> -  FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi);
> +
> +  if (FcPatternGetDouble (pat, FC_DPI, 0, &oldsettings.dpi) == FcResultMatch)
> +    {
> +      oldsettings.dpi = round(oldsettings.dpi);
> +    }
>  
>    if ((settings->seen & SEEN_AA) != 0 && oldsettings.aa != settings->aa)
>      {
> ----------------------------------------------------------------------------
> 
> and indeed there is a change in the behaviour.  Without the custom font setting
> now GNU Emacs window does not a resize anymore at open.  It simply starts with
> the system font without changing its size at open its window.
> 
> Nevertheless, with the custom font setting and without my change in lisp/dynamic-setting.el
> the resize event of the GNU Emacs window is back and still the system font is
> used regardless what font has been customized in ~/.emacs
> 
> > [backtraces]
> > 
> > It's easy to spot `dynamic-setting-handle-config-changed-event' as the
> > source of this.
> 
> Ack

There seems to be also an other place where rounding does not fit. With system
font set, that is no custom font at all the height of the same font are different,
that is 

  (font-face-attributes (font-get-system-font))

results in

  (:family "Monospace" :height 110)

whereas 

  (font-face-attributes (face-attribute 'default :font))

shows

  (:family "Source Code Pro" :height 113 :weight normal :slant normal :width normal)

which is the same font (even over different channels) but different height. I've
verified this by using

  (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
  (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))

Would interesting how to compare the uperficial ifferent font face attributes
for the same font in (font-setting-change-default-font).

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > Nevertheless, with the custom font setting and without my change in lisp/dynamic-setting.el
 > the resize event of the GNU Emacs window is back and still the system font is
 > used regardless what font has been customized in ~/.emacs

In that case do you get a backtrace that includes
`dynamic-setting-handle-config-changed-event'?

martin

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > There seems to be also an other place where rounding does not fit. With system
 > font set, that is no custom font at all the height of the same font are different,
 > that is
 >
 >    (font-face-attributes (font-get-system-font))
 >
 > results in
 >
 >    (:family "Monospace" :height 110)
 >
 > whereas
 >
 >    (font-face-attributes (face-attribute 'default :font))
 >
 > shows
 >
 >    (:family "Source Code Pro" :height 113 :weight normal :slant normal :width normal)

I get "DejaVu Sans Mono" instead of "Source Code Pro" here and
identical values otherwise.

 > which is the same font (even over different channels) but different height. I've
 > verified this by using
 >
 >    (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
 >    (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))
 >
 > Would interesting how to compare the uperficial ifferent font face attributes
 > for the same font in (font-setting-change-default-font).

I'm missing you here.

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Rostislav Svoboda]

>>> , we'd like you to
>>> apply a small patch and see if the problem goes away.  Is it okay?
>>
>> Yes. Gladly.
>
> Please try the attached.

The patch works! The font-height stays the same.

FYI - this is most probably unrelated to the font-height problem, anyway:
1. On my "font-height-works" machine (Ubuntu 16.10) the first invocation of:
    ./src/emacs -q --eval "(set-face-attribute 'default nil :height 40)" &
creates a rather small frame (I mean gtk window). The consequent
invocations of this
command create frames of normal size.

2. On my "font-height-works" machine the command above produces warnings:

** (emacs:21762): WARNING **: Couldn't connect to accessibility bus:
Failed to connect to socket /tmp/dbus-CV9wAFvBnL: Connection refused

(emacs:21762): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
assertion 'extra_space >= 0' failed

where the "... Gtk-CRITICAL ..." line gets repeated

3. On my "font-height-buggy" machine (Ubuntu 16.10 in VirtBox under Windows 7) I
always get small frames of the same size and I never see any Gtk errors or
warnings.

Cheers Bost

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Wed, Dec 21, 2016 at 09:56:19AM +0100, martin rudalics wrote:
> 
> > which is the same font (even over different channels) but different height. I've
> > verified this by using
> >
> >    (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
> >    (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))
> >
> > Would interesting how to compare the uperficial ifferent font face attributes
> > for the same font in (font-setting-change-default-font).
> 
> I'm missing you here.

The problem is that I currently miss the possibilty to check that
both (custom-set-face) do actual load and scale the same font file
to the same values ... without performing both (custom-set-face) I
mean here.  Similar there is no way I see to do this attribute/value
comparision in lisp/dynamic-setting.el for the currently used font
and the system as well as the custom font.

Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Wed, Dec 21, 2016 at 09:48:56AM +0100, martin rudalics wrote:
> > Nevertheless, with the custom font setting and without my change in lisp/dynamic-setting.el
> > the resize event of the GNU Emacs window is back and still the system font is
> > used regardless what font has been customized in ~/.emacs
> 
> In that case do you get a backtrace that includes
> `dynamic-setting-handle-config-changed-event'?

The variable changed becomes changed due to the font changed

(gdb) 
~"638\t      changed = true;\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004da770",func="apply_xft_settings",args=[{name="settings",value="0x7fffffffc510"},{name="dpyinfo",value="0x166fe20"}],file="xsettings.c",fullname="/usr/src/werner/emacs/emacs-25.1/src/xsettings.c",line="638"},thread-id="1",stopped-threads="all",core="5"
(gdb) 
list
&"list\n"
~"633\t  if ((settings->seen & SEEN_HINTING) != 0\n"
~"634\t      && oldsettings.hinting != settings->hinting)\n"
~"635\t    {\n"
~"636\t      FcPatternDel (pat, FC_HINTING);\n"
~"637\t      FcPatternAddBool (pat, FC_HINTING, settings->hinting);\n"
~"638\t      changed = true;\n"
~"639\t      oldsettings.hinting = settings->hinting;\n"
~"640\t    }\n"
~"641\t  if ((settings->seen & SEEN_RGBA) != 0 && oldsettings.rgba != settings->rgba)\n"
~"642\t    {\n"

(gdb) 
~"646\t      changed = true;\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004da7bf",func="apply_xft_settings",args=[{name="settings",value="0x7fffffffc510"},{name="dpyinfo",value="0x166fe20"}],file="xsettings.c",fullname="/usr/src/werner/emacs/emacs-25.1/src/xsettings.c",line="646"},thread-id="1",stopped-threads="all",core="4"
(gdb) 
list
&"list\n"
~"641\t  if ((settings->seen & SEEN_RGBA) != 0 && oldsettings.rgba != settings->rgba)\n"
~"642\t    {\n"
~"643\t      FcPatternDel (pat, FC_RGBA);\n"
~"644\t      FcPatternAddInteger (pat, FC_RGBA, settings->rgba);\n"
~"645\t      oldsettings.rgba = settings->rgba;\n"
~"646\t      changed = true;\n"
~"647\t    }\n"
~"648\t\n"
~"649\t  /* Older fontconfig versions don't have FC_LCD_FILTER. */\n"
~"650\t  if ((settings->seen & SEEN_LCDFILTER) != 0\n"

(gdb) 
~"655\t      changed = true;\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004da80e",func="apply_xft_settings",args=[{name="settings",value="0x7fffffffc510"},{name="dpyinfo",value="0x166fe20"}],file="xsettings.c",fullname="/usr/src/werner/emacs/emacs-25.1/src/xsettings.c",line="655"},thread-id="1",stopped-threads="all",core="4"
(gdb) 
list
&"list\n"
~"650\t  if ((settings->seen & SEEN_LCDFILTER) != 0\n"
~"651\t      && oldsettings.lcdfilter != settings->lcdfilter)\n"
~"652\t    {\n"
~"653\t      FcPatternDel (pat, FC_LCD_FILTER);\n"
~"654\t      FcPatternAddInteger (pat, FC_LCD_FILTER, settings->lcdfilter);\n"
~"655\t      changed = true;\n"
~"656\t      oldsettings.lcdfilter = settings->lcdfilter;\n"
~"657\t    }\n"
~"658\t\n"
~"659\t#ifdef FC_HINT_STYLE\n"
^done
(gdb) 

(gdb) 
~"665\t      changed = true;\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004da85d",func="apply_xft_settings",args=[{name="settings",value="0x7fffffffc510"},{name="dpyinfo",value="0x166fe20"}],file="xsettings.c",fullname="/usr/src/werner/emacs/emacs-25.1/src/xsettings.c",line="665"},thread-id="1",stopped-threads="all",core="4"
(gdb) 
list
&"list\n"
~"660\t  if ((settings->seen & SEEN_HINTSTYLE) != 0\n"
~"661\t      && oldsettings.hintstyle != settings->hintstyle)\n"
~"662\t    {\n"
~"663\t      FcPatternDel (pat, FC_HINT_STYLE);\n"
~"664\t      FcPatternAddInteger (pat, FC_HINT_STYLE, settings->hintstyle);\n"
~"665\t      changed = true;\n"
~"666\t      oldsettings.hintstyle = settings->hintstyle;\n"
~"667\t    }\n"
~"668\t#endif\n"
~"669\t\n"
^done
(gdb) 

now breakpoint at x_new_font() and aftersome c I see with bt

~"\n"
~"Lisp Backtrace:\n"
~"\"internal-set-lisp-face-attribute\""
~" (0xffffa740)\n"
~"\"set-face-attribute\""
~" (0xffffa930)\n"
~"\"font-setting-change-default-font\""
~" (0xffffab50)\n"
~"\"dynamic-setting-handle-config-changed-event\""
~" (0xffffae00)\n"
~"\"funcall-interactively\""
~" (0xffffadf8)\n"
~"\"call-interactively\""

which is a hit

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Wed, 21 Dec 2016 09:47:46 +0100
> From: "Dr. Werner Fink" <werner@suse.de>
> Cc: martin rudalics <rudalics@gmx.at>, 25228@debbugs.gnu.org
> 
> There seems to be also an other place where rounding does not fit. With system
> font set, that is no custom font at all the height of the same font are different,
> that is 
> 
>   (font-face-attributes (font-get-system-font))
> 
> results in
> 
>   (:family "Monospace" :height 110)
> 
> whereas 
> 
>   (font-face-attributes (face-attribute 'default :font))
> 
> shows
> 
>   (:family "Source Code Pro" :height 113 :weight normal :slant normal :width normal)
> 
> which is the same font (even over different channels) but different height. I've
> verified this by using
> 
>   (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
>   (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))

I see nothing particularly surprising here: "Monospace" is a family,
of which Emacs selected one specific monospaced font.  Why do you see
this as a problem?

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
> Date: Wed, 21 Dec 2016 12:03:35 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, werner@suse.de, 25228@debbugs.gnu.org
> 
> >>> , we'd like you to
> >>> apply a small patch and see if the problem goes away.  Is it okay?
> >>
> >> Yes. Gladly.
> >
> > Please try the attached.
> 
> The patch works! The font-height stays the same.

Great, thanks for testing.

> FYI - this is most probably unrelated to the font-height problem, anyway:
> 1. On my "font-height-works" machine (Ubuntu 16.10) the first invocation of:
>     ./src/emacs -q --eval "(set-face-attribute 'default nil :height 40)" &
> creates a rather small frame (I mean gtk window). The consequent
> invocations of this
> command create frames of normal size.
> 
> 2. On my "font-height-works" machine the command above produces warnings:
> 
> ** (emacs:21762): WARNING **: Couldn't connect to accessibility bus:
> Failed to connect to socket /tmp/dbus-CV9wAFvBnL: Connection refused
> 
> (emacs:21762): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
> assertion 'extra_space >= 0' failed
> 
> where the "... Gtk-CRITICAL ..." line gets repeated
> 
> 3. On my "font-height-buggy" machine (Ubuntu 16.10 in VirtBox under Windows 7) I
> always get small frames of the same size and I never see any Gtk errors or
> warnings.

Not sure this is related to the issue at hand.

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Wed, 21 Dec 2016 13:08:26 +0100
> From: "Dr. Werner Fink" <werner@suse.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 25228@debbugs.gnu.org
> 
> ~"Lisp Backtrace:\n"
> ~"\"internal-set-lisp-face-attribute\""
> ~" (0xffffa740)\n"
> ~"\"set-face-attribute\""
> ~" (0xffffa930)\n"
> ~"\"font-setting-change-default-font\""
> ~" (0xffffab50)\n"
> ~"\"dynamic-setting-handle-config-changed-event\""
> ~" (0xffffae00)\n"
> ~"\"funcall-interactively\""
> ~" (0xffffadf8)\n"
> ~"\"call-interactively\""

This seems to indicate that a real font-changed event was received.
Can you look in your Gsettings and find where does this come from?

Anyway, how about if we simply introduce a defcustom that would
disable dynamic-setting-handle-config-changed-event from having any
effect?  Or maybe people who don't want this feature should be advised
to simply unbind this key binding:

  (define-key special-event-map [config-changed-event]
    'dynamic-setting-handle-config-changed-event)

WDYT?

In any case, Martin, I think you should install your patch on the
emacs-25 branch.

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Wed, Dec 21, 2016 at 07:24:03PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 21 Dec 2016 09:47:46 +0100
> > From: "Dr. Werner Fink" <werner@suse.de>
> > Cc: martin rudalics <rudalics@gmx.at>, 25228@debbugs.gnu.org
> > 
> > There seems to be also an other place where rounding does not fit. With system
> > font set, that is no custom font at all the height of the same font are different,
> > that is 
> > 
> >   (font-face-attributes (font-get-system-font))
> > 
> > results in
> > 
> >   (:family "Monospace" :height 110)
> > 
> > whereas 
> > 
> >   (font-face-attributes (face-attribute 'default :font))
> > 
> > shows
> > 
> >   (:family "Source Code Pro" :height 113 :weight normal :slant normal :width normal)
> > 
> > which is the same font (even over different channels) but different height. I've
> > verified this by using
> > 
> >   (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
> >   (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))
> 
> I see nothing particularly surprising here: "Monospace" is a family,
> of which Emacs selected one specific monospaced font.  Why do you see
> this as a problem?

I'm aware nevertheless ... why should an already loaded font be reloaded
with exactly the same attributes because it is not possible to detect that
equality  ... beside the rounding problems it is superfluous

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Wed, 21 Dec 2016 18:39:51 +0100
> From: "Dr. Werner Fink" <werner@suse.de>
> Cc: rudalics@gmx.at, 25228@debbugs.gnu.org
> 
> > >   (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
> > >   (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))
> > 
> > I see nothing particularly surprising here: "Monospace" is a family,
> > of which Emacs selected one specific monospaced font.  Why do you see
> > this as a problem?
> 
> I'm aware nevertheless ... why should an already loaded font be reloaded
> with exactly the same attributes because it is not possible to detect that
> equality  ... beside the rounding problems it is superfluous

Is it really reloaded?  How can you tell?

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > The patch works! The font-height stays the same.

Installed now for Emacs 25.2.

 > FYI - this is most probably unrelated to the font-height problem, anyway:
 > 1. On my "font-height-works" machine (Ubuntu 16.10) the first invocation of:
 >      ./src/emacs -q --eval "(set-face-attribute 'default nil :height 40)" &
 > creates a rather small frame (I mean gtk window).

With 40 lines though.  What did you expect?

 > The consequent
 > invocations of this
 > command create frames of normal size.

With "consequent invocations" you mean what?  C-x 5 2 here creates yet
another frame of the same size.  The size of the initial frame is
derived from the ‘height’ and ‘width’ frame parameters, if specified,
and the height of the default font.

 > 2. On my "font-height-works" machine the command above produces warnings:
 >
 > ** (emacs:21762): WARNING **: Couldn't connect to accessibility bus:
 > Failed to connect to socket /tmp/dbus-CV9wAFvBnL: Connection refused

No ideas about this one.

 > (emacs:21762): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
 > assertion 'extra_space >= 0' failed
 >
 > where the "... Gtk-CRITICAL ..." line gets repeated

gtk_distribute_natural_allocation is a pain.  You could try to set
‘frame-resize-pixelwise’ to t but I doubt that it will help.

 > 3. On my "font-height-buggy" machine (Ubuntu 16.10 in VirtBox under Windows 7) I
 > always get small frames of the same size and I never see any Gtk errors or
 > warnings.

The Windows API has no idea of window sizes based on the metrics of some
default font.  The "round frame sizes to multiples of the default font
height" paradigm is among the most irksome legacies the Emacs frame code
has to deal with.

martin

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > The problem is that I currently miss the possibilty to check that
 > both (custom-set-face) do actual load and scale the same font file
 > to the same values ... without performing both (custom-set-face) I
 > mean here.  Similar there is no way I see to do this attribute/value
 > comparision in lisp/dynamic-setting.el for the currently used font
 > and the system as well as the custom font.

What are the "both (custom-set-face)"?  Can you give me an example?

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > Anyway, how about if we simply introduce a defcustom that would
 > disable dynamic-setting-handle-config-changed-event from having any
 > effect?  Or maybe people who don't want this feature should be advised
 > to simply unbind this key binding:
 >
 >    (define-key special-event-map [config-changed-event]
 >      'dynamic-setting-handle-config-changed-event)

One variable that should help here but whose semantics I haven't been
able to grok is ‘font-use-system-font’.  It would be very helpful if
someone who uses the dynamic-setting code could tell us how it is
supposed to work.  Then we could decide how to en-/disable some of its
features.

 > In any case, Martin, I think you should install your patch on the
 > emacs-25 branch.

Done.

martin

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Thu, Dec 22, 2016 at 09:35:14AM +0100, martin rudalics wrote:
> > The problem is that I currently miss the possibilty to check that
> > both (custom-set-face) do actual load and scale the same font file
> > to the same values ... without performing both (custom-set-face) I
> > mean here.  Similar there is no way I see to do this attribute/value
> > comparision in lisp/dynamic-setting.el for the currently used font
> > and the system as well as the custom font.
> 
> What are the "both (custom-set-face)"?  Can you give me an example?

That was

  (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
  (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))

which in fact do show exactly the same font at the same attributes here.

Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Rostislav Svoboda]

>> The patch works! The font-height stays the same.
>
> Installed now for Emacs 25.2.

thx :)

>> FYI - this is most probably unrelated to the font-height problem, anyway:
>> 1. On my "font-height-works" machine (Ubuntu 16.10) the first invocation
>> of:
>>      ./src/emacs -q --eval "(set-face-attribute 'default nil :height 40)"
>> &
>> creates a rather small frame (I mean gtk window).
>
> With 40 lines though.  What did you expect?

I think it's better to show you some screenshots:

http://picpaste.com/first.png
Size is 522 x 486 - I think this is too small (a bug?)

http://picpaste.com/second-fdbVUcuU.png
Size is 762 x 695 pixels - expected size

>> 3. On my "font-height-buggy" machine (Ubuntu 16.10 in VirtBox under
>> Windows 7) I
>> always get small frames of the same size and I never see any Gtk errors or
>> warnings.
>
> The Windows API has no idea of window sizes based on the metrics of some
> default font.  The "round frame sizes to multiples of the default font
> height" paradigm is among the most irksome legacies the Emacs frame code
> has to deal with.

I run my emacs on Ubuntu 16.10 with Xfce installed in Virtual Machine running
on Windows 7. Is Windows API the culprit here? I don't think so.

Cheers Bost

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Eli Zaretskii]

> Date: Thu, 22 Dec 2016 09:35:19 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 25228@debbugs.gnu.org
> 
>  > Anyway, how about if we simply introduce a defcustom that would
>  > disable dynamic-setting-handle-config-changed-event from having any
>  > effect?  Or maybe people who don't want this feature should be advised
>  > to simply unbind this key binding:
>  >
>  >    (define-key special-event-map [config-changed-event]
>  >      'dynamic-setting-handle-config-changed-event)
> 
> One variable that should help here but whose semantics I haven't been
> able to grok is ‘font-use-system-font’.  It would be very helpful if
> someone who uses the dynamic-setting code could tell us how it is
> supposed to work.  Then we could decide how to en-/disable some of its
> features.

I agree, but I'm not sure we have anyone aboard who can tell.

Failing that, would unbinding the above solve the problem?  If so, we
could suggest that to people as workaround, until we find a proper
solution.

>  > In any case, Martin, I think you should install your patch on the
>  > emacs-25 branch.
> 
> Done.

Thanks.

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 >> What are the "both (custom-set-face)"?  Can you give me an example?
 >
 > That was
 >
 >    (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
 >    (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))
 >
 > which in fact do show exactly the same font at the same attributes here.

I'm still too dense to understand you.  Do you mean that one of these
has been implicitly specified in the GSettings file, the other in your
.emacs and although they would result in the same default character
height, Emacs detects a difference in ‘font-setting-change-default-font’
and switches to a larger font?

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 >>> FYI - this is most probably unrelated to the font-height problem, anyway:
 >>> 1. On my "font-height-works" machine (Ubuntu 16.10) the first invocation
 >>> of:
 >>>       ./src/emacs -q --eval "(set-face-attribute 'default nil :height 40)"
 >>> &
 >>> creates a rather small frame (I mean gtk window).
 >>
 >> With 40 lines though.  What did you expect?
 >
 > I think it's better to show you some screenshots:
 >
 > http://picpaste.com/first.png
 > Size is 522 x 486 - I think this is too small (a bug?)

I can't say - what does evaluating (frame-height) give - if you can read
it?

 > http://picpaste.com/second-fdbVUcuU.png
 > Size is 762 x 695 pixels - expected size

You mean the first picture was from a first invocation of Emacs and the
second picture from a second?  Funny.  Anyway - it's the menu bar.

I forgot for the umpteenth time where these GTK errors come from.  So
anybody who reads this please remember with me:

   Whenever you see in your Emacs session something like

   Gtk-CRITICAL **: gtk_distribute_natural_allocation:
   assertion 'extra_space >= 0' failed

   then most likely your GTK menubar has become too large for the
   (implicitly) specified frame width and GTK will deliberately widen
   your frame to make the menubar fit.

I haven't yet found out how to truncate menubars with GTK.

This behavior reaches its highest level of annoyance when switching
buffers in a window, a few menu bar items get added and the frame gets
wider ... I have to mention this in the Emacs 25.2 manual.

 >>> 3. On my "font-height-buggy" machine (Ubuntu 16.10 in VirtBox under
 >>> Windows 7) I
 >>> always get small frames of the same size and I never see any Gtk errors or
 >>> warnings.
 >>
 >> The Windows API has no idea of window sizes based on the metrics of some
 >> default font.  The "round frame sizes to multiples of the default font
 >> height" paradigm is among the most irksome legacies the Emacs frame code
 >> has to deal with.
 >
 > I run my emacs on Ubuntu 16.10 with Xfce installed in Virtual Machine running
 > on Windows 7. Is Windows API the culprit here? I don't think so.

I have no idea.  Does the menu bar fit there?

martin

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[martin rudalics]

 > I agree, but I'm not sure we have anyone aboard who can tell.

Neither am I.

 > Failing that, would unbinding the above solve the problem?

Forcefully.

 > If so, we
 > could suggest that to people as workaround, until we find a proper
 > solution.

Please do that.  Maybe in a way that people who simply wonder why their
default font settings all of a sudden get overridden do not have to
understand what's going on.  Something like "If you see this happen, put

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

into your .emacs.".

martin

bug#25228: [emacs-bug] bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Thu, Dec 22, 2016 at 06:44:45PM +0100, martin rudalics wrote:
> >> What are the "both (custom-set-face)"?  Can you give me an example?
> >
> > That was
> >
> >    (custom-set-faces '(default ((t (:family "Source Code Pro" :height 110 :weight normal :slant normal :width normal)))))
> >    (custom-set-faces '(default ((t (:family "Monospace" :height 110)))))
> >
> > which in fact do show exactly the same font at the same attributes here.
> 
> I'm still too dense to understand you.  Do you mean that one of these
> has been implicitly specified in the GSettings file, the other in your
> .emacs and although they would result in the same default character
> height, Emacs detects a difference in ‘font-setting-change-default-font’
> and switches to a larger font?

There is no difference and the first (custom-set-faces) is from ~/.emacs
and the second is caused by gconf ... it is the same used font with the
same attributes.

After(!) fixing the DPI rounding in xsettings.c switching between both lines
with eval-expression results in no visible difference

Werner

-- 
 Dr. Werner Fink -- Software Engineer Consultant
 SUSE Linux GmbH,  Maxfeldstraße 5,  90409 Nürnberg,  Germany
 DE370832343409169, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild,
 Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
 phone: +49-911-740-53-0,  fax: +49-911-3206727,  www.opensuse.org
---------------------------------------------------------------------------
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25228: 25.1; GNU emacs 25.1: custom-set-faces from init file ~/.emacs ignored

[Dr. Werner Fink]

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

On Thu, Dec 22, 2016 at 06:45:46PM +0100, martin rudalics wrote:
> > I agree, but I'm not sure we have anyone aboard who can tell.
> 
> Neither am I.
> 
> > Failing that, would unbinding the above solve the problem?
> 
> Forcefully.
> 
> > If so, we
> > could suggest that to people as workaround, until we find a proper
> > solution.
> 
> Please do that.  Maybe in a way that people who simply wonder why their
> default font settings all of a sudden get overridden do not have to
> understand what's going on.  Something like "If you see this happen, put
> 
> (define-key special-event-map [config-changed-event] 'ignore)
> 
> into your .emacs.".

Hmmm ... couldn't that be a line within the API for (custom-set-faces)

My guess is that the dynamic font changing feature might be there to support
switching system fonts with gconf/dconf at runtime(?).  This might happen
if such a change triggers an event

Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]