bug#59347: 29.0.50; `:family` face setting ignored

bug#59347: 29.0.50; `:family` face setting ignored

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

Package: Emacs
Version: 29.0.50


When I do:

    src/emacs -Q --eval \
        '(progn
           (custom-set-faces `(variable-pitch
                               ((t (:family "DejaVu Sans")))))
           (add-to-list `default-frame-alist
                        `(font . "-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*"))
           (font-lock-mode -1)
           (insert (propertize "hello" `face `variable-pitch)))'

I get "hello" shown in the same font as with the default face
(i.e. "misc-fixed") instead using DejaVu Sans.


        Stefan


 In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2022-11-05 built on pastel
Repository revision: 452771086a1638bd11bae3633a3c10d51c83d9f8
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable
 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign'
 PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
THREADS TOOLKIT_SCROLL_BARS WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LANG: fr_CH.UTF-8
  locale-coding-system: utf-8-unix

Major mode: InactiveMinibuffer

Minor modes in effect:
  shell-dirtrack-mode: t
  server-mode: t
  electric-pair-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  global-compact-docstrings-mode: t
  url-handler-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  global-prettify-symbols-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/monnier/src/emacs/nongnu/packages/geiser-kawa/geiser-kawa-autoloads hides /home/monnier/src/emacs/nongnu/packages/geiser-kawa/elisp/geiser-kawa-autoloads
/home/monnier/src/emacs/nongnu/packages/geiser/geiser-autoloads hides /home/monnier/src/emacs/nongnu/packages/geiser/elisp/geiser-autoloads
/home/monnier/src/emacs/nongnu/packages/arduino-mode/ob-arduino hides /home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ob-arduino
/home/monnier/src/emacs/nongnu/packages/org-contrib/org-contrib-autoloads hides /home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/org-contrib-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/magit-autoloads hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/git-commit-autoloads hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/git-commit-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/magit-pkg hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-pkg
/home/monnier/src/emacs/nongnu/packages/magit/magit-section-autoloads hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-section-autoloads
/home/monnier/src/emacs/nongnu/packages/magit/git-commit-pkg hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/git-commit-pkg
/home/monnier/src/emacs/nongnu/packages/magit/magit-section-pkg hides /home/monnier/src/emacs/nongnu/packages/magit/lisp/magit-section-pkg
/home/monnier/src/emacs/nongnu/packages/pdf-tools/pdf-tools-autoloads hides /home/monnier/src/emacs/nongnu/packages/pdf-tools/lisp/pdf-tools-autoloads
/home/monnier/src/emacs/nongnu/packages/php-mode/php-mode-autoloads hides /home/monnier/src/emacs/nongnu/packages/php-mode/lisp/php-mode-autoloads
/home/monnier/src/emacs/nongnu/packages/jade-mode/jade-mode hides /home/monnier/src/emacs/nongnu/packages/stylus-mode/jade-mode
/home/monnier/src/emacs/nongnu/packages/jade-mode/sws-mode hides /home/monnier/src/emacs/nongnu/packages/stylus-mode/sws-mode
/home/monnier/src/emacs/nongnu/packages/jade-mode/stylus-mode hides /home/monnier/src/emacs/nongnu/packages/stylus-mode/stylus-mode
/home/monnier/src/emacs/nongnu/packages/subed/subed-autoloads hides /home/monnier/src/emacs/nongnu/packages/subed/subed/subed-autoloads
/home/monnier/src/emacs/nongnu/packages/with-editor/with-editor-autoloads hides /home/monnier/src/emacs/nongnu/packages/with-editor/lisp/with-editor-autoloads
/home/monnier/src/emacs/elpa/packages/bbdb/bbdb-autoloads hides /home/monnier/src/emacs/elpa/packages/bbdb/lisp/bbdb-autoloads
/home/monnier/src/emacs/nongnu/packages/paredit/test hides /home/monnier/src/emacs/elpa/packages/easy-kill/test
/home/monnier/src/emacs/elpa/packages/embark-consult/embark-consult hides /home/monnier/src/emacs/elpa/packages/embark/embark-consult
/home/monnier/src/emacs/elpa/packages/embark-consult/embark hides /home/monnier/src/emacs/elpa/packages/embark/embark
/home/monnier/src/emacs/elpa/packages/embark-consult/avy-embark-collect hides /home/monnier/src/emacs/elpa/packages/embark/avy-embark-collect
/home/monnier/src/emacs/elpa/packages/embark-consult/embark-org hides /home/monnier/src/emacs/elpa/packages/embark/embark-org
/home/monnier/src/emacs/elpa/packages/ess/ess-autoloads hides /home/monnier/src/emacs/elpa/packages/ess/lisp/ess-autoloads
/home/monnier/src/emacs/nongnu/packages/forth-mode/build hides /home/monnier/src/emacs/elpa/packages/lentic/build
/home/monnier/src/emacs/nongnu/packages/paredit/test hides /home/monnier/src/emacs/elpa/packages/num3-mode/test
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/org-contacts hides /home/monnier/src/emacs/elpa/packages/org-contacts/org-contacts
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/org-notify hides /home/monnier/src/emacs/elpa/packages/org-notify/org-notify
/home/monnier/src/emacs/elpa/packages/realgud-lldb/cask-install hides /home/monnier/src/emacs/elpa/packages/realgud-trepan-ni/cask-install
/home/monnier/src/emacs/elpa/packages/realgud-lldb/cask-install hides /home/monnier/src/emacs/elpa/packages/realgud/cask-install
/home/monnier/src/emacs/elpa/packages/srht/srht-autoloads hides /home/monnier/src/emacs/elpa/packages/srht/lisp/srht-autoloads
/home/monnier/src/emacs/elpa/packages/taxy-magit-section/taxy-magit-section hides /home/monnier/src/emacs/elpa/packages/taxy/taxy-magit-section
/home/monnier/src/emacs/elpa/packages/transient/transient-autoloads hides /home/monnier/src/emacs/elpa/packages/transient/lisp/transient-autoloads
/home/monnier/src/emacs/nongnu/packages/mentor/url-scgi hides /home/monnier/src/emacs/elpa/packages/url-scgi/url-scgi
/home/monnier/src/emacs/elpa/packages/use-package/use-package-tests hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-tests
/home/monnier/src/emacs/elpa/packages/use-package/use-package-delight hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-delight
/home/monnier/src/emacs/elpa/packages/use-package/use-package-diminish hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-diminish
/home/monnier/src/emacs/elpa/packages/use-package/bind-chord hides /home/monnier/src/emacs/elpa/packages/bind-key/bind-chord
/home/monnier/src/emacs/elpa/packages/use-package/use-package-lint hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-lint
/home/monnier/src/emacs/elpa/packages/use-package/use-package-core hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-core
/home/monnier/src/emacs/elpa/packages/use-package/use-package-ensure hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-ensure
/home/monnier/src/emacs/elpa/packages/use-package/use-package-chords hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-chords
/home/monnier/src/emacs/elpa/packages/use-package/bind-key hides /home/monnier/src/emacs/elpa/packages/bind-key/bind-key
/home/monnier/src/emacs/elpa/packages/use-package/use-package-chords-tests hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-chords-tests
/home/monnier/src/emacs/elpa/packages/use-package/use-package-jump hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-jump
/home/monnier/src/emacs/elpa/packages/use-package/use-package hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package
/home/monnier/src/emacs/elpa/packages/use-package/use-package-bind-key hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-bind-key
/home/monnier/src/emacs/elpa/packages/use-package/use-package-ensure-system-package hides /home/monnier/src/emacs/elpa/packages/bind-key/use-package-ensure-system-package
/home/monnier/src/emacs/elpa/packages/hydra/hydra-test hides /home/monnier/src/emacs/elpa/packages/lv/hydra-test
/home/monnier/src/emacs/elpa/packages/hydra/hydra hides /home/monnier/src/emacs/elpa/packages/lv/hydra
/home/monnier/src/emacs/elpa/packages/hydra/lv hides /home/monnier/src/emacs/elpa/packages/lv/lv
/home/monnier/src/emacs/elpa/packages/hydra/hydra-ox hides /home/monnier/src/emacs/elpa/packages/lv/hydra-ox
/home/monnier/src/emacs/elpa/packages/hydra/hydra-examples hides /home/monnier/src/emacs/elpa/packages/lv/hydra-examples
/home/monnier/src/emacs/elpa/packages/ada-mode/gnat-core hides /home/monnier/src/emacs/elpa/packages/wisi/gnat-core
/home/monnier/src/emacs/elpa/packages/transient/lisp/transient hides /home/monnier/src/emacs/work/lisp/transient
/home/monnier/src/emacs/nongnu/packages/lua-mode/lua-mode hides /home/monnier/src/emacs/work/lisp/progmodes/lua-mode
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ob-julia hides /home/monnier/src/emacs/work/lisp/org/ob-julia
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ol-man hides /home/monnier/src/emacs/work/lisp/org/ol-man
/home/monnier/src/emacs/nongnu/packages/org-contrib/lisp/ox-koma-letter hides /home/monnier/src/emacs/work/lisp/org/ox-koma-letter
/home/monnier/.emacs.d/elpa/hyperbole-8.0.0/set hides /home/monnier/src/emacs/work/lisp/emacs-lisp/set
/home/monnier/src/emacs/work/lisp/keymap hides /home/monnier/src/emacs/work/lisp/emacs-lisp/keymap
/home/monnier/src/emacs/elpa/packages/landmark/landmark hides /home/monnier/src/emacs/work/lisp/obsolete/landmark
/home/monnier/src/emacs/elpa/packages/crisp/crisp hides /home/monnier/src/emacs/work/lisp/obsolete/crisp

Features:
(crm tuareg tuareg-compat tuareg-opam caml-types caml-help find-file
ert-x gud cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew
holidays holiday-loaddefs cal-french org-journal org-crypt cal-iso
diary-lib diary-loaddefs mule-util cal-move arc-mode archive-mode
markdown-mode edit-indirect nameless cus-edit edmacro kmacro picture
package-x css-mode color html5-schema rng-xsd xsd-regexp rng-cmpct
rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt
rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap sgml-mode
facemenu nxml-util nxml-enc xmltok rfc2104 network-stream nsm mailalias
smtpmail textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check rect shadow mail-extr emacsbug j-help reftex-ref epa-file
eglot array jsonrpc ert xref edebug shortdoc org-eldoc org-element
avl-tree generator ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe
ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail mail-source utf7 nnoo parse-time gnus-spec gnus-int gnus-range
gnus-win gnus nnheader range ol-docview ol-bibtex ol-bbdb ol-w3m ol-doi
org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob-core ob-eval org-table
oc-basic bibtex iso8601 org-keys oc org-loaddefs cal-menu calendar
cal-loaddefs texinfo texinfo-loaddefs dired-aux drupal/ispell
drupal/eldoc drupal/autoinsert drupal-mode cc-styles cc-align cc-engine
cc-langs cc-vars cc-defs sql view dired-x reftex-cite reftex-parse ielm
cus-start cus-load skeleton pp wid-edit descr-text face-remap
gitignore-mode conf-mode sort elpa-admin smerge-mode whitespace dabbrev
debug backtrace find-func ffap sm-c-mode wgrep grep vc-fossil vc-backup
vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc-got log-view
log-edit message sendmail yank-media puny rfc822 mml mml-sec epa derived
epg rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log vc-annotate
vc-dir ewoc vc copyright misearch multi-isearch bug-reference cl-print
diff autorevert imenu doc-view filenotify jka-compr image-mode exif
dired dired-loaddefs sh-script smie executable make-mode files-x vc-git
diff-mode easy-mmode vc-dispatcher filecache reftex-dcr reftex
reftex-loaddefs reftex-vars tex-mode shell drupal/pcomplete pcomplete
latexenc raku-detect server cl-extra time-date flymake-proc flymake
project compile text-property-search comint ansi-osc ansi-color noutline
outline flyspell ispell checkdoc lisp-mnt thingatpt elec-pair reveal
autoinsert savehist minibuf-eldef disp-table compact-docstrings corfu
afternoon-theme-autoloads alect-themes-autoloads ample-theme-autoloads
annotate-autoloads anti-zenburn-theme-autoloads apache-mode-autoloads
apropospriate-theme-autoloads arduino-mode-autoloads ede/auto eieio-base
better-jumper-autoloads bison-mode-autoloads boxquote-autoloads
buttercup-autoloads cdlatex-autoloads cider-autoloads
coffee-mode-autoloads corfu-terminal-autoloads crux-autoloads
cyberpunk-theme-autoloads cycle-at-point-autoloads d-mode-autoloads
dart-mode-autoloads diff-ansi-autoloads doc-show-inline-autoloads
dockerfile-mode-autoloads dracula-theme-autoloads drupal-mode-autoloads
edit-indirect-autoloads editorconfig-autoloads elixir-mode-autoloads
elpher-autoloads evil-anzu-autoloads anzu-autoloads evil-args-autoloads
evil-exchange-autoloads evil-goggles-autoloads
evil-indent-plus-autoloads evil-lisp-state-autoloads bind-map-autoloads
evil-matchit-autoloads evil-nerd-commenter-autoloads
evil-numbers-autoloads evil-visualstar-autoloads evil-autoloads
flymake-kondor-autoloads flymake-popon-autoloads focus-autoloads
forth-mode-autoloads free-keys-autoloads geiser-chez-autoloads
geiser-chibi-autoloads geiser-chicken-autoloads geiser-gambit-autoloads
geiser-gauche-autoloads geiser-guile-autoloads geiser-kawa-autoloads
geiser-mit-autoloads geiser-racket-autoloads geiser-impl help-fns
radix-tree help-mode geiser-custom geiser-base ring
geiser-stklos-autoloads git-modes-autoloads gnu-apl-mode-autoloads
gnuplot-autoloads go-mode-autoloads gotham-theme-autoloads
goto-chg-autoloads graphql-mode-autoloads gruvbox-theme-autoloads
autothemer-autoloads guru-mode-autoloads haskell-mode-autoloads
haskell-tng-mode-autoloads helm-autoloads helm-core-autoloads
highlight-parentheses-autoloads hl-block-mode-autoloads
htmlize-autoloads idle-highlight-mode-autoloads idris-mode-autoloads
iedit-autoloads inf-clojure-autoloads clojure-mode-autoloads
inf-ruby-autoloads inkpot-theme-autoloads j-mode-autoloads
jabber-autoloads jade-mode-autoloads jinja2-mode-autoloads
julia-mode-autoloads keycast-autoloads kotlin-mode-autoloads
lua-mode-autoloads markdown-mode-autoloads material-theme-autoloads
mentor-autoloads moe-theme-autoloads monokai-theme-autoloads
mpv-autoloads multiple-cursors-autoloads nasm-mode-autoloads
nginx-mode-autoloads nix-mode-autoloads oblivion-theme-autoloads
org-auto-tangle-autoloads org-drill-autoloads org-journal-autoloads
org-mime-autoloads org-present-autoloads org-superstar-autoloads
org-tree-slide-autoloads orgit-autoloads pacmacs-autoloads
paredit-autoloads parseedn-autoloads parseclj-autoloads
pcmpl-args-autoloads pcre2el-autoloads popon-autoloads popup-autoloads
projectile-autoloads proof-general-autoloads proof-site proof-autoloads
prop-menu-autoloads rainbow-delimiters-autoloads raku-mode-autoloads
recomplete-autoloads rfc-mode-autoloads rubocop-autoloads
rust-mode-autoloads sass-mode-autoloads haml-mode-autoloads
scala-mode-autoloads scroll-on-drag-autoloads scroll-on-jump-autoloads
sesman-autoloads shellcop-autoloads slime-autoloads macrostep-autoloads
sly-autoloads smartparens-autoloads solarized-theme-autoloads
spacemacs-theme-autoloads spell-fu-autoloads stylus-mode-autoloads
subatomic-theme-autoloads sweeprolog-autoloads swift-mode-autoloads
swsw-autoloads symbol-overlay-autoloads systemd-autoloads
tablist-autoloads tangotango-theme-autoloads telephone-line-autoloads
textile-mode-autoloads toc-org-autoloads tuareg-autoloads caml-autoloads
typescript-mode-autoloads ujelly-theme-autoloads undo-fu-autoloads
undo-fu-session-autoloads vc-fossil-autoloads vcomplete-autoloads
visual-fill-column-autoloads web-mode-autoloads webpaste-autoloads
wgrep-autoloads with-simulated-input-autoloads ws-butler-autoloads
xah-fly-keys-autoloads xml-rpc-autoloads yaml-mode-autoloads
yasnippet-snippets-autoloads zenburn-theme-autoloads zig-mode-autoloads
ace-window-autoloads ack-autoloads ada-mode-autoloads
ada-ref-man-autoloads adaptive-wrap-autoloads adjust-parens-autoloads
advice-patch-autoloads aggressive-completion-autoloads
aggressive-indent-autoloads agitate-autoloads ahungry-theme-autoloads
aircon-theme-autoloads all-autoloads ampc-autoloads arbitools-autoloads
assess-autoloads aumix-mode-autoloads auto-correct-autoloads
auto-overlays-autoloads bbdb-autoloads beacon-autoloads blist-autoloads
bluetooth-autoloads bnf-mode-autoloads boxy-headings-autoloads
boxy-headlines-autoloads brief-autoloads buffer-env-autoloads
buffer-expose-autoloads bug-hunter-autoloads cape-autoloads
capf-autosuggest-autoloads caps-lock-autoloads captain-autoloads
chess-autoloads clipboard-collector-autoloads cobol-mode-autoloads
code-cells-autoloads comint-mime-autoloads compact-docstrings-autoloads
company-ebdb-autoloads company-math-autoloads
company-statistics-autoloads company-autoloads consult-recoll-autoloads
context-coloring-autoloads corfu-doc-autoloads corfu-autoloads
coterm-autoloads counsel-autoloads cpio-mode-autoloads
cpupower-autoloads crdt-autoloads crisp-autoloads csharp-mode-autoloads
csv-mode-autoloads cursory-autoloads cycle-quotes-autoloads
darkroom-autoloads dbus-codegen-autoloads debbugs-autoloads
delight-autoloads denote-autoloads detached-autoloads devdocs-autoloads
dict-tree-autoloads diff-hl-autoloads diffview-autoloads
diminish-autoloads dired-du-autoloads dired-git-info-autoloads
disk-usage-autoloads dismal-autoloads djvu-autoloads doc-toc-autoloads
docbook-autoloads dts-mode-autoloads easy-escape-autoloads
easy-kill-autoloads ebdb-gnorb-autoloads cl-seq ebdb-i18n-chn-autoloads
ebdb-autoloads ediprolog-autoloads eev-autoloads ef-themes-autoloads
el-search-autoloads eldoc-eval-autoloads electric-spacing-autoloads
elisp-benchmarks-autoloads emacspeak-autoloads embark-consult-autoloads
consult-autoloads embark-autoloads ement-autoloads emms-autoloads
engrave-faces-autoloads enwc-autoloads epoch-view-autoloads
ergoemacs-mode-autoloads ess-autoloads excorporate-autoloads
expand-region-autoloads exwm-autoloads f90-interface-browser-autoloads
filladapt-autoloads flylisp-autoloads flymake-proselint-autoloads
fontaine-autoloads frame-tabs-autoloads frog-menu-autoloads
fsm-autoloads ftable-autoloads gcmh-autoloads ggtags-autoloads
gited-autoloads gle-mode-autoloads gnat-compiler-autoloads
gnome-c-style-autoloads gnorb-autoloads gnu-elpa-autoloads
gnu-elpa-features gnu-elpa-keyring-update-autoloads gnugo-autoloads
ascii-art-to-unicode-autoloads gnus-mock-autoloads gpastel-autoloads
graphql-autoloads greader-autoloads greenbar-autoloads
gtags-mode-autoloads guess-language-autoloads hcel-autoloads
hiddenquote-autoloads highlight-escape-sequences-autoloads
hook-helpers-autoloads html5-schema-autoloads ilist-autoloads
inspector-autoloads treeview-autoloads ioccur-autoloads
isearch-mb-autoloads iterators-autoloads ivy-avy-autoloads avy-autoloads
ivy-explorer-autoloads ivy-hydra-autoloads ivy-posframe-autoloads
javaimp-autoloads jgraph-mode-autoloads js2-mode-autoloads
json-mode-autoloads jumpc-autoloads kind-icon-autoloads kiwix-autoloads
request-autoloads kmb-autoloads landmark-autoloads leaf-autoloads
lentic-server-autoloads lentic-autoloads lex-autoloads lin-autoloads
lmc-autoloads load-dir-autoloads loccur-autoloads logos-autoloads
luwak-autoloads m-buffer-autoloads marginalia-autoloads
markchars-autoloads math-symbol-lists-autoloads mct-autoloads
memory-usage-autoloads metar-autoloads midi-kbd-autoloads
mines-autoloads minibuffer-header-autoloads minibuffer-line-autoloads
minimap-autoloads multi-mode-autoloads multishell-autoloads
muse-autoloads myers-autoloads nameless-autoloads names-autoloads
nano-agenda-autoloads nano-modeline-autoloads nano-theme-autoloads
nftables-mode-autoloads nhexl-mode-autoloads nlinum-autoloads
notes-mode-autoloads notmuch-indicator-autoloads num3-mode-autoloads
oauth2-autoloads ob-haxe-autoloads objed-autoloads omn-mode-autoloads
on-screen-autoloads orderless-autoloads org-contacts-autoloads
org-edna-autoloads org-modern-autoloads org-notify-autoloads
org-real-autoloads ol rx org-compat advice org-macs format-spec
boxy-autoloads org-remark-autoloads org-transclusion-autoloads
org-translate-autoloads orgalist-autoloads osc-autoloads osm-autoloads
other-frame-window-autoloads pabbrev-autoloads paced-autoloads
package-fixes-autoloads parsec-autoloads parser-generator-autoloads
path-iterator-autoloads peg-autoloads perl-doc-autoloads
persist-autoloads phps-mode-autoloads pinentry-autoloads poke-autoloads
poke-mode-autoloads poker-autoloads polymode-autoloads pq-autoloads
prefixed-core-autoloads psgml-autoloads pspp-mode-autoloads
pulsar-autoloads pyim-autoloads async-autoloads pyim-basedict-autoloads
quarter-plane-autoloads rainbow-mode-autoloads rbit-autoloads
rcirc-color-autoloads rcirc-menu-autoloads realgud-ipdb-autoloads
realgud-jdb-autoloads realgud-lldb-autoloads
realgud-node-debug-autoloads realgud-node-inspect-autoloads
realgud-trepan-ni-autoloads realgud-autoloads loc-changes-autoloads
load-relative-autoloads rec-mode-autoloads register-list-autoloads
relint-autoloads repology-autoloads rich-minority-autoloads
rmsbolt-autoloads rnc-mode-autoloads info rt-liberation-autoloads
rudel-autoloads rudel-interactive rudel-backend warnings icons
satchel-autoloads scanner-autoloads scroll-restore-autoloads
sed-mode-autoloads setup-autoloads shelisp-autoloads
shell-command+-autoloads shell-quasiquote-autoloads shen-mode-autoloads
sisu-mode-autoloads sketch-mode-autoloads slime-volleyball-autoloads
sm-c-mode-autoloads smalltalk-mode-autoloads smart-yank-autoloads
sml-mode-autoloads sokoban-autoloads sotlisp-autoloads spinner-autoloads
sql-beeline-autoloads sql-cassandra-autoloads sql-indent-autoloads
sql-smie-autoloads plz-autoloads ssh-deploy-autoloads stream-autoloads
svg-clock-autoloads svg-tag-mode-autoloads svg-lib-autoloads
swiper-autoloads ivy-autoloads system-packages-autoloads
taxy-magit-section-autoloads taxy-autoloads dash-autoloads
temp-buffer-browse-autoloads tempel-autoloads test-simple-autoloads
timerfunctions-autoloads tiny-autoloads tmr-autoloads toc-mode-autoloads
tomelr-autoloads topspace-autoloads tramp-nspawn-autoloads
tramp-theme-autoloads transcribe-autoloads transient-cycles-autoloads
trie-autoloads heap-autoloads tNFA-autoloads trinary-autoloads
finder-inf undo-tree-autoloads uni-confusables-autoloads
uniquify-files-autoloads url-http-ntlm-autoloads url-auth
url-scgi-autoloads use-package-autoloads bind-key-autoloads
validate-autoloads valign-autoloads vc-backup-autoloads compat-autoloads
vc-got-autoloads vc-hgcmd-autoloads vcard-autoloads vcl-mode-autoloads
vdiff-autoloads hydra-autoloads lv-autoloads vertico-posframe-autoloads
vertico-autoloads posframe-autoloads vigenere-autoloads
visual-filename-abbrev-autoloads visual-fill-autoloads vlf-autoloads
vundo-autoloads wcheck-mode-autoloads wconf-autoloads
web-server-autoloads webfeeder-autoloads websocket-autoloads
which-key-autoloads windower-autoloads windresize-autoloads
wisitoken-grammar-mode-autoloads mmm-mode-autoloads wisi-autoloads
wpuzzle-autoloads wrap-search-autoloads xclip-autoloads xelb-autoloads
xpm-autoloads queue-autoloads xr-autoloads
yasnippet-classic-snippets-autoloads yasnippet-autoloads zones-autoloads
ztree-autoloads zuul-autoloads ustar-withsub-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source eieio eieio-core cl-macs gv pcase password-cache
json subr-x map byte-opt bytecomp byte-compile url-vars cl-loaddefs
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 button
loaddefs theme-loaddefs oclosure cl-preloaded 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 x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 1373967 465408) (symbols 48 60127 306) (strings 32 283975 64620)
 (string-bytes 1 9145370) (vectors 16 187977)
 (vector-slots 8 4678227 999474) (floats 8 1693 1344)
 (intervals 56 102184 1671) (buffers 984 183))

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Thu, 17 Nov 2022 23:57:31 -0500
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When I do:
> 
>     src/emacs -Q --eval \
>         '(progn
>            (custom-set-faces `(variable-pitch
>                                ((t (:family "DejaVu Sans")))))
>            (add-to-list `default-frame-alist
>                         `(font . "-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*"))
>            (font-lock-mode -1)
>            (insert (propertize "hello" `face `variable-pitch)))'
> 
> I get "hello" shown in the same font as with the default face
> (i.e. "misc-fixed") instead using DejaVu Sans.

All those backquotes, are they really backquotes when you type this?
Or should they be escaped apostrophes?

More to the point, why do you think this is a bug in Emacs?  What
happened here is that you requested a face to use some font family,
and Emacs for whatever reasons decided not to use that family.  Why is
that a bug? why are you sure Emacs didn't do that for valid reasons?
Like, for example, that DejaVu Sans doesn't have a variant with the
size that matches the default face's font?

bug#59347: 29.0.50; `:family` face setting ignored

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

>>     src/emacs -Q --eval \
>>         '(progn
>>            (custom-set-faces `(variable-pitch
>>                                ((t (:family "DejaVu Sans")))))
>>            (add-to-list `default-frame-alist
>>                         `(font . "-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*"))
>>            (font-lock-mode -1)
>>            (insert (propertize "hello" `face `variable-pitch)))'
>> 
>> I get "hello" shown in the same font as with the default face
>> (i.e. "misc-fixed") instead using DejaVu Sans.
>
> All those backquotes, are they really backquotes when you type this?

Yes.

> Or should they be escaped apostrophes?

It's a pain in the rear to escape quotes from within quotes, so I use
backquotes instead, which works as well as long as there's no comma
nested inside :-)

> More to the point, why do you think this is a bug in Emacs?  What
> happened here is that you requested a face to use some font family,
> and Emacs for whatever reasons decided not to use that family.  Why is
> that a bug?  Why are you sure Emacs didn't do that for valid reasons?

I'm not.  I just can't see an obvious good reason for it.
I suspect I wouldn't be the only user who'd find this rather perplexing.

So let me return the question: what part of the above code makes you
think it's correct for Emacs to use a different font than the DejaVu Sans?

> Like, for example, that DejaVu Sans doesn't have a variant with the
> size that matches the default face's font?

DejaVu is a scalable font, so I can't see how it could not have a size
that matches.


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 59347@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 09:59:38 -0500
> 
> So let me return the question: what part of the above code makes you
> think it's correct for Emacs to use a different font than the DejaVu Sans?

The part where you requested a misc-fixed font.

> > Like, for example, that DejaVu Sans doesn't have a variant with the
> > size that matches the default face's font?
> 
> DejaVu is a scalable font, so I can't see how it could not have a size
> that matches.

Of course, it can.

And if it isn't because of size, it can be because of some other font
attribute, like weight.

Bottom line: you cannot expect Emacs to select a font from a family
you request, not with a 100% reliability anyway.  Emacs can decide not
to.

bug#59347: 29.0.50; `:family` face setting ignored

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

>> So let me return the question: what part of the above code makes you
>> think it's correct for Emacs to use a different font than the DejaVu Sans?
> The part where you requested a misc-fixed font.

I can't see how a "misc-fixed" default fault would prevent the use of
DejaVu Sans font for particular parts of the text.  This has worked for
the last 10 years or so, AFAIK.

>> > Like, for example, that DejaVu Sans doesn't have a variant with the
>> > size that matches the default face's font?
>> DejaVu is a scalable font, so I can't see how it could not have a size
>> that matches.
> Of course, it can.
> And if it isn't because of size, it can be because of some other font
> attribute, like weight.

I can't see which such attribute in my example would explain the
behavior I see.

> Bottom line: you cannot expect Emacs to select a font from a family
> you request, not with a 100% reliability anyway.  Emacs can decide
> not to.

I sense a bit of defensiveness in your responses.  I'm really trying to
fix an actual misbehavior in my config (one which at first sight looks
to me like a plain bug, or at least a plain regression).

What should I change in my recipe in order to keep the same default font
but get the DejaVu Sans that used to get?


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 59347@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 10:25:34 -0500
> 
> >> So let me return the question: what part of the above code makes you
> >> think it's correct for Emacs to use a different font than the DejaVu Sans?
> > The part where you requested a misc-fixed font.
> 
> I can't see how a "misc-fixed" default fault would prevent the use of
> DejaVu Sans font for particular parts of the text.  This has worked for
> the last 10 years or so, AFAIK.

So this recipe is something that stopped working recently?  Can you
tell when, or bisect?

> > Bottom line: you cannot expect Emacs to select a font from a family
> > you request, not with a 100% reliability anyway.  Emacs can decide
> > not to.
> 
> I sense a bit of defensiveness in your responses.

I'm just tired of investigating recipes that eventually lead nowhere.
The way Emacs approves and rejects fonts doesn't guarantee that a
request to use a given family will always be granted.  Moreover,
fontconfig setup on the user's platform is also relevant.

> I'm really trying to fix an actual misbehavior in my config (one
> which at first sight looks to me like a plain bug, or at least a
> plain regression).

It isn't.

> What should I change in my recipe in order to keep the same default font
> but get the DejaVu Sans that used to get?

The default font would be my guess.  Try using some other font, not
from the fixed-misc family.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Cc: 59347@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 18:54:02 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > What should I change in my recipe in order to keep the same default font
> > but get the DejaVu Sans that used to get?
> 
> The default font would be my guess.  Try using some other font, not
> from the fixed-misc family.

I take that back: I tried your recipe, and it works with every font I
tried except DejaVu Sans.  So I guess that font is the culprit, and
you should find some other font that you like.

Why DejaVu Sans is rejected, I donb't know, but that font has some
issues that we already discovered in the past, so it could be a good
idea to get rid of it regardless.

bug#59347: 29.0.50; `:family` face setting ignored

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

> So this recipe is something that stopped working recently?

I think so, yes (at least a similar setup in my config did).

> Can you tell when, or bisect?

Not sure when, yet.  Presumably within the last 2 months.
I'll try to bisect.

> I'm just tired of investigating recipes that eventually lead nowhere.
> The way Emacs approves and rejects fonts doesn't guarantee that a
> request to use a given family will always be granted.  Moreover,
> fontconfig setup on the user's platform is also relevant.

Is there some way I can ask Emacs for (something approximating) an
explanation of why that `:family` specification was ignored?

>> I'm really trying to fix an actual misbehavior in my config (one
>> which at first sight looks to me like a plain bug, or at least a
>> plain regression).
> It isn't.

For me it's definitely a regression: my favorite fonts aren't used as
I want them.

>> What should I change in my recipe in order to keep the same default font
>> but get the DejaVu Sans that used to get?
> The default font would be my guess.  Try using some other font, not
> from the fixed-misc family.

I don't really want another default font.
So far it's still the most legible monospace font at that size
(both horizontal and vertical) I have found.

> I take that back: I tried your recipe, and it works with every font I
> tried except DejaVu Sans.  So I guess that font is the culprit, and
> you should find some other font that you like.

That was my favorite so far for variable-pitch mixed with monospace.
And it worked fine until recently.

As far as I know it's a very widespread font, so it'd be good to know
more precisely where's the problem so we can hopefully get it fixed or
otherwise have a good justification.

Admittedly, https://dejavu-fonts.github.io/ says the last release of
that font was in 2016, so maybe it's not well maintained any more?

> Why DejaVu Sans is rejected, I donb't know, but that font has some
> issues that we already discovered in the past, so it could be a good
> idea to get rid of it regardless.

I'm looking at debbugs search for "dejavu sans" but can't see anything
that suggests a problem specific to that font (and those I find just
seem to be using "DejaVu Sans Mono" rather than "DejaVu Sans").
Do you remember particular instances?


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 59347@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 14:46:46 -0500
> 
> Is there some way I can ask Emacs for (something approximating) an
> explanation of why that `:family` specification was ignored?

The only way I know is to set font-log to nil before you do this, and
then look at the log.  But I have never learned anything useful from
that log.

> I'm looking at debbugs search for "dejavu sans" but can't see anything
> that suggests a problem specific to that font (and those I find just
> seem to be using "DejaVu Sans Mono" rather than "DejaVu Sans").
> Do you remember particular instances?

Look at the DejaVu Sans Mono issues, I think they are the same font,
basically.

Anyway, can you confirm that using other fonts instead of DejaVu Sans
does work?

bug#59347: 29.0.50; `:family` face setting ignored

[Yuan Fu]

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



> On Nov 18, 2022, at 9:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 59347@debbugs.gnu.org
>> Date: Fri, 18 Nov 2022 18:54:02 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>>> What should I change in my recipe in order to keep the same default font
>>> but get the DejaVu Sans that used to get?
>> 
>> The default font would be my guess.  Try using some other font, not
>> from the fixed-misc family.
> 
> I take that back: I tried your recipe, and it works with every font I
> tried except DejaVu Sans.  So I guess that font is the culprit, and
> you should find some other font that you like.
> 
> Why DejaVu Sans is rejected, I donb't know, but that font has some
> issues that we already discovered in the past, so it could be a good
> idea to get rid of it regardless.

I might have some more information, and here is a reproduce of what I see: 

Load these two (open source) fonts in to your machine, and emacs -Q -l reproduce.el

The content of reproduce.el is:

(pop-to-buffer
 (let ((font1 "IBM Plex Mono")
       (font2 "Charter"))
   (with-current-buffer (get-buffer-create "*test*")
     (set-face-attribute 'default nil
                         :font (font-spec :family font1
                                          :weight 'medium))
     (insert (propertize "Some Text\n" 'face `(:family ,font2)))
     (insert (propertize "Some Text"
                         'face `(:font ,(font-spec :family font2))))
     (current-buffer))))

It inserts two lines of text, both using font2, but the first line using :family and the second using :font. The one using :family is not displayed in font2 (it falls back to some other font), but the one using :font is.

I think this is because the default font (font1) uses medium weight, but font2 doesn’t have a medium weight. I tried with different fonts for font2, and whether that font has a medium weight correlates to whether the first line of text can be displayed in that font.

So my guess is that if the face uses the :family attribute, it inherits the weight from default, and if Emacs cannot find that weight in that font, it falls back to some other font.

I don’t know how to “fix” this, but at very least we should make it easy to figure out why the family attribute “didn’t work”. (It’s not unreasonable for someone to think: I have the font on my machine, the family settings is set to that font, why is the text not displayed in that font??)

Personally I think falling back to the same font but different weight is probably less confusing.

Yuan


[-- Attachment #2: reproduce.el --]
[-- Type: application/octet-stream, Size: 484 bytes --]

(pop-to-buffer
 (let ((font1 "IBM Plex Mono")
       (font2 "PragmataPro Mono"))
   (with-current-buffer (get-buffer-create "*test*")
     (set-face-attribute 'default nil
                         :font (font-spec :family font1
                                          :weight 'medium))
     (insert (propertize "Some Text\n" 'face `(:family ,font2)))
     (insert (propertize "Some Text"
                         'face `(:font ,(font-spec :family font2))))
     (current-buffer))))

[-- Attachment #3: IBMPlexMono-Medium.ttf --]
[-- Type: font/ttf, Size: 113392 bytes --]

[-- Attachment #4: Charter Regular.otf --]
[-- Type: font/otf, Size: 38716 bytes --]

[-- Attachment #5: Type: text/plain, Size: 3 bytes --]

bug#59347: 29.0.50; `:family` face setting ignored

[Yuan Fu]

> On Nov 18, 2022, at 12:00 PM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Nov 18, 2022, at 9:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>> Cc: 59347@debbugs.gnu.org
>>> Date: Fri, 18 Nov 2022 18:54:02 +0200
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> 
>>>> What should I change in my recipe in order to keep the same default font
>>>> but get the DejaVu Sans that used to get?
>>> 
>>> The default font would be my guess.  Try using some other font, not
>>> from the fixed-misc family.
>> 
>> I take that back: I tried your recipe, and it works with every font I
>> tried except DejaVu Sans.  So I guess that font is the culprit, and
>> you should find some other font that you like.
>> 
>> Why DejaVu Sans is rejected, I donb't know, but that font has some
>> issues that we already discovered in the past, so it could be a good
>> idea to get rid of it regardless.
> 
> I might have some more information, and here is a reproduce of what I see: 
> 
> Load these two (open source) fonts in to your machine, and emacs -Q -l reproduce.el
> 
> The content of reproduce.el is:
> 
> (pop-to-buffer
> (let ((font1 "IBM Plex Mono")
>       (font2 "Charter"))
>   (with-current-buffer (get-buffer-create "*test*")
>     (set-face-attribute 'default nil
>                         :font (font-spec :family font1
>                                          :weight 'medium))
>     (insert (propertize "Some Text\n" 'face `(:family ,font2)))
>     (insert (propertize "Some Text"
>                         'face `(:font ,(font-spec :family font2))))
>     (current-buffer))))
> 
> It inserts two lines of text, both using font2, but the first line using :family and the second using :font. The one using :family is not displayed in font2 (it falls back to some other font), but the one using :font is.
> 
> I think this is because the default font (font1) uses medium weight, but font2 doesn’t have a medium weight. I tried with different fonts for font2, and whether that font has a medium weight correlates to whether the first line of text can be displayed in that font.
> 
> So my guess is that if the face uses the :family attribute, it inherits the weight from default, and if Emacs cannot find that weight in that font, it falls back to some other font.
> 
> I don’t know how to “fix” this, but at very least we should make it easy to figure out why the family attribute “didn’t work”. (It’s not unreasonable for someone to think: I have the font on my machine, the family settings is set to that font, why is the text not displayed in that font??)
> 
> Personally I think falling back to the same font but different weight is probably less confusing.
> 
> Yuan
> 
> <reproduce.el><IBMPlexMono-Medium.ttf><Charter Regular.otf>

Basically the culprit in Stefan’s recipe is probably semicondensed rather than Dejavu.

Yuan

bug#59347: 29.0.50; `:family` face setting ignored

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

Stefan Monnier [2022-11-18 14:46:46] wrote:

>> So this recipe is something that stopped working recently?
>
> I think so, yes (at least a similar setup in my config did).
>
>> Can you tell when, or bisect?
>
> Not sure when, yet.  Presumably within the last 2 months.
> I'll try to bisect.

`git bisect` says:

    6b1ed2f2c99a1c2da56c5f434570c438cad6576d is the first bad commit
    commit 6b1ed2f2c99a1c2da56c5f434570c438cad6576d
    Author: Eli Zaretskii <eliz@gnu.org>
    Date:   Sat Aug 27 13:13:48 2022 +0300
    
        Fix antialias face attribute when text is scaled
        
        This restores the code we had in realize_gui_face before commit bf0d3f7.
        The problem described in bug#17973, which led to that commit, only
        happens if one uses a specific (misc-fixed) font family, not for
        the usual default fonts used by Emacs, and I'm not sure what's
        described there is a bug at all.  At least for the purposes of
        text-scale-adjust, it makes no sense to ignore the
        foundry/family/adstyle of the original font, because we _want_ the
        same (or very similar) font, just of a different size.
        
        And likely in other use cases: if the :font attribute of a face
        specifies some font properties, we want to keep them all, not
        arbitrarily to ignore some of them.  And definitely catering to an
        obscure use case such as the one cited in bug#17973 is NOT a good
        reason to make such radical changes in face-realization behavior.
        
        So I think backing out that part of commit bf0d3f7 is TRT, and if
        we decide that this causes bug#17973 in too many situations we care
        about, I'd rather find a kludge for that specific case than do that
        for every face realization.
        * src/xfaces.c (realize_gui_face): Preserve face attributes when
        text is scaled.  This reverts part of the changes installed in
        commit bf0d3f7.  (Bug#37473)
    
     src/xfaces.c | 27 +++------------------------
     1 file changed, 3 insertions(+), 24 deletions(-)

:-(

> The only way I know is to set font-log to nil before you do this, and
> then look at the log.  But I have never learned anything useful from
> that log.

:-(

> Anyway, can you confirm that using other fonts instead of DejaVu Sans
> does work?

I just tried with `Noto Sans`, `Verdana`, `STIX`, and `Courier New` and
none of them works (although they work with Emacs-28), so no
I can't confirm.


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

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

>> So my guess is that if the face uses the :family attribute, it
>> inherits the weight from default, and if Emacs cannot find that
>> weight in that font, it falls back to some other font.

But my `font` pattern doesn't specify a "weight".

>> Personally I think falling back to the same font but different weight
>> is probably less confusing.

Ignoring a "bold" setting would probably surprise/disappoint users just
as often.

> Basically the culprit in Stefan’s recipe is probably semicondensed
> rather than Dejavu.

Could be, indeed.  I don't actually care about the width of the font
when I request `DejaVu Sans`.  This said, if I use

    (:family "DejaVu Sans" :width normal)

I still don't get `DejaVu Sans` but I get a "normal" (hence wider)
misc-fixed instead :-(


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Package: Emacs
> Version: 29.0.50
>
>
> When I do:
>
>     src/emacs -Q --eval \
>         '(progn
>            (custom-set-faces `(variable-pitch
>                                ((t (:family "DejaVu Sans")))))
>            (add-to-list `default-frame-alist
>                         `(font . "-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*"))
>            (font-lock-mode -1)
>            (insert (propertize "hello" `face `variable-pitch)))'
>
> I get "hello" shown in the same font as with the default face
> (i.e. "misc-fixed") instead using DejaVu Sans.
>
>
>         Stefan
>
>
>  In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
>  version 1.16.0, Xaw3d scroll bars) of 2022-11-05 built on pastel
> Repository revision: 452771086a1638bd11bae3633a3c10d51c83d9f8

What happens if you revert xsettings.c to the state it was on the 1st of
October?

bug#59347: 29.0.50; `:family` face setting ignored

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

> What happens if you revert xsettings.c to the state it was on the 1st of
> October?

I used `master` and then

    git checkout 568920a5b703e80c43e1b6f31778ea5776218a1e -- src/xsettings.c

But the result behaves like `master` w.r.t to this problem (it does fix
the minibuffer-only frame's font bug#59371, OTOH).


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What happens if you revert xsettings.c to the state it was on the 1st of
>> October?
>
> I used `master` and then
>
>     git checkout 568920a5b703e80c43e1b6f31778ea5776218a1e -- src/xsettings.c
>
> But the result behaves like `master` w.r.t to this problem (it does fix
> the minibuffer-only frame's font bug#59371, OTOH).
>
>
>         Stefan

Thanks.  I should have a fix installed shortly.

bug#59347: 29.0.50; `:family` face setting ignored

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

Po Lu <luangruo@yahoo.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> What happens if you revert xsettings.c to the state it was on the 1st of
>>> October?
>>
>> I used `master` and then
>>
>>     git checkout 568920a5b703e80c43e1b6f31778ea5776218a1e -- src/xsettings.c
>>
>> But the result behaves like `master` w.r.t to this problem (it does fix
>> the minibuffer-only frame's font bug#59371, OTOH).
>>
>>
>>         Stefan
>
> Thanks.  I should have a fix installed shortly.

Would you please see whether or not it worked?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 59347@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 15:55:43 -0500
> 
> `git bisect` says:
> 
>     6b1ed2f2c99a1c2da56c5f434570c438cad6576d is the first bad commit
>     commit 6b1ed2f2c99a1c2da56c5f434570c438cad6576d
>     Author: Eli Zaretskii <eliz@gnu.org>
>     Date:   Sat Aug 27 13:13:48 2022 +0300
>     
>         Fix antialias face attribute when text is scaled

Then Emacs does here what we intended it to do: it tries to match the
variable-pitch font to the attributes of the default font.  And DejaVu
Sans fails that test on your system, because DejaVu Sans doesn't have
a variant with the font attributes that are present in misc-fixed font
you use as the default face's font.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  59347@debbugs.gnu.org
> Date: Fri, 18 Nov 2022 16:09:46 -0500
> 
> >> So my guess is that if the face uses the :family attribute, it
> >> inherits the weight from default, and if Emacs cannot find that
> >> weight in that font, it falls back to some other font.
> 
> But my `font` pattern doesn't specify a "weight".

Then it's some other attribute.

> >> Personally I think falling back to the same font but different weight
> >> is probably less confusing.
> 
> Ignoring a "bold" setting would probably surprise/disappoint users just
> as often.

Exactly.

> > Basically the culprit in Stefan’s recipe is probably semicondensed
> > rather than Dejavu.
> 
> Could be, indeed.  I don't actually care about the width of the font
> when I request `DejaVu Sans`.  This said, if I use
> 
>     (:family "DejaVu Sans" :width normal)
> 
> I still don't get `DejaVu Sans` but I get a "normal" (hence wider)
> misc-fixed instead :-(

The basic problem here is that we don't know which attributes to
ignore and which to enforce, first, because different users have
different preferences and expectations, and second, because the same
font selection routines are involved in many different use cases.  All
the attempts to resolve these issues till now boiled down to
arbitrarily ignoring some or even all attributes of the font whose
face is being modified by setting a different font, and that can never
be TRT.  If we can find a reasonable way to decide which attributes of
a font are important and which aren't, or maybe lax some of the
criteria for matching fonts to a font spec, that could solve at least
some of the problems.

bug#59347: 29.0.50; `:family` face setting ignored

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

Po Lu [2022-11-19 14:01:15] wrote:
> Would you please see whether or not it worked?

No, the `:family` setting is still ignored in my recipe.


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

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

> Then Emacs does here what we intended it to do: it tries to match the
> variable-pitch font to the attributes of the default font.  And DejaVu
> Sans fails that test on your system, because DejaVu Sans doesn't have
> a variant with the font attributes that are present in misc-fixed font
> you use as the default face's font.

Then maybe the problem is the following: I do not consider
`-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*` to include "please
use non-anti-aliased fonts", contrary to the `-fn monospace:antialias=0`
of bug#37473?

I'd actually be happier if Emacs could find an anti-aliased version
of misc-fixed :-)

The only part I could see that "collides" with "DejaVu Sans" is the
"semicondensed" part, but if I change my recipe to add `:width normal`,
I *still* don't get to see my variable-pitch text in DejaVu Sans.

Oh wait... I can recover the behavior I want by selecting

    :family "DejaVu Sans" :foundry "PfEd"

so the problem is the foundry info.  Changing the recipe to use

    -*-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*

doesn't help, OTOH (IOW Emacs insists on preserving the foundry even if
I did not explicitly request any particular foundry).

Does it make sense to preserve the `:foundry` attribute when the
`:family` is different?  I always thought of `:foundry` as a weird
detail which only makes sense when selecting a specific implementation
of a given `:family`.  In my experience the foundry is very rarely
used/exposed (e.g., I had no idea what was the foundry to use for
`DejaVu Sans` and I have no idea what "PfEd" means (but my web search
suggests it's not really a "foundry")), and it's rare to have
several foundries for the same font family.

Is there some way to say `:foundry any` in order to override the
default's foundry but without having to choose a particular foundry?


        Stefan


PS: Things become really weird with:

    src/emacs -Q --eval '(progn (custom-set-faces `(variable-pitch ((t (:family "DejaVu Sans" :foundry "*"))))) (add-to-list `default-frame-alist `(font . "-*-fixed-*-*-semicondensed-*-13-*-*-*-*-*-*-*")) (font-lock-mode -1) (insert (propertize "hello" `face `variable-pitch) " world"))'

where "hello" ends up with the following font:

    ftcrhb:-urw-Century Schoolbook L-medium-normal-normal-*-13-*-*-*-*-0-iso10646-1

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 59347@debbugs.gnu.org
> Date: Sat, 19 Nov 2022 09:55:29 -0500
> 
> > Then Emacs does here what we intended it to do: it tries to match the
> > variable-pitch font to the attributes of the default font.  And DejaVu
> > Sans fails that test on your system, because DejaVu Sans doesn't have
> > a variant with the font attributes that are present in misc-fixed font
> > you use as the default face's font.
> 
> Then maybe the problem is the following: I do not consider
> `-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*` to include "please
> use non-anti-aliased fonts", contrary to the `-fn monospace:antialias=0`
> of bug#37473?

Antialias attribute is just one of the attributes.  The problem is
much larger and more general than just that single attribute.

> Oh wait... I can recover the behavior I want by selecting
> 
>     :family "DejaVu Sans" :foundry "PfEd"
> 
> so the problem is the foundry info.  Changing the recipe to use
> 
>     -*-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*
> 
> doesn't help, OTOH (IOW Emacs insists on preserving the foundry even if
> I did not explicitly request any particular foundry).
> 
> Does it make sense to preserve the `:foundry` attribute when the
> `:family` is different?

I don't know; it might be.

> Is there some way to say `:foundry any` in order to override the
> default's foundry but without having to choose a particular foundry?

We will need to set it to nil where the font spec is passed to
font-selection functions, I guess.

But I'd be happier if you could step through the code and verified
that indeed the foundry mismatch is what causes us to reject DejaVu
Sans, and that after we reject it, we never try it with foundry set to
nil in the font-spec.  Perhaps we first set family to nil and only
after that set foundry to nil?

If this is indeed what happens, I'm okay with adding a variable that
could control whether we try to adhere to foundry in font selection,
and letting people try with it on and off.

Alternatively, why not document that including foundry in the font
spec is the solution to such problems?

> PS: Things become really weird with:
> 
>     src/emacs -Q --eval '(progn (custom-set-faces `(variable-pitch ((t (:family "DejaVu Sans" :foundry "*"))))) (add-to-list `default-frame-alist `(font . "-*-fixed-*-*-semicondensed-*-13-*-*-*-*-*-*-*")) (font-lock-mode -1) (insert (propertize "hello" `face `variable-pitch) " world"))'
> 
> where "hello" ends up with the following font:
> 
>     ftcrhb:-urw-Century Schoolbook L-medium-normal-normal-*-13-*-*-*-*-0-iso10646-1

Why is this weird?

bug#59347: 29.0.50; `:family` face setting ignored

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

> But I'd be happier if you could step through the code and verified
> that indeed the foundry mismatch is what causes us to reject DejaVu
> Sans, and that after we reject it, we never try it with foundry set to
> nil in the font-spec.  Perhaps we first set family to nil and only
> after that set foundry to nil?

I'll try that, tho I haven't looked at that code in quite a while, so
it'll take some time for me to figure out how&where to look.

>> PS: Things become really weird with:
>> 
>>     src/emacs -Q --eval '(progn (custom-set-faces `(variable-pitch ((t
>> (:family "DejaVu Sans" :foundry "*"))))) (add-to-list `default-frame-alist
>> `(font . "-*-fixed-*-*-semicondensed-*-13-*-*-*-*-*-*-*"))
>> (font-lock-mode -1) (insert (propertize "hello" `face `variable-pitch) "
>> world"))'
>> 
>> where "hello" ends up with the following font:
>> 
>>     ftcrhb:-urw-Century Schoolbook L-medium-normal-normal-*-13-*-*-*-*-0-iso10646-1
>
> Why is this weird?

To me this font comes literally out of nowhere.

AFAICT the only relevant face specifications at play here are the two
pieces of font-info in the recipe (and `face-font-family-alternatives`
but this doesn't seem to play any role).

So, how do we end up with the `Century Schoolbook L` family (rather
than either `fixed` or `DejaVu Sans` both of such seem just as
qualified)?

And if `urw` matches `*`, then why doesn't `PfEd` match it as well?


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 59347@debbugs.gnu.org
> Date: Sat, 19 Nov 2022 11:01:03 -0500
> 
> >> PS: Things become really weird with:
> >> 
> >>     src/emacs -Q --eval '(progn (custom-set-faces `(variable-pitch ((t
> >> (:family "DejaVu Sans" :foundry "*"))))) (add-to-list `default-frame-alist
> >> `(font . "-*-fixed-*-*-semicondensed-*-13-*-*-*-*-*-*-*"))
> >> (font-lock-mode -1) (insert (propertize "hello" `face `variable-pitch) "
> >> world"))'
> >> 
> >> where "hello" ends up with the following font:
> >> 
> >>     ftcrhb:-urw-Century Schoolbook L-medium-normal-normal-*-13-*-*-*-*-0-iso10646-1
> >
> > Why is this weird?
> 
> To me this font comes literally out of nowhere.

AFAIR, when we fail to find fonts that match the spec, we
progressively set more and more attributes to nil, so that in the end
we have all of them nil, and then the first font that matches the size
is fine.

> AFAICT the only relevant face specifications at play here are the two
> pieces of font-info in the recipe (and `face-font-family-alternatives`
> but this doesn't seem to play any role).

The other attributes come from the default face's font, I think.

> So, how do we end up with the `Century Schoolbook L` family (rather
> than either `fixed` or `DejaVu Sans` both of such seem just as
> qualified)?

I think if you step through the code, you will see it.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

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


Stefan, could you please try the attached patch and see if it fixes your 
problem?  (It does here, with your recipe.)

Eli, could you please review that patch?

Thanks.

[-- Attachment #2: Also-try-normal-weight-when-searching-a-font-with-me.patch --]
[-- Type: text/x-diff, Size: 4135 bytes --]

From ab7090e055b7c2043f9fdb07b760ae8b304fe02c Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Sun, 20 Nov 2022 13:50:47 +0000
Subject: [PATCH] Also try 'normal' weight when searching a font with 'medium'
 weight.

Between commits bf0d3f76dc (2014) and 6b1ed2f2c9 (2022),
realize_gui_face called font_load_for_lface with an empty or partly
emptied font spec, i.e. it ignored a part of its attrs argument.  The
rationale given in bug#17973, which led to bf0d3f76dc, is not clear.
In the meantime, commit 65fd3ca84f added support for the 'medium' font
weight, which was previously synonymous to 'normal'.

Together, the two commits 6b1ed2f2c9 and 65fd3ca84f lead to suboptimal
font choices.  When the font chosen for the default face has its
weight set to 'medium' and actually supports that weight,
font_load_for_lface will be called with a weight attribute set to
'medium' in spec for other faces.  However, fonts with an explicit
'medium' weight are much less common than fonts with an explicit
'normal' weight, which means that fonts that only support a 'normal'
weight are rejected, although they are close to the desired font.

Therefore, font_find_for_lface should also try the 'normal' weight
when the weight in spec is 'medium', after trying the 'medium' weight.

* src/font.c (font_find_for_lface): When the weight in SPEC is
'medium', also try the 'normal' weight.
---
 src/font.c | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/src/font.c b/src/font.c
index 6e720bc285..4222d60231 100644
--- a/src/font.c
+++ b/src/font.c
@@ -2959,9 +2959,9 @@ font_find_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec, int
 {
   Lisp_Object work;
   Lisp_Object entities, val;
-  Lisp_Object foundry[3], *family, registry[3], adstyle[3];
+  Lisp_Object foundry[3], *family, registry[3], adstyle[3], weight[3];
   int pixel_size;
-  int i, j, k, l;
+  int i, j, k, l, m;
   USE_SAFE_ALLOCA;
 
   /* Registry specification alternatives: from the most specific to
@@ -3081,6 +3081,17 @@ font_find_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec, int
 	}
     }
 
+  /* If weight is "medium" in SPEC, also try "normal".  Fonts with an
+     explicit "medium" weight are much less common than fonts with an
+     explicit "normal" weight, and for a long time "medium" and
+     "normal" (a.k.a. "regular" a.k.a. "book") were synonymous in
+     Emacs.  See e.g. bug#59347 and bug#57555.  */
+  weight[0] = AREF (spec, FONT_WEIGHT_INDEX);
+  if (EQ (weight[0], Qmedium))
+    weight[1] = Qnormal, weight[2] = zero_vector;
+  else
+    weight[1] = zero_vector;
+
   /* Now look up suitable fonts, from the most specific spec to the
      least specific spec.  Accept the first one that matches.  */
   for (i = 0; SYMBOLP (family[i]); i++)
@@ -3095,18 +3106,22 @@ font_find_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec, int
 	      for (l = 0; SYMBOLP (adstyle[l]); l++)
 		{
 		  ASET (work, FONT_ADSTYLE_INDEX, adstyle[l]);
-		  /* Produce the list of candidates for the spec in WORK.  */
-		  entities = font_list_entities (f, work);
-		  if (! NILP (entities))
+		  for (m = 0; SYMBOLP (weight[m]); m++)
 		    {
-		      /* If there are several candidates, select the
-			 best match for PIXEL_SIZE and attributes in ATTRS.  */
-		      val = font_select_entity (f, entities,
-						attrs, pixel_size, c);
-		      if (! NILP (val))
+		      ASET (work, FONT_WEIGHT_INDEX, weight[m]);
+		      /* Produce the list of candidates for the spec in WORK.  */
+		      entities = font_list_entities (f, work);
+		      if (! NILP (entities))
 			{
-			  SAFE_FREE ();
-			  return val;
+			  /* If there are several candidates, select the
+			     best match for PIXEL_SIZE and attributes in ATTRS.  */
+			  val = font_select_entity (f, entities,
+						    attrs, pixel_size, c);
+			  if (! NILP (val))
+			    {
+			      SAFE_FREE ();
+			      return val;
+			    }
 			}
 		    }
 		}
-- 
2.35.1

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 13:57:48 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 59347@debbugs.gnu.org
> 
> Stefan, could you please try the attached patch and see if it fixes your 
> problem?  (It does here, with your recipe.)
> 
> Eli, could you please review that patch?

I'd prefer to delay the discussion of this until after Stefan has time to
see why DejaVu Sans is rejected in his cases and describe his findings.

If you already did that, please describe your findings.  AFAIU, Stefan
discovered that the problematic attribute was foundry, and your patch does
nothing about foundry.  It sounds like your patch is for another problem
altogether.

A quick comment wrt the patch itself:

> +  /* If weight is "medium" in SPEC, also try "normal".  Fonts with an
> +     explicit "medium" weight are much less common than fonts with an
> +     explicit "normal" weight, and for a long time "medium" and
> +     "normal" (a.k.a. "regular" a.k.a. "book") were synonymous in
> +     Emacs.  See e.g. bug#59347 and bug#57555.  */
> +  weight[0] = AREF (spec, FONT_WEIGHT_INDEX);
> +  if (EQ (weight[0], Qmedium))
> +    weight[1] = Qnormal, weight[2] = zero_vector;
> +  else
> +    weight[1] = zero_vector;

This is not enough, IMO: you need to make sure the scoring of candidates is
still correct.  For example, if the weights of two candidates differ (normal
vs medium), but sizes are the same or close, how will that compare with
candidates whose weights are identical, but sizes differ?  IOW, we need to
reconsider how font_score scores the candidates.

Thanks.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> I'd prefer to delay the discussion of this until after Stefan has time 
> to see why DejaVu Sans is rejected in his cases and describe his 
> findings.
>
> If you already did that, please describe your findings.
>

It's described in the commit message.  DejaVu Sans is rejected because the 
font of the default face has a 'medium' weight, and DejaVu Sans (like many 
other fonts) does not explicitly support that weight.  For many fonts (and 
for Emacs until recently), normal, regular and medium are the same weight.

>
> AFAIU, Stefan discovered that the problematic attribute was foundry, and 
> and your patch does nothing about foundry.
>

I don't know how he reached that conclusion, but it's most likely not the 
cause of the problem.

>
> It sounds like your patch is for another problem altogether.
>

I don't think so, at least my intention was to fix this bug (and also at 
least bug#57555, which is the same one).

>> +  /* If weight is "medium" in SPEC, also try "normal".  Fonts with an
>> +     explicit "medium" weight are much less common than fonts with an
>> +     explicit "normal" weight, and for a long time "medium" and
>> +     "normal" (a.k.a. "regular" a.k.a. "book") were synonymous in
>> +     Emacs.  See e.g. bug#59347 and bug#57555.  */
>> +  weight[0] = AREF (spec, FONT_WEIGHT_INDEX);
>> +  if (EQ (weight[0], Qmedium))
>> +    weight[1] = Qnormal, weight[2] = zero_vector;
>> +  else
>> +    weight[1] = zero_vector;
>
> This is not enough, IMO: you need to make sure the scoring of candidates 
> is still correct.  For example, if the weights of two candidates differ 
> (normal vs medium), but sizes are the same or close, how will that 
> compare with candidates whose weights are identical, but sizes differ? 
> IOW, we need to reconsider how font_score scores the candidates.
>

I don't understand your question.  The patch essentially adds an inner 
loop in the loop of fond_find_for_lface, to make sure that when weight == 
medium, we call font_list_entities two times, first with

(family, foundry, registry, adstyle, weight == medium)

and then (if the previous call did not succeed to find a matching font, 
IOW, if it did not return nil) with

(family, foundry, registry, adstyle, weight == normal)

There is no scoring involved at that point, AFAIU.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 15:35:06 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > I'd prefer to delay the discussion of this until after Stefan has time 
> > to see why DejaVu Sans is rejected in his cases and describe his 
> > findings.
> >
> > If you already did that, please describe your findings.
> 
> It's described in the commit message.  DejaVu Sans is rejected because the 
> font of the default face has a 'medium' weight, and DejaVu Sans (like many 
> other fonts) does not explicitly support that weight.

Stefan said that he tried to change the weight, but that had no effect on
the problem.  So maybe what you see on your system is a different issue.

> > AFAIU, Stefan discovered that the problematic attribute was foundry, and 
> > and your patch does nothing about foundry.
> 
> I don't know how he reached that conclusion, but it's most likely not the 
> cause of the problem.

He described how he reached that conclusion in

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#65



> > This is not enough, IMO: you need to make sure the scoring of candidates 
> > is still correct.  For example, if the weights of two candidates differ 
> > (normal vs medium), but sizes are the same or close, how will that 
> > compare with candidates whose weights are identical, but sizes differ? 
> > IOW, we need to reconsider how font_score scores the candidates.
> >
> 
> I don't understand your question.  The patch essentially adds an inner 
> loop in the loop of fond_find_for_lface, to make sure that when weight == 
> medium, we call font_list_entities two times, first with
> 
> (family, foundry, registry, adstyle, weight == medium)
> 
> and then (if the previous call did not succeed to find a matching font, 
> IOW, if it did not return nil) with
> 
> (family, foundry, registry, adstyle, weight == normal)
> 
> There is no scoring involved at that point, AFAIU.

If we don't make font_score consistent with the change you made, we will
have other weird problems.  Maybe not in this particular case (although I'm
not sure even in this), but in others.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>>> AFAIU, Stefan discovered that the problematic attribute was foundry, 
>>> and and your patch does nothing about foundry.
>>
>> I don't know how he reached that conclusion, but it's most likely not 
>> the cause of the problem.
>
> He described how he reached that conclusion in
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#65
>

Thanks.  What he describes there looks like a workaround more than a 
solution to me.  The actual problem is that

-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*

selects

-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1

in which you see the 'medium' height.

>
> If we don't make font_score consistent with the change you made, we will 
> have other weird problems.  Maybe not in this particular case (although 
> I'm not sure even in this), but in others.
>

Thanks, I think I see what you mean now.  I overlooked the fact that 
font_select_entity is called with attrs and not with work, so indeed 
font_score called in font_sort_entities might reject (?) a legitimate 
font.  Is that what you mean?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 16:59:00 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#65
> >
> 
> Thanks.  What he describes there looks like a workaround more than a 
> solution to me.  The actual problem is that
> 
> -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*
> 
> selects
> 
> -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
> 
> in which you see the 'medium' height.

You mean weight, not height, right?

Does this font have a 'regular' weight?  If it does, why didn't Emacs choose
the 'regular' variant?

In any case, I don't understand how asking for a specific foundry can work
around the problem with weight.  If you do understand that, please tell the
details.

> > If we don't make font_score consistent with the change you made, we will 
> > have other weird problems.  Maybe not in this particular case (although 
> > I'm not sure even in this), but in others.
> 
> Thanks, I think I see what you mean now.  I overlooked the fact that 
> font_select_entity is called with attrs and not with work, so indeed 
> font_score called in font_sort_entities might reject (?) a legitimate 
> font.  Is that what you mean?

Yes.  We need to make sure the scoring will not now sometimes prefer the
medium weight where the regular weight exists and is a better match.  Not
only should it not reject a legitimate font, but also not prefer another
font due to this change.  IOW, the change should ideally only affect the
cases where the 'medium' weight doesn't exist, and we therefore prefer to
use 'regular' rather than reject the family.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
>>
>> in which you see the 'medium' height.
>
> You mean weight, not height, right?
>

Yes, sorry for the typo.

>
> Does this font have a 'regular' weight?  If it does, why didn't Emacs 
> choose the 'regular' variant?
>

Because the spec specified that it should find a medium variant.  So 
regular variants are rejected (because of 65fd3ca84f).

>
> In any case, I don't understand how asking for a specific foundry can 
> work around the problem with weight.  If you do understand that, please 
> tell the details.
>

I'd have to investigate this, is it really worth the effort given that a 
proper fix has already been found?

>>> If we don't make font_score consistent with the change you made, we 
>>> will have other weird problems.  Maybe not in this particular case 
>>> (although I'm not sure even in this), but in others.
>>
>> Thanks, I think I see what you mean now.  I overlooked the fact that 
>> font_select_entity is called with attrs and not with work, so indeed 
>> font_score called in font_sort_entities might reject (?) a legitimate 
>> font.  Is that what you mean?
>
> Yes.  We need to make sure the scoring will not now sometimes prefer the 
> medium weight where the regular weight exists and is a better match. 
> Not only should it not reject a legitimate font, but also not prefer 
> another font due to this change.  IOW, the change should ideally only 
> affect the cases where the 'medium' weight doesn't exist, and we 
> therefore prefer to use 'regular' rather than reject the family.
>

I don't think the case you have in mind could happen in the scenario of 
this bug or bug#57555 (if a regular weight exists and is a better match 
the loop in font_find_for_lface will exit with that better match), but 
indeed with some other call sequence this could perhaps happen.  I'll see 
what I can do.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 17:43:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > Does this font have a 'regular' weight?  If it does, why didn't Emacs 
> > choose the 'regular' variant?
> 
> Because the spec specified that it should find a medium variant.  So 
> regular variants are rejected (because of 65fd3ca84f).

No, the spec was -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*, so any
weight should be okay.  See Stefan's original recipe.

> > In any case, I don't understand how asking for a specific foundry can 
> > work around the problem with weight.  If you do understand that, please 
> > tell the details.
> 
> I'd have to investigate this, is it really worth the effort given that a 
> proper fix has already been found?

I'd like to hear Stefan say that this is fixed on his system as well.  And
yes, I'd still be interested in understanding why asking for another foundry
fixed or worked around the problem.

> > Yes.  We need to make sure the scoring will not now sometimes prefer the 
> > medium weight where the regular weight exists and is a better match. 
> > Not only should it not reject a legitimate font, but also not prefer 
> > another font due to this change.  IOW, the change should ideally only 
> > affect the cases where the 'medium' weight doesn't exist, and we 
> > therefore prefer to use 'regular' rather than reject the family.
> >
> 
> I don't think the case you have in mind could happen in the scenario of 
> this bug or bug#57555 (if a regular weight exists and is a better match 
> the loop in font_find_for_lface will exit with that better match), but 
> indeed with some other call sequence this could perhaps happen.  I'll see 
> what I can do.

Thanks, it's indeed the other cases that I worry about.  We had a lot of
changes in this area which solved one problem only to create others.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>>> Does this font have a 'regular' weight?  If it does, why didn't Emacs 
>>> choose the 'regular' variant?
>>
>> Because the spec specified that it should find a medium variant.  So 
>> regular variants are rejected (because of 65fd3ca84f).
>
> No, the spec was -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*, so 
> any weight should be okay.  See Stefan's original recipe.
>

It's the spec of the default face, so its realization takes place before 
the realization of the other one (DejaVu Sans), and the medium weight is 
selected.  When Emacs tries to realize the DejaVu Sans font, it sees that 
DejaVu Sans does not have a medium weight, and it is rejected.

>> I'd have to investigate this, is it really worth the effort given that 
>> a proper fix has already been found?
>
> I'd like to hear Stefan say that this is fixed on his system as well. 
> And yes, I'd still be interested in understanding why asking for another 
> foundry fixed or worked around the problem.
>

Okay, I'll try to find out if I have time.

>
> Thanks, it's indeed the other cases that I worry about.  We had a lot of 
> changes in this area which solved one problem only to create others.
>

If bug fixes did not create other bugs, programming wouldn't be fun, isn't 
it? ;-)

bug#59347: 29.0.50; `:family` face setting ignored

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

> Stefan, could you please try the attached patch and see if it fixes your
> problem?  (It does here, with your recipe.)

It works for me, indeed!


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 18:11:11 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > No, the spec was -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*, so 
> > any weight should be okay.  See Stefan's original recipe.
> 
> It's the spec of the default face, so its realization takes place before 
> the realization of the other one (DejaVu Sans), and the medium weight is 
> selected.

Yes, but why medium?  Is that the default (I don't think so)?

> > Thanks, it's indeed the other cases that I worry about.  We had a lot of 
> > changes in this area which solved one problem only to create others.
> 
> If bug fixes did not create other bugs, programming wouldn't be fun, isn't 
> it? ;-)

Of course.  I just think in this case we've had enough fun already.

bug#59347: 29.0.50; `:family` face setting ignored

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

>> I'd have to investigate this, is it really worth the effort given that a 
>> proper fix has already been found?
> I'd like to hear Stefan say that this is fixed on his system as well.

As mentioned in my other message, it does fix it for me.

> And yes, I'd still be interested in understanding why asking for
> another foundry fixed or worked around the problem.

Haven't found that out yet.

>> > Yes.  We need to make sure the scoring will not now sometimes prefer the 
>> > medium weight where the regular weight exists and is a better match. 
>> > Not only should it not reject a legitimate font, but also not prefer 
>> > another font due to this change.  IOW, the change should ideally only 
>> > affect the cases where the 'medium' weight doesn't exist, and we 
>> > therefore prefer to use 'regular' rather than reject the family.
[...]
> Thanks, it's indeed the other cases that I worry about.  We had a lot of
> changes in this area which solved one problem only to create others.

BTW, when scoring fonts, I'd expect that the different weights get
turned into a number and we then look at the difference between the
requested number and the font's number.  This way `medium` and `normal`
won't be considered as "equal" but "almost equal" [ tho, to be honest,
I have no idea which of `regular`, `normal`, and `medium` is supposed to
be heavier or lighter.  The same problem can affect the width attribute
where many of the possible choices seem to use just arbitrarily
different names for the same thing.  ]


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

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

> Thanks, it's indeed the other cases that I worry about.  We had a lot of
> changes in this area which solved one problem only to create others.

That's why I think we should make an effort to provide test cases (even
though it's clearly going to be tricky).


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Gregory Heytings <gregory@heytings.org>,  59347@debbugs.gnu.org
> Date: Sun, 20 Nov 2022 13:30:41 -0500
> 
> >> I'd have to investigate this, is it really worth the effort given that a 
> >> proper fix has already been found?
> > I'd like to hear Stefan say that this is fixed on his system as well.
> 
> As mentioned in my other message, it does fix it for me.

Good to know, thanks.

> > Thanks, it's indeed the other cases that I worry about.  We had a lot of
> > changes in this area which solved one problem only to create others.
> 
> BTW, when scoring fonts, I'd expect that the different weights get
> turned into a number and we then look at the difference between the
> requested number and the font's number.

We do that, yes.  But the problem is not the conversion to numbers, the
problem is the balance between the numerical value of a given difference in
weight vs the numerical value of a given difference in width or slant.  They
should follow some reasonable considerations of selecting suitable fonts in
various use cases.  When we start considering 'normal' in addition to
'medium', or vice versa, we introduce changes into the relative scores of
fonts, and the results could be not what we want.

> [ tho, to be honest,
> I have no idea which of `regular`, `normal`, and `medium` is supposed to
> be heavier or lighter.

See the beginning off font.c, where the numerical values we use are spelled
out.

> The same problem can affect the width attribute where many of the possible
> choices seem to use just arbitrarily different names for the same thing.

We score by values, not by names.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Gregory Heytings <gregory@heytings.org>,  59347@debbugs.gnu.org
> Date: Sun, 20 Nov 2022 13:31:52 -0500
> 
> > Thanks, it's indeed the other cases that I worry about.  We had a lot of
> > changes in this area which solved one problem only to create others.
> 
> That's why I think we should make an effort to provide test cases (even
> though it's clearly going to be tricky).

"Tricky"?  I don't even know how it would be possible.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>>> No, the spec was -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*, so 
>>> any weight should be okay.  See Stefan's original recipe.
>>
>> It's the spec of the default face, so its realization takes place 
>> before the realization of the other one (DejaVu Sans), and the medium 
>> weight is selected.
>
> Yes, but why medium?  Is that the default (I don't think so)?
>

Because -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-* only matches two 
weights: medium and bold.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> Stefan, could you please try the attached patch and see if it fixes 
>> your problem?  (It does here, with your recipe.)
>
> It works for me, indeed!
>

Great, thanks!

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 19:45:19 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> 
> >>> No, the spec was -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*, so 
> >>> any weight should be okay.  See Stefan's original recipe.
> >>
> >> It's the spec of the default face, so its realization takes place 
> >> before the realization of the other one (DejaVu Sans), and the medium 
> >> weight is selected.
> >
> > Yes, but why medium?  Is that the default (I don't think so)?
> >
> 
> Because -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-* only matches two 
> weights: medium and bold.

Where is that coded?  Or is that something general about semicondensed width
fonts?

bug#59347: 29.0.50; `:family` face setting ignored

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

Eli Zaretskii [2022-11-20 22:01:25] wrote:
>> Because -misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-* only matches two 
>> weights: medium and bold.
>
> Where is that coded?  Or is that something general about semicondensed width
> fonts?

It's simply a property of the `misc-fixed` font which only comes in two
variants of weight.


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>>> I'd have to investigate this, is it really worth the effort given that 
>>> a proper fix has already been found?
>> 
>> I'd like to hear Stefan say that this is fixed on his system as well. 
>> And yes, I'd still be interested in understanding why asking for 
>> another foundry fixed or worked around the problem.
>
> Okay, I'll try to find out if I have time.
>

Well, I cannot investigate this myself.  I just tried

src/emacs -Q --eval \
         '(progn
            (custom-set-faces `(variable-pitch
                                ((t (:family "DejaVu Sans" :foundry "PfEd")))))
            (add-to-list `default-frame-alist
                         `(font . "-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*"))
            (font-lock-mode -1)
            (insert (propertize "hello" `face `variable-pitch)))'

and the font I got is 
-PfEd-Terminus-medium-normal-normal-*-12-*-*-*-c-*-iso10646-1.  I removed 
the Terminus font from my system, and I got "no font available".

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>>> Yes.  We need to make sure the scoring will not now sometimes prefer 
>>> the medium weight where the regular weight exists and is a better 
>>> match. Not only should it not reject a legitimate font, but also not 
>>> prefer another font due to this change.  IOW, the change should 
>>> ideally only affect the cases where the 'medium' weight doesn't exist, 
>>> and we therefore prefer to use 'regular' rather than reject the 
>>> family.
>>
>> I don't think the case you have in mind could happen in the scenario of 
>> this bug or bug#57555 (if a regular weight exists and is a better match 
>> the loop in font_find_for_lface will exit with that better match), but 
>> indeed with some other call sequence this could perhaps happen.  I'll 
>> see what I can do.
>
> Thanks, it's indeed the other cases that I worry about.  We had a lot of 
> changes in this area which solved one problem only to create others.
>

After looking at this a bit closer, I don't see how font_score could be 
changed, or even why it should be changed.  It has only two callers: 
font_match_p and font_sort_entities.  The former only checks whether its 
return value is > 0 (IOW it only checks whether the font is an exact match 
or not).  The latter has only two callers: list-font and 
font_select_entity.  The latter has only one caller: font_find_for_lface. 
So it seems to me that there are no execution paths that could be 
negatively affected by this change (which is in font_find_for_lface).

Also, AFAIU, a font whose weight == spec_prop[weight] is in principle 
preferred to a font whose weight != spec_prop[weight].  However, a font 
whose weight != spec_prop[weight] could in practice be preferred to a font 
whose weight == spec_prop[weight] when it is a better match according to 
the other sorting criteria (size and width, and possibly type and slant). 
How could (and why should) this be changed to make sure that the scoring 
will not sometimes prefer the medium weight when the regular weight 
exists?

I'm probably missing something, but what?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 20:45:15 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> >> And yes, I'd still be interested in understanding why asking for 
> >> another foundry fixed or worked around the problem.
> >
> > Okay, I'll try to find out if I have time.
> >
> 
> Well, I cannot investigate this myself.  I just tried
> 
> src/emacs -Q --eval \
>          '(progn
>             (custom-set-faces `(variable-pitch
>                                 ((t (:family "DejaVu Sans" :foundry "PfEd")))))
>             (add-to-list `default-frame-alist
>                          `(font . "-misc-fixed-*-r-semicondensed-*-13-*-*-*-*-*-*-*"))
>             (font-lock-mode -1)
>             (insert (propertize "hello" `face `variable-pitch)))'
> 
> and the font I got is 
> -PfEd-Terminus-medium-normal-normal-*-12-*-*-*-c-*-iso10646-1.  I removed 
> the Terminus font from my system, and I got "no font available".

Thanks for trying.  I guess we will have to wait for Stefan to dig into what
happens on his system.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Sun, 20 Nov 2022 21:49:46 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> Also, AFAIU, a font whose weight == spec_prop[weight] is in principle 
> preferred to a font whose weight != spec_prop[weight].  However, a font 
> whose weight != spec_prop[weight] could in practice be preferred to a font 
> whose weight == spec_prop[weight] when it is a better match according to 
> the other sorting criteria (size and width, and possibly type and slant). 
> How could (and why should) this be changed to make sure that the scoring 
> will not sometimes prefer the medium weight when the regular weight 
> exists?

I thought the answer to your question would be "adjust the scoring such that
what we don't want to happen, doesn't".

One way of doing that is by boosting the score when there's an exact match
in attributes which we consider "more equal than others".  I guess weight is
one of them, and perhaps the only one.

Btw, another conceptual issue I have with your patch is that it treats
'medium' and 'regular' asymmetrically (AFAIU): if we see 'medium', we also
consider 'normal', but not vice versa.  Why the asymmetry? why not always
consider the other when we see the one?

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> Also, AFAIU, a font whose weight == spec_prop[weight] is in principle 
>> preferred to a font whose weight != spec_prop[weight].  However, a font 
>> whose weight != spec_prop[weight] could in practice be preferred to a 
>> font whose weight == spec_prop[weight] when it is a better match 
>> according to the other sorting criteria (size and width, and possibly 
>> type and slant). How could (and why should) this be changed to make 
>> sure that the scoring will not sometimes prefer the medium weight when 
>> the regular weight exists?
>
> I thought the answer to your question would be "adjust the scoring such 
> that what we don't want to happen, doesn't".
>
> One way of doing that is by boosting the score when there's an exact 
> match in attributes which we consider "more equal than others".  I guess 
> weight is one of them, and perhaps the only one.
>

Hmmm...  AFAIU that's already the case: when there's an exact match (e.g. 
we're expecting a medium font and the font is medium) the weight field for 
that font is 0, and when there's an inexact match (e.g. we're expecting a 
medium font and the font is regular) we store the difference between the 
two weights (which is 20 in this case) in the weight field.

It does not seem possible (at least not without adding a lot of 
complexity) inside font_score to know that the font only has a medium 
variant and that if we're expecting a regular font, we should therefore 
consider that the font is an exact (or "less inexact than if the font had 
a regular variant") match.  And, even if we don't do that, in that case 
and similar ones a medium variant will be better scored than a semi-bold 
or semi-light one.

All in all, it seems to me that we should not change font_score now.

>
> Btw, another conceptual issue I have with your patch is that it treats 
> 'medium' and 'regular' asymmetrically (AFAIU): if we see 'medium', we 
> also consider 'normal', but not vice versa.  Why the asymmetry? why not 
> always consider the other when we see the one?
>

That's correct, indeed.  The reason (which is perhaps not convincing 
enough?) is that fonts with an explicit 'medium' variant are less common 
than fonts with an explicit 'normal' variant.  So if we're trying to find 
a 'normal' font, the likelihood that a 'medium' font would be a better 
match than a 'normal' font is low.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Mon, 21 Nov 2022 14:48:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> All in all, it seems to me that we should not change font_score now.

OK, thanks.

> > Btw, another conceptual issue I have with your patch is that it treats 
> > 'medium' and 'regular' asymmetrically (AFAIU): if we see 'medium', we 
> > also consider 'normal', but not vice versa.  Why the asymmetry? why not 
> > always consider the other when we see the one?
> >
> 
> That's correct, indeed.  The reason (which is perhaps not convincing 
> enough?) is that fonts with an explicit 'medium' variant are less common 
> than fonts with an explicit 'normal' variant.  So if we're trying to find 
> a 'normal' font, the likelihood that a 'medium' font would be a better 
> match than a 'normal' font is low.

I understand, but are there any downsides to making it symmetrical?

My only other comment is that perhaps the consideration of 'regular' when
'medium' was required (or vice versa) should be controlled by a variable
that people could tweak from Lisp.  This would help us if this change
causes, or is suspected to cause, some regression in some case.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

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


I did some further testing to answer your previous email, and I now think 
that my previous patch is a half-measure, and that TRT would be to simply 
ignore the font weight specified in the default face while searching for 
other fonts.  Consider the following recipe:

emacs -Q
M-: (fancy-startup-screen) RET

and now evaluate the following lines in turn:

(set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-heavy) ;; 1
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'heavy) ;; 2
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-bold) ;; 3
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'bold) ;; 4
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-bold) ;; 5
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium) ;; 6
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'normal) ;; 7
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-light) ;; 8
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'light) ;; 9
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-light) ;; 10
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'thin) ;; 11

(If you don't have the Source Code Pro font on your system, I'm sure you 
can find another font with more weight variants with which you will 
observe a similar effect.)

With current master, the variable-pitch face is realized as follows:

- with 1-3: -ADBO-Source Code Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font

- with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font

- with 5: -ADBO-Source Code Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font

- with 6: -urw-nimbus sans l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch font but without anti-aliasing

- with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font

- with 8-9: -ADBO-Source Code Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font

- with 10-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font

That can't be right.  Only 4, 7, and 10-11 correspond to what is expected 
for that face, namely a variable pitch font.  Fixing the 'medium' case (as 
my patch does) only improves 7.  Fixing the other cases would amount to do 
something similar for each possible weight (e.g. "also try 'bold' after 
trying 'ultra-bold'"), which in fact amounts to ignoring the weight in 
spec.

When the weight is ignored in font_find_for_lface, the variable-pitch face 
is realized as follows:

- with 1-5: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1

- with 6-7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1

- with 8-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1

Which is clearly TRT.

New patch attached.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Unset-the-weight-in-font-specs-when-searching-for-a-.patch --]
[-- Type: text/x-diff; name=Unset-the-weight-in-font-specs-when-searching-for-a-.patch, Size: 1577 bytes --]

From 7e8fb5cebd4031d947940ae8eeef0a2b72fb4cba Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Mon, 21 Nov 2022 23:26:07 +0000
Subject: [PATCH] Unset the weight in font specs when searching for a font.

Between commits bf0d3f76dc (2014) and 6b1ed2f2c9 (2022),
realize_gui_face called font_load_for_lface with an empty or partly
emptied font spec, i.e. it ignored a part of its attrs argument.  The
rationale given in bug#17973, which led to bf0d3f76dc, is not clear.
However, 6b1ed2f2c9 leads to suboptimal font choices when the font
chosen for the default face has a weight that is not supported by
other available fonts on the system, such as 'medium' or 'heavy'.
Therefore, the weight in the spec argument to font_find_for_lface
must be unset.

* src/font.c (font_find_for_lface): Unset the weight of the font spec.
Fixes bug#57555 and bug#59347.
---
 src/font.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/font.c b/src/font.c
index 6e720bc285..fc8019fe13 100644
--- a/src/font.c
+++ b/src/font.c
@@ -3003,6 +3003,10 @@ font_find_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec, int
     }
   ASET (work, FONT_SIZE_INDEX, Qnil);
 
+  /* Also ignore the font weight, which when set leads to suboptimal
+     font choices.  See bug#59347.  */
+  ASET (work, FONT_WEIGHT_INDEX, Qnil);
+
   /* Foundry specification alternatives: from the most specific to the
      least specific and finally an unspecified one.  */
   foundry[0] = AREF (work, FONT_FOUNDRY_INDEX);
-- 
2.35.1

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

By the way, I suspect (but do not have a recipe right now) that the same 
bug exists with the :width and :slant attributes (namely, that setting the 
font for the default face with an "exotic" value leads to suboptimal/wrong 
font choices for other faces), and that they should also be set to nil in 
font_find_for_lface.

bug#59347: 29.0.50; `:family` face setting ignored

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

> By the way, I suspect (but do not have a recipe right now) that the same bug
>  exists with the :width and :slant attributes (namely, that setting the font
>  for the default face with an "exotic" value leads to suboptimal/wrong font
>  choices for other faces), and that they should also be set to nil in
>  font_find_for_lface.

IIUC the way we manage choose fonts is that we ask for a list of fonts
matching a particular pattern.  If that list is empty we make the
pattern more coarse and try again.  And when the list is not empty we
choose the best fit based on a score.

So in essence, what you're saying is that we should rely more on
scoring, and start with a coarser pattern right from the beginning?


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

I would go even further: scoring font candidates according to their 
weight, slant, width and size (by comparing the values of these attributes 
to the desired value of these attributes) is pointless unless the weight, 
slant, width and size are set to nil (are not "free variables") when 
building the list of fonts on which the scoring will be applied.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

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


>> By the way, I suspect (but do not have a recipe right now) that the 
>> same bug exists with the :width and :slant attributes (namely, that 
>> setting the font for the default face with an "exotic" value leads to 
>> suboptimal/wrong font choices for other faces), and that they should 
>> also be set to nil in font_find_for_lface.
>
> IIUC the way we manage choose fonts is that we ask for a list of fonts 
> matching a particular pattern.  If that list is empty we make the 
> pattern more coarse and try again.  And when the list is not empty we 
> choose the best fit based on a score.
>

Yes, that's roughly speaking what is happening indeed.  Except that if we 
constraint, when we build it, the list of candidates to a specific weight 
and/or slant and/or width, scoring the candidates becomes pointless, 
because all candidates in the list will (by definition) be perfect 
matches.

>
> So in essence, what you're saying is that we should rely more on 
> scoring, and start with a coarser pattern right from the beginning?
>

What I'm saying (now) is that we should rely on scoring, not that we 
should rely _more_ on scoring.

New (again) patch attached.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Unset-the-weight-slant-width-in-font-specs-when-sear.patch --]
[-- Type: text/x-diff; name=Unset-the-weight-slant-width-in-font-specs-when-sear.patch, Size: 2207 bytes --]

From d21017c8b2fdf017f78217b34e6a5411b605e37c Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Tue, 22 Nov 2022 07:58:30 +0000
Subject: [PATCH] Unset the weight/slant/width in font specs when searching for
 a font

Between commits bf0d3f76dc (2014) and 6b1ed2f2c9 (2022),
realize_gui_face called font_load_for_lface with an empty or partly
emptied font spec, i.e. it ignored a part of its attrs argument.  The
rationale given in bug#17973, which led to bf0d3f76dc, is not clear.
However, 6b1ed2f2c9 leads to suboptimal font choices, in particular
when the font chosen for the default face has a weight, slant or width
that is not supported by other available fonts on the system, such as
'medium' or 'heavy'.  Furthermore, calling font_list_entities without
unsetting these attributes arbitrarily limits the number of candidates
to only those that are perfect matches, which means that scoring the
candidates becomes in fact pointless.  Therefore, the weight, slant
and width attributes in the spec argument to font_find_for_lface must
be unset, like the size attribute.

* src/font.c (font_find_for_lface): Unset the weight, slant and width
of the font spec.  Fixes bug#57555 and bug#59347.
---
 src/font.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/font.c b/src/font.c
index 6e720bc285..0723e080dd 100644
--- a/src/font.c
+++ b/src/font.c
@@ -3003,6 +3003,15 @@ font_find_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec, int
     }
   ASET (work, FONT_SIZE_INDEX, Qnil);
 
+  /* Unset the font weight, slant and width.  The best possible values
+     for these attributes is determined later, when the candidate list
+     returned by font_list_entities is sorted by font_select_entity
+     (which calls font_sort_entities, which calls font_score).  See
+     bug#59347.  */
+  ASET (work, FONT_WEIGHT_INDEX, Qnil);
+  ASET (work, FONT_SLANT_INDEX, Qnil);
+  ASET (work, FONT_WIDTH_INDEX, Qnil);
+
   /* Foundry specification alternatives: from the most specific to the
      least specific and finally an unspecified one.  */
   foundry[0] = AREF (work, FONT_FOUNDRY_INDEX);
-- 
2.35.1

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> is pointless unless the weight, slant, width and size are set to nil 
> (are not "free variables")
>

That's a typo, obviously I meant (are "free variables").

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Mon, 21 Nov 2022 23:34:18 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> emacs -Q
> M-: (fancy-startup-screen) RET
> 
> and now evaluate the following lines in turn:
> 
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-heavy) ;; 1
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'heavy) ;; 2
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-bold) ;; 3
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'bold) ;; 4
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-bold) ;; 5
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium) ;; 6
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'normal) ;; 7
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-light) ;; 8
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'light) ;; 9
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-light) ;; 10
> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'thin) ;; 11
> 
> (If you don't have the Source Code Pro font on your system, I'm sure you 
> can find another font with more weight variants with which you will 
> observe a similar effect.)
> 
> With current master, the variable-pitch face is realized as follows:
                           ^^^^^^^^^^^^^^
Is that a typo?  If not, how does variable-pitch face come into play here:
you only asked for a font for the default face.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> emacs -Q M-: (fancy-startup-screen) RET
>>
>> and now evaluate the following lines in turn:
>>
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-heavy) ;; 1
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'heavy) ;; 2
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-bold) ;; 3
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'bold) ;; 4
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-bold) ;; 5
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium) ;; 6
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'normal) ;; 7
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-light) ;; 8
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'light) ;; 9
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-light) ;; 10
>> (set-face-attribute 'default nil :font "Source Code Pro" :weight 'thin) ;; 11
>>
>> (If you don't have the Source Code Pro font on your system, I'm sure 
>> you can find another font with more weight variants with which you will 
>> observe a similar effect.)
>>
>> With current master, the variable-pitch face is realized as follows:
>                           ^^^^^^^^^^^^^^
>
> Is that a typo?  If not, how does variable-pitch face come into play 
> here: you only asked for a font for the default face.
>

No, it's not a typo.  See line 2 of the recipe above, which opens the 
fancy-startup-screen, which uses the variable-pitch face (and other faces 
that inherit from variable-pitch).  With that you see the effect of 
changing the default face on the variable-pitch face.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  59347@debbugs.gnu.org
> Date: Mon, 21 Nov 2022 22:05:05 -0500
> 
> So in essence, what you're saying is that we should rely more on
> scoring, and start with a coarser pattern right from the beginning?

Wouldn't this potentially examine many more fonts?  For example, if all I
want is a 'bold' version of the same family as the default face's font,
Emacs currently can find it almost immediately, by considering only the few
fonts of the same family.  Whereas with your proposal, it will start from a
"clean slate" every time and will need to examine many (if not all) of the
fonts on the system to be sure score-only matches will find the best
candidate.

Also, font_score only scores the numerical attributes, so how do we assess
the "score" of matches for :family or :adstyle?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Tue, 22 Nov 2022 06:42:11 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> 
> I would go even further: scoring font candidates according to their 
> weight, slant, width and size (by comparing the values of these attributes 
> to the desired value of these attributes) is pointless unless the weight, 
> slant, width and size are set to nil (are not "free variables") when 
> building the list of fonts on which the scoring will be applied.

You assume that all, say, 'bold' fonts have the same numerical weight
values?  That is factually incorrect, especially as some font backends
support more fine-granular weight (and slant and width) classes and values
than the scale we use (which AFAIR was inherited from an old standard).

And please also consider my comment about the number of fonts we examine
when looking for a suitable candidate.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Tue, 22 Nov 2022 07:59:22 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 59347@debbugs.gnu.org
> 
> What I'm saying (now) is that we should rely on scoring, not that we 
> should rely _more_ on scoring.
> 
> New (again) patch attached.

What happens with the recipe in bug#37473 after this change?

And can you somehow tell how many fonts does Emacs examine with and without
this change?

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> Whereas with your proposal, it will start from a "clean slate" every 
> time and will need to examine many (if not all) of the fonts on the 
> system to be sure score-only matches will find the best candidate.
>

That's not what it does, no.  The loop in font_find_for_lface limits the 
number of fonts that are considered to some foundry, family, registry and 
additional style, and only considers more fonts if no suitable fonts have 
been found.

>
> Also, font_score only scores the numerical attributes, so how do we 
> assess the "score" of matches for :family or :adstyle?
>

That's the purpose of the loop at the end of font_find_for_lface.  It 
starts with a specific spec and gradually makes it less specific if 
necessary (that is, if no suitable font has been found with a more 
specific spec).

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> What happens with the recipe in bug#37473 after this change?
>

It works as expected: the font is initially not anti-aliased, the mode 
line is not anti-aliased, and everything remains not anti-aliased when 
scaling.

>
> And can you somehow tell how many fonts does Emacs examine with and 
> without this change?
>

That depends on the number of fonts installed on the system, of course. 
Also note that that's what Emacs has been doing for ~8 years after 
bf0d3f76dc (except that the situation was worse: after setting _all_ 
attributes to nil, more fonts are examined).

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Mon, 21 Nov 2022 23:34:18 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> With current master, the variable-pitch face is realized as follows:
> 
> - with 1-3: -ADBO-Source Code Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font
> 
> - with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
> 
> - with 5: -ADBO-Source Code Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font
> 
> - with 6: -urw-nimbus sans l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch font but without anti-aliasing
> 
> - with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
> 
> - with 8-9: -ADBO-Source Code Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font
> 
> - with 10-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
> 
> That can't be right.  Only 4, 7, and 10-11 correspond to what is expected 
> for that face, namely a variable pitch font.

Why do you expect to get a variable pitch font?  We don't have any way of
expressing that in font attributes, do we?  Emacs tries to find a font from
the same family, but if that fails for some reason, all bets are off wrt
whether the font we find will be variable-pitch or not.  Or what am I
missing?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Tue, 22 Nov 2022 13:38:19 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Stefan Monnier <monnier@iro.umontreal.ca>, 59347@debbugs.gnu.org
> 
> > Whereas with your proposal, it will start from a "clean slate" every 
> > time and will need to examine many (if not all) of the fonts on the 
> > system to be sure score-only matches will find the best candidate.
> >
> 
> That's not what it does, no.  The loop in font_find_for_lface limits the 
> number of fonts that are considered to some foundry, family, registry and 
> additional style, and only considers more fonts if no suitable fonts have 
> been found.

But the same considerations apply to weight, slant, and width: shouldn't we
prefer an identical value for each one of those, if that is possible?
font_score has its own ideas about which one of these 3 is "more equal",
AFAICT.

And if no suitable candidate is found by making these 3 attributes free,
then we are back to the same problem, now with non-numerical attributes.
Right?

> > Also, font_score only scores the numerical attributes, so how do we 
> > assess the "score" of matches for :family or :adstyle?
> 
> That's the purpose of the loop at the end of font_find_for_lface.  It 
> starts with a specific spec and gradually makes it less specific if 
> necessary (that is, if no suitable font has been found with a more 
> specific spec).

So we will be back to the same problem with those.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> With current master, the variable-pitch face is realized as follows:
>>
>> - with 1-3: -ADBO-Source Code Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font
>>
>> - with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
>>
>> - with 5: -ADBO-Source Code Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font
>>
>> - with 6: -urw-nimbus sans l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch font but without anti-aliasing
>>
>> - with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
>>
>> - with 8-9: -ADBO-Source Code Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font
>>
>> - with 10-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
>>
>> That can't be right.  Only 4, 7, and 10-11 correspond to what is 
>> expected for that face, namely a variable pitch font.
>
> Why do you expect to get a variable pitch font?
>

The variable-pitch face should use a variable pitch font, shouldn't it? 
Unless there are no such fonts installed on the computer of course, in 
which case it could fall back to a monospace font.

>
> Emacs tries to find a font from the same family, but if that fails for 
> some reason, all bets are off wrt whether the font we find will be 
> variable-pitch or not.  Or what am I missing?
>

Why should the weight of the default face influence the font selected for 
the variable-pitch face, to the point that even when variable pitch fonts 
are installed on the computer, they are all flatly rejected because they 
do not explicitly support say the 'semi-bold' weight?  The weight of the 
default face should only influence the weight of the other faces, which is 
what it does with the patch.  With a 'semi-bold' default face, a 'bold' 
variable pitch font is a legitimate candidate for the variable-pitch face.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> That's not what it does, no.  The loop in font_find_for_lface limits 
>> the number of fonts that are considered to some foundry, family, 
>> registry and additional style, and only considers more fonts if no 
>> suitable fonts have been found.
>
> But the same considerations apply to weight, slant, and width: shouldn't 
> we prefer an identical value for each one of those, if that is possible?
>

Of course, and that's font_select_entity does (by using font_score).

>
> And if no suitable candidate is found by making these 3 attributes free, 
> then we are back to the same problem, now with non-numerical attributes. 
> Right?
>

I don't understand your question, sorry.  As I said, if no suitable 
candidate is found, the loop at the end of font_find_for_lface gradually 
makes the other attributes less specific until a suitable font is found.

>> That's the purpose of the loop at the end of font_find_for_lface.  It 
>> starts with a specific spec and gradually makes it less specific if 
>> necessary (that is, if no suitable font has been found with a more 
>> specific spec).
>
> So we will be back to the same problem with those.
>

Sorry, I don't understand what you mean.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Tue, 22 Nov 2022 14:39:16 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > Why do you expect to get a variable pitch font?
> >
> 
> The variable-pitch face should use a variable pitch font, shouldn't it? 
> Unless there are no such fonts installed on the computer of course, in 
> which case it could fall back to a monospace font.

You know it and I know it, but how should the code which examines the fonts
know it?  AFAICT, nothing tells it to reject fixed-pitch fonts.  Or did I
miss something?

> > Emacs tries to find a font from the same family, but if that fails for 
> > some reason, all bets are off wrt whether the font we find will be 
> > variable-pitch or not.  Or what am I missing?
> 
> Why should the weight of the default face influence the font selected for 
> the variable-pitch face

Because if the default face is bold, so should be other faces, preferably.
To keep a consistent appearance, so to say.  And the same goes for slant and
width.

> to the point that even when variable pitch fonts 
> are installed on the computer, they are all flatly rejected because they 
> do not explicitly support say the 'semi-bold' weight?  The weight of the 
> default face should only influence the weight of the other faces

How are "other faces", where you agree that the weight should matter,
different from the variable-pitch face, where you don't agree?

Anyway, I'm okay with doing what you suggest as a fallback, if the code we
have now somehow didn't produce satisfactory results.  Provided we can
define reasonable criteria for what is "satisfactory".  But I don't think
it's right to throw away these 2 attributes to begin with, no.

> With a 'semi-bold' default face, a 'bold' variable pitch font is a
> legitimate candidate for the variable-pitch face.

But your patch doesn't "loosen" just one attribute, it does that with all 3
in one blow.  Maybe if we "loosen" just one, we will be able to find a match
for the other two.  I don't think font_score guarantees that, does it?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Tue, 22 Nov 2022 14:45:20 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> >> That's the purpose of the loop at the end of font_find_for_lface.  It 
> >> starts with a specific spec and gradually makes it less specific if 
> >> necessary (that is, if no suitable font has been found with a more 
> >> specific spec).
> >
> > So we will be back to the same problem with those.
> >
> 
> Sorry, I don't understand what you mean.

I mean that the basic algorithm that gradually makes the spec less specific
is used for non-numerical attributes, and so can potentially reject valid
fonts, just like it happens with these 3 numerical attributes.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> The variable-pitch face should use a variable pitch font, shouldn't it? 
>> Unless there are no such fonts installed on the computer of course, in 
>> which case it could fall back to a monospace font.
>
> You know it and I know it, but how should the code which examines the 
> fonts know it?  AFAICT, nothing tells it to reject fixed-pitch fonts. 
> Or did I miss something?
>

Nothing tells it to reject fixed-pitch fonts as a last resort indeed. 
But clearly the code should not select a fixed-pitch font _because_ it is 
the only available font that supports say a 'semi-bold' weight, when 
variable pitch fonts that support a 'bold' weight are in fact available.

>> Why should the weight of the default face influence the font selected 
>> for the variable-pitch face
>
> Because if the default face is bold, so should be other faces, 
> preferably. To keep a consistent appearance, so to say.  And the same 
> goes for slant and width.
>

With the code on master, the effect is the opposite of consistence.  With 
the patch the effect is consistent: when the default face is say 
'semi-bold', a 'bold' variable pitch font can be considered the best match 
for the variable-pitch face.

>> to the point that even when variable pitch fonts are installed on the 
>> computer, they are all flatly rejected because they do not explicitly 
>> support say the 'semi-bold' weight?  The weight of the default face 
>> should only influence the weight of the other faces
>
> How are "other faces", where you agree that the weight should matter, 
> different from the variable-pitch face, where you don't agree?
>

What I said above was perhaps not clear enough.  There is nothing special 
about the variable-pitch face, I only used it to make the problem of the 
code on master as clear as possible.

Of course the weight of the default face should influence the weight of 
all other faces.  But not to the point that a 'bold' variable pitch font 
is never even considered as a potential candidate for the variable-pitch 
face.

>
> Anyway, I'm okay with doing what you suggest as a fallback, if the code 
> we have now somehow didn't produce satisfactory results.
>

It's not that it doesn't produce satisfactory results, it's that it 
doesn't do what it is meant to do.  The scoring mechanism for the 
weight/slant/width attributes is simply bypassed.  Without unsetting these 
three attributes, font_list_entities only produces candidates that are 
exact matches (e.g. only "bold" fonts are returned), and the whole point 
of scoring ("when searching for a semi-bold font, bold is better than 
medium and worse than extra-bold") is entirely lost.  My patch simply 
restores the scoring mechanism (and fixes at least three bugs: 37473, 
57555 and 59347).

>> With a 'semi-bold' default face, a 'bold' variable pitch font is a 
>> legitimate candidate for the variable-pitch face.
>
> But your patch doesn't "loosen" just one attribute, it does that with 
> all 3 in one blow.  Maybe if we "loosen" just one, we will be able to 
> find a match for the other two.  I don't think font_score guarantees 
> that, does it?
>

It does that because these three attributes are those that are considered 
by the font scoring mechanism (together with the size, which is set to nil 
two lines above).  The scoring mechanism guarantees that the best match, 
depending on the user preferences specified in face-font-selection-order, 
will be selected.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>>>> That's the purpose of the loop at the end of font_find_for_lface. 
>>>> It starts with a specific spec and gradually makes it less specific 
>>>> if necessary (that is, if no suitable font has been found with a more 
>>>> specific spec).
>>>
>>> So we will be back to the same problem with those.
>>
>> Sorry, I don't understand what you mean.
>
> I mean that the basic algorithm that gradually makes the spec less 
> specific is used for non-numerical attributes, and so can potentially 
> reject valid fonts, just like it happens with these 3 numerical 
> attributes.
>

No, it won't reject valid fonts (unless I misunderstand what you mean by 
"valid font").  For example, when searching for a font in the monospace 
family, all fonts in the monospace family are considered.  If no such 
fonts are found, Emacs tries again (see face-font-family-alternatives) and 
considers all fonts in the courier family.  If no such fonts are found, 
Emacs tries again and considers all fonts in the fixed family.  After 
which Emacs gives up.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Tue, 22 Nov 2022 15:41:47 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org, bug-gnu-emacs@gnu.org
> 
> No, it won't reject valid fonts (unless I misunderstand what you mean by 
> "valid font").  For example, when searching for a font in the monospace 
> family, all fonts in the monospace family are considered.  If no such 
> fonts are found, Emacs tries again (see face-font-family-alternatives) and 
> considers all fonts in the courier family.  If no such fonts are found, 
> Emacs tries again and considers all fonts in the fixed family.  After 
> which Emacs gives up.

I feel like we have no focus in this dispute, and no real understanding of
the goal.  So let me go back to your scenario and ask you: what exactly is
the problem with the scenario that you described?  A reminder:

  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-heavy) ;; 1
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'heavy) ;; 2
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-bold) ;; 3
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'bold) ;; 4
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-bold) ;; 5
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium) ;; 6
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'normal) ;; 7
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-light) ;; 8
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'light) ;; 9
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-light) ;; 10
  (set-face-attribute 'default nil :font "Source Code Pro" :weight 'thin) ;; 11

  (If you don't have the Source Code Pro font on your system, I'm sure you 
  can find another font with more weight variants with which you will 
  observe a similar effect.)

  With current master, the variable-pitch face is realized as follows:

  - with 1-3: -ADBO-Source Code Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font

  - with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font

  - with 5: -ADBO-Source Code Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font

  - with 6: -urw-nimbus sans l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch font but without anti-aliasing

  - with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font

  - with 8-9: -ADBO-Source Code Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font

  - with 10-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font

Is the problem that you expected the family to be DejaVu Sans, but you got a
different family in some cases?

Or is the problem that you expected a variable-pitch font, but got a
monospaced font in some cases?

Or is the problem something else?

And why is this result:

  - with 1-5: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1

  - with 6-7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1

  - with 8-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1

better?  You asked for ultra-heavy and heavy weight, but got bold -- why is
that TRT? what if it really mattered to you to have several fonts of
different heaviness?

You also mentioned this:

> Nothing tells it to reject fixed-pitch fonts as a last resort indeed. 
> But clearly the code should not select a fixed-pitch font _because_ it is 
> the only available font that supports say a 'semi-bold' weight, when 
> variable pitch fonts that support a 'bold' weight are in fact available.

Why is it "clear" that font selection should do what you expect here, given
that the only (weak) indication that we are after a variable-pitch font is
the family?  Why do you consider it so preposterous that Emacs comes up with
a semi-bold font, when you ask for a semi-bold font?

> Of course the weight of the default face should influence the weight of 
> all other faces.  But not to the point that a 'bold' variable pitch font 
> is never even considered as a potential candidate for the variable-pitch 
> face.

How do you know it wasn't considered?  Maybe it was considered, but "lost"
to what Emacs decided to be a better candidate?  And again, there's no
information of any kind in the font-spec we use that we are looking for a
variable-pitch font.  We only have the family.  Given that no font in the
family matches the specified width, why shouldn't Emacs try to find a font
from another family that does match the width?

> It's not that it doesn't produce satisfactory results, it's that it 
> doesn't do what it is meant to do.  The scoring mechanism for the 
> weight/slant/width attributes is simply bypassed.  Without unsetting these 
> three attributes, font_list_entities only produces candidates that are 
> exact matches (e.g. only "bold" fonts are returned), and the whole point 
> of scoring ("when searching for a semi-bold font, bold is better than 
> medium and worse than extra-bold") is entirely lost.

The fact that we bypass scoring and look only for exact matches might be a
valid criticism of the existing font-selection algorithm, but it doesn't yet
tell us what should be the alternative.  To decide what would be such an
alternative, we need a good understanding of the goals of the font search in
the various use cases we need to support.  Which is why I'm asking all those
questions.

> My patch simply restores the scoring mechanism (and fixes at least three
> bugs: 37473, 57555 and 59347).

Unfortunately, I've seen too many changes in this area which solved a couple
of problems, only to produce others, which took us time to discover.  The
last thing I want here is to do the same for the N+1st time.  So let's first
try to determine what exactly do we want to happen and why.

Thanks.

bug#59347: 29.0.50; `:family` face setting ignored

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

>> That's not what it does, no.  The loop in font_find_for_lface limits the 
>> number of fonts that are considered to some foundry, family, registry and 
>> additional style, and only considers more fonts if no suitable fonts have 
>> been found.
>
> But the same considerations apply to weight, slant, and width: shouldn't we
> prefer an identical value for each one of those, if that is possible?

The difference is that for numerical attributes there is a notion of
proximity (plus some arbitrariness: very few users care whether a font
is "normal" vs "regular" vs "medium", especially when the font of the
family you requested has only one of those 3 and the font designed
chose one of those three names somewhat arbitrarily).  This makes the
scoring work well for those.

In contrast, we don't have such a notion for family/foundry/registry,
which means scoring doesn't really work well for those attributes.

So I think it makes sense to rely exclusively on scoring for the
numerical attributes (width/weight/height/weight).  At least intuitively
it should give good results.  For me the question is what is its impact
in terms of the number of fonts we need to consider.

[ Side note: the slant attribute could also be made numerical, I think.  ]

> And if no suitable candidate is found by making these 3 attributes free,
> then we are back to the same problem, now with non-numerical attributes.
> Right?

Yes, but since they are not numerical/continuous attributes we can't see
those weird discontinuities where you get font A for `semi-bold`, then
font B for `normal`, then font A again for `light` (as in Gregory's
example) which makes no sense: either A is heavier than B or not, but it
can't be both, right?


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> So let me go back to your scenario and ask you: what exactly is the 
> problem with the scenario that you described?  A reminder:
>
> With current master, the variable-pitch face is realized as follows:
>
> - with 1-3: -ADBO-Source Code Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font
>
> - with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
>
> - with 5: -ADBO-Source Code Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font
>
> - with 6: -urw-nimbus sans l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch font but without anti-aliasing
>
> - with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
>
> - with 8-9: -ADBO-Source Code Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font
>
> - with 10-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font
>
> Is the problem that you expected the family to be DejaVu Sans, but you 
> got a different family in some cases?
>
> Or is the problem that you expected a variable-pitch font, but got a 
> monospaced font in some cases?
>
> Or is the problem something else?
>

The problem is that users expect a variable pitch font for the 
variable-pitch face (and an antialiased font when antialising is on). 
That's what the "family = Sans Serif" specification of that face means.

>
> And why is this result:
>
> - with 1-5: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1
>
> - with 6-7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1
>
> - with 8-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1
>
> better?
>

It is better because the "family = Sans Serif" specification of the 
variable-pitch face is obeyed.  (Incidentally, that result corresponds to 
the result returned by fc-match for those weights.)

>
> You asked for ultra-heavy and heavy weight, but got bold -- why is that 
> TRT?
>

Same answer: it is TRT because the "family = Sans Serif" specification of 
the variable-pitch face is obeyed.

>> Nothing tells it to reject fixed-pitch fonts as a last resort indeed. 
>> But clearly the code should not select a fixed-pitch font _because_ it 
>> is the only available font that supports say a 'semi-bold' weight, when 
>> variable pitch fonts that support a 'bold' weight are in fact 
>> available.
>
> Why is it "clear" that font selection should do what you expect here, 
> given that the only (weak) indication that we are after a variable-pitch 
> font is the family?  Why do you consider it so preposterous that Emacs 
> comes up with a semi-bold font, when you ask for a semi-bold font?
>

You seem to misunderstand how font selection works.  The "family = Sans 
Serif" specification of the variable-pitch face is not at at all a "weak" 
indication that we are after a variable pitch font, it's the strongest 
possible indication that we are after a variable pitch font.  It means 
"please choose whatever font you want among those installed on the system, 
but one in the Sans Serif family", "Sans Serif" being one of the few 
generic font families.  It's like the "Monospace" family for the default 
font.  It would be wrong if Emacs decided to select a variable pitch font 
for the default face, wouldn't it?

>> Of course the weight of the default face should influence the weight of 
>> all other faces.  But not to the point that a 'bold' variable pitch 
>> font is never even considered as a potential candidate for the 
>> variable-pitch face.
>
> How do you know it wasn't considered?
>

I debugged the code.

>
> And again, there's no information of any kind in the font-spec we use 
> that we are looking for a variable-pitch font.  We only have the family.
>

See above.

>
> Given that no font in the family matches the specified width, why 
> shouldn't Emacs try to find a font from another family that does match 
> the width?
>

Because the variable-pitch face is specified with "family = Sans Serif", 
and it is its only specification.  Specifying a font family means leaving 
a lot of freedom to the program (in this case Emacs, but the same applies 
to a browser for example) to select the font it wants among those 
installed on the system.  And there is no reason whatsoever to not obey 
that specification, unless there are strong reasons not to obey it (e.g. 
there are no Sans Serif fonts installed on the system, or the ones that 
are installed do not cover the character sets we want to display).  Which 
is evidently not the case here: if we're after a "Sans Serif semi-bold" 
font, and there are "Sans Serif bold" fonts installed on the system, they 
are good candidates.

There are, on my system, no less than 166 fonts in the "Sans Serif" 
family.  It just happens that none of them explicitly supports the 'heavy' 
weight / has no explicit 'heavy' variant.  But that is not a sufficient 
reason to reject all those 166 fonts.  What Emacs should do, what others 
programs do, and what Emacs would do with the patch, is to select the best 
possible font among those 166 fonts.

>
> Unfortunately, I've seen too many changes in this area which solved a 
> couple of problems, only to produce others, which took us time to 
> discover.  The last thing I want here is to do the same for the N+1st 
> time.  So let's first try to determine what exactly do we want to happen 
> and why.
>

I don't know what else I could say to convince you.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> For me the question is what is its impact in terms of the number of 
> fonts we need to consider.
>

I don't understand why we should suddently worry about the number of fonts 
we consider.  During ~8 years (after bf0d3f76dc) _all_ attributes (not 
just the size/weight/slant/height ones) were set to nil (in 
realize_x_face), and I don't think there were any bug reports about Emacs 
being too slow to select fonts.  Face realization is something that 
happens only rarely.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

Are there further comments or questions about this patch?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 10:03:34 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Stefan Monnier <monnier@iro.umontreal.ca>, 59347@debbugs.gnu.org
> 
> 
> Are there further comments or questions about this patch?

Yes.  I stopped responding because I didn't want to get in the way of your
finishing the merge of the locked-narrowing branch, but the discussion about
this one is far from over.  I will respond when I have more time.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

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


>> Are there further comments or questions about this patch?
>
> Yes.  I stopped responding because I didn't want to get in the way of 
> your finishing the merge of the locked-narrowing branch, but the 
> discussion about this one is far from over.  I will respond when I have 
> more time.
>

Okay.

To clarify the matter, I think the following is useful, to explain what 
"family = Sans Serif" means.

I attach a screenshot of the font preference box in Firefox.  In that 
screenshot you see the three most general font families: Serif, Sans Serif 
and Monospace.  The Serif and Sans Serif families are meant for variable 
pitch fonts.  Emacs uses these same "Sans Serif" and "Monospace" families.

Websites specify the font the browser should use in a specification, which 
should always include a font family, as follows:

font-family: 'Arial', 'Helvetica', sans-serif;

As you probably understand, this means "please use the Arial font for that 
element, or if it is not available the Helvetica font, or if neither are 
available fall back to the default sans-serif font".  Likewise:

font-family: sans-serif;

means "I don't care about the font, please use the default Sans Serif 
font".

[-- Attachment #2: firefox.png --]
[-- Type: image/png, Size: 76089 bytes --]

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 15:38:37 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> I attach a screenshot of the font preference box in Firefox.  In that 
> screenshot you see the three most general font families: Serif, Sans Serif 
> and Monospace.  The Serif and Sans Serif families are meant for variable 
> pitch fonts.  Emacs uses these same "Sans Serif" and "Monospace" families.

Emacs uses the same families because we have it in
face-font-family-alternatives, and/or because Fontconfig has the same notion
of families.  There's no magic here, and btw face-font-family-alternatives
can be customized by the user to yield completely different preferences.

But nothing in the family name tells Emacs it _must_ produce a
variable-pitch font.  Those are just lists of font names, that's all.  In
your example, you consider DejaVu Sans to be a proper font for that family,
but the name "DejaVu Sans" doesn't appear anywhere, so why is it correct?

> > You asked for ultra-heavy and heavy weight, but got bold -- why is that 
> > TRT?
> 
> Same answer: it is TRT because the "family = Sans Serif" specification of 
> the variable-pitch face is obeyed.

This doesn't make sense to me: why should Emacs obey "family = Sans Serif",
but not "weight = ultra"?

> > Why is it "clear" that font selection should do what you expect here, 
> > given that the only (weak) indication that we are after a variable-pitch 
> > font is the family?  Why do you consider it so preposterous that Emacs 
> > comes up with a semi-bold font, when you ask for a semi-bold font?
> >
> 
> You seem to misunderstand how font selection works.

Stop right there.  If you still wonder how you got a semi-angry response in
the dispute about narrowed-locking, this arrogant attitude is the reason.
You are always right and anyone who disagrees "doesn't understand".  You are
dangerously close to getting the same reaction in this discussion.  If you
want a rational, technical, efficient discussion, please drop the attitude
and start leveling with me.  Do not try to tell me what I do and don't
understand, and do not reply with arrogant responses like this one:

> > How do you know it wasn't considered?
> 
> I debugged the code.

Instead, please assume that I know enough about the code to have good
reasons for asking my questions, and please humor me with full, detailed
responses.  That is the only way to convince me that you are right.

So once again, here are my questions:

  . why do you think Emacs must return only variable-pitch fonts for a spec
    that includes family = Sans Serif"? where and how should Emacs get the
    indication that only variable-pitch fonts are acceptable in that case?
  . why do you consider the family attribute of a face be more important
    than other attributes? if not all the attributes of a spec are "equal"
    in their importance, which attributes are more important, and why? and
    if bold is fine when semi-bold was requested, what about other weights,
    like ultra-light -- are they also okay? if not, why not? what are the
    criteria here and with other similar attributes?

Without getting detailed answers to these questions, I don't see how we can
continue the discussion, nor why we should; and there's no real reason for
me to change my mind that what Emacs does now with these specs is correct
and expected.

> There are, on my system, no less than 166 fonts in the "Sans Serif" 
> family.  It just happens that none of them explicitly supports the 'heavy' 
> weight / has no explicit 'heavy' variant.  But that is not a sufficient 
> reason to reject all those 166 fonts.  What Emacs should do, what others 
> programs do, and what Emacs would do with the patch, is to select the best 
> possible font among those 166 fonts.

That would mean the user cannot specify a weight meaning "give me that
weight or admit failure to find a suitable font".  And how does that make
sense?

> I don't know what else I could say to convince you.

You could start showing data and details of the code workings, instead of
talking slogans and insults.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Wed, 23 Nov 2022 08:13:08 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 59347@debbugs.gnu.org
> 
> > For me the question is what is its impact in terms of the number of 
> > fonts we need to consider.
> 
> I don't understand why we should suddently worry about the number of fonts 
> we consider.  During ~8 years (after bf0d3f76dc) _all_ attributes (not 
> just the size/weight/slant/height ones) were set to nil (in 
> realize_x_face), and I don't think there were any bug reports about Emacs 
> being too slow to select fonts.  Face realization is something that 
> happens only rarely.

I suspect that you don't have enough fonts installed on your system to see
the effect.  I've seen people report that they have thousands of fonts
installed, and looking for a suitable font take ages.  So yes, we do need to
worry about that.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

I did not deserve such a public reprimand.  I do not care at all about 
being right or wrong personally, the only thing I care about here is 
improving Emacs.  I try to be as careful as possible, both in the code I 
write and in the messages I post.  In particular, I avoid posting anything 
that is intentionally insulting, ironical, or even simply humorous.

I already spent an unreasonable amount of time on this bug (I'd say easily 
around 30 hours), although I have no personal interest in seeing it 
resolved: I did not report it (or any of the bugs to which it is related), 
and it does not and cannot affect me (I use the same fixed-pitch font 
everywhere).

Nonetheless, I'll try to answer your questions:

>
> why do you think Emacs must return only variable-pitch fonts for a spec 
> that includes family = Sans Serif?
>

In emacs -Q, the only attribute specified in the variable-pitch face is 
its family: "Sans Serif".  There are three canonical, cross-platform, 
generic font families: "Sans Serif" and "Serif", whose names do not 
contain the word "proportional" or "variable pitch" but which contain only 
variable pitch fonts, and "Monospace", which (as its name implies, and as 
opposed to the Sans Serif and Serif families) contains only fixed pitch 
fonts.  Emacs (by default) only uses the Sans Serif and Monospace generic 
font families.

There is no standard way to make a distiction between monospace fonts with 
and without serifs.  For its fixed-pitch-serif face, which is inherited by 
Info-quoted and tex-verbatim, Emacs 25 invented another generic font 
family: "Monospace Serif".

>
> where and how should Emacs get the indication that only variable-pitch 
> fonts are acceptable in that case?
>

It is not Emacs that decides which fonts correspond to a "family = Sans 
Serif" specification, it is the font driver.  In font_list_entities, Emacs 
passes a font specification to a font driver, which returns a list of 
fonts matching that specification.  When Emacs passes the specification 
"family = Sans Serif" (or "family = Monospace") to the font driver, it 
receives a list of all available fonts in that family back.  If the 
specification passed to font_list_entities contains a non-nil width, 
weight or slant, that list is immediately filtered and all fonts that do 
not match these width, weight or slant exactly are removed from the list.

>
> why do you consider the family attribute of a face be more important 
> than other attributes?  if not all the attributes of a spec are "equal" 
> in their importance, which attributes are more important, and why?
>

Indeed, the attributes are not equal, in fact none of the attributes are 
ever equal in their importance.  The family is the most important one, 
followed by the foundry, the registry, the additional style (in that 
order, see the loop at the end of font_find_for_lface in which Emacs tries 
to make each of these attributes less specific in turn, starting with the 
least important one, namely the additional style), followed by the width, 
height (or size), weight, slant (in the order specified by the variable 
face-font-selection-order).

It is also in that loop (at the end of font_find_for_lface) that 
face-font-family-alternatives are used.  If the generic "Sans Serif", 
"Monospace" and "Monospace Serif" families that Emacs uses are not a 
recognized by the font driver (IOW, if font_list_entities returns an empty 
result for these families), Emacs falls back to some hard-coded, less 
generic, family names.  For example, if "family = Monospace" isn't 
recognized, Emacs tries "family = courier", and if "family = courier" 
isn't recongized either, Emacs tries "family = fixed".  As noted above, 
the "Monospace Serif" family is specific to Emacs, so for that generic 
family name Emacs will always fall back to the less generic family names 
corresponding to that generic family name in that variable.

>
> and if bold is fine when semi-bold was requested, what about other 
> weights, like ultra-light -- are they also okay? if not, why not?
>

Yes, ultra-light is also okay.  If a program requests a font in the Sans 
Serif family with a semi-bold weight, and the only available font on a 
given system in that family is a ultra-light one, it's the best possible 
match for that font specification.  It's up to the user to install a font 
in the Sans Serif family which has a semi-bold variant on their system, if 
they need a font in the Sans Serif family with a semi-bold variant (or to 
install another font that is closer to semi-bold than ultra-light, e.g. 
one with a bold variant).

>
> what are the criteria here and with other similar attributes?
>

The family, foundry, registry and additional style attributes are passed 
"as is" to the font driver, which returns a list of fonts matching these 
attributes.  The width, weight and/or slant are converted to numerical 
values (with font-{width,weight,slant}-table), and font_score, called by 
font_sort_entities, called by font_select_entity, which is applied on the 
list of fonts returned by font_list_entities, selects the best match in 
that list (according the the preferences in face-font-selection-order). 
If the width, weight and/or slant were already passed to 
font_list_entities, the list of fonts passed to font_select_entity 
contains only fonts that match these width, weight and/or slant, and that 
mechanism is bypassed.

In the worst case, the one which is the cause of this bug, when 
font_list_entities is called for example with "family = Sans Serif, weight 
= medium", font_list_entities returns an empty list, even when there are 
plenty of fonts in the Sans Serif families that would be good candidates 
according to the scoring mechanism, and therefore Emacs falls back to 
using face-font-family-alternatives, which is only meant to be used on 
systems in which the generic font families are not recognized.  And in the 
worst of the worst cases, even using face-font-family-alternatives does 
not help (IOW, font_list_entities keeps returning an empty list), in which 
case Emacs falls back to using the default face.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Mon, 05 Dec 2022 23:30:48 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> 
> I did not deserve such a public reprimand.  I do not care at all about 
> being right or wrong personally, the only thing I care about here is 
> improving Emacs.  I try to be as careful as possible, both in the code I 
> write and in the messages I post.  In particular, I avoid posting anything 
> that is intentionally insulting, ironical, or even simply humorous.
> 
> I already spent an unreasonable amount of time on this bug (I'd say easily 
> around 30 hours), although I have no personal interest in seeing it 
> resolved: I did not report it (or any of the bugs to which it is related), 
> and it does not and cannot affect me (I use the same fixed-pitch font 
> everywhere).
> 
> Nonetheless, I'll try to answer your questions:

Thank you.  I hope we can now finish up dealing with this issue.

> > where and how should Emacs get the indication that only variable-pitch 
> > fonts are acceptable in that case?
> 
> It is not Emacs that decides which fonts correspond to a "family = Sans 
> Serif" specification, it is the font driver.  In font_list_entities, Emacs 
> passes a font specification to a font driver, which returns a list of 
> fonts matching that specification.

That is also what I know, so we agree on this point.

I will note right here that Emacs has no way of knowing whether the fonts
returned by the font driver are or aren't variable-pitch.  In fact, AFAIR it
is a tricky and not very reliable to try deducing that from the font data
Emacs records about each font (see 'font-info').  We just blindly trust the
font driver to give us the appropriate list of fonts.  IOW, for Emacs the
family is just a meaningless string.

> If the specification passed to font_list_entities contains a non-nil
> width, weight or slant, that list is immediately filtered and all fonts
> that do not match these width, weight or slant exactly are removed from
> the list.

And you are saying that this filtering is wrong, yes?

> > why do you consider the family attribute of a face be more important 
> > than other attributes?  if not all the attributes of a spec are "equal" 
> > in their importance, which attributes are more important, and why?
> 
> Indeed, the attributes are not equal, in fact none of the attributes are 
> ever equal in their importance.  The family is the most important one, 
> followed by the foundry, the registry, the additional style (in that 
> order, see the loop at the end of font_find_for_lface in which Emacs tries 
> to make each of these attributes less specific in turn, starting with the 
> least important one, namely the additional style), followed by the width, 
> height (or size), weight, slant (in the order specified by the variable 
> face-font-selection-order).

That is not the relative importance of interest in the context of this
discussion, because Emacs already does look for a suitable font in the order
of the importance you describe.

My question was not about this basic relative importance, it was about
something else: when none of the fonts of the given FAMILY fits the font
spec, why do you consider keeping the family to be more important than
keeping the weight?

And another question: if we are to follow face-font-selection-order, to
observe the relative importance of the attributes as set by the user, then
why did your patch only consider relaxing the weight (which is in the
penultimate place in the order of importance), and not the slant (which is
the least important attribute, in the default order we use)?

> It is also in that loop (at the end of font_find_for_lface) that 
> face-font-family-alternatives are used.  If the generic "Sans Serif", 
> "Monospace" and "Monospace Serif" families that Emacs uses are not a 
> recognized by the font driver (IOW, if font_list_entities returns an empty 
> result for these families), Emacs falls back to some hard-coded, less 
> generic, family names.

I'm not sure I agree with this part of your description.  The code looks up
face-font-family-alternatives _before_ the loop in font_find_for_lface,
i.e., _before_ font_list_entities is called.  Where exactly do you see what
you describe above?

> > and if bold is fine when semi-bold was requested, what about other 
> > weights, like ultra-light -- are they also okay? if not, why not?
> 
> Yes, ultra-light is also okay.  If a program requests a font in the Sans 
> Serif family with a semi-bold weight, and the only available font on a 
> given system in that family is a ultra-light one, it's the best possible 
> match for that font specification.  It's up to the user to install a font 
> in the Sans Serif family which has a semi-bold variant on their system, if 
> they need a font in the Sans Serif family with a semi-bold variant (or to 
> install another font that is closer to semi-bold than ultra-light, e.g. 
> one with a bold variant).
> 
> >
> > what are the criteria here and with other similar attributes?
> >
> 
> The family, foundry, registry and additional style attributes are passed 
> "as is" to the font driver, which returns a list of fonts matching these 
> attributes.  The width, weight and/or slant are converted to numerical 
> values (with font-{width,weight,slant}-table), and font_score, called by 
> font_sort_entities, called by font_select_entity, which is applied on the 
> list of fonts returned by font_list_entities, selects the best match in 
> that list (according the the preferences in face-font-selection-order). 
> If the width, weight and/or slant were already passed to 
> font_list_entities, the list of fonts passed to font_select_entity 
> contains only fonts that match these width, weight and/or slant, and that 
> mechanism is bypassed.

IOW, you want to disable the filtering of candidate fonts in
font_list_entities, and instead consider _all_ the candidates, selecting the
best match for the numerical attributes: width, height, weight, and slant.
And you don't want to relax the non-numerical attributes (family, foundry,
registry, adstyle) unless there's really no font, of any
width/height/weight/slant, installed for the specified
family/foundry/registry/adstyle.  Is that right?

If that is what you want us to do, then I must ask at least about the
height: is it really reasonable to prefer _any_ height from the given
family, even if it's radically different from what was requested?

Also, the patch you suggested to install in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#77 doesn't do the above,
it is basically a minor semi-kludgey change of the existing code, which only
considers 'normal' weight when 'medium' was requested.  Why didn't you
submit a patch that follows your description and your critique to the
logical conclusion?

The rest of what I write below is based on the assumption that my
understanding of your critique of the current code is as I describe above;
if it is wrong, please ignore what's below, and please help me understand
what is it that you are actually proposing and I misunderstood.

So I see the following issues with your proposal (which AFAIU is different
from the patch you actually posted):

 . we will examine much more fonts than we do now: the current code only
   examines matching fonts and returns the first one that satisfies the
   spec; your proposal will require us to examine all of them, in order to
   find the best match out of many
 . your logic, which says that the family is so much more important than the
   other attributes is not necessarily correct in all the cases where this
   code is executed: I can easily imagine cases where the requested weight
   is so important that no other "close" weight will do, and the caller
   really wants to get an empty list rather than a deviant font

So I can only agree to installing the patch along the lines of the above
logic, i.e. to make the code relax the numerical attributes trying to keep
the family, on the following conditions:

 . we add an additional loop, like the one in font_find_for_lface, after the
   original one, and in that additional loop implement the examination of
   candidates without filtering then by numerical attributes up front; that
   additional loop will run only if the one before it came up with no fonts
   that match the family
 . whether the additional loop will actually run should be controlled by a
   variable exposed to Lisp, so that if this change causes regressions, we
   could easily find out this is the reason, and users could work around the
   regressions without rebuilding Emacs

OK?  And note that my agreement is not to the patch you posted, but to a
more general change in the logic of examining the candidate fonts.  This is
how I understand what you think Emacs should do; if I misunderstood, please
correct me.

Thanks.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> I will note right here that Emacs has no way of knowing whether the 
> fonts returned by the font driver are or aren't variable-pitch.  In 
> fact, AFAIR it is a tricky and not very reliable to try deducing that 
> from the font data Emacs records about each font (see 'font-info').  We 
> just blindly trust the font driver to give us the appropriate list of 
> fonts.  IOW, for Emacs the family is just a meaningless string.
>

Indeed, Emacs trusts the font driver


>> If the specification passed to font_list_entities contains a non-nil 
>> width, weight or slant, that list is immediately filtered and all fonts 
>> that do not match these width, weight or slant exactly are removed from 
>> the list.
>
> And you are saying that this filtering is wrong, yes?
>

No, that filtering in font_list_entities is not wrong, because 
font_list_entities has another caller besides font_find_for_lface: 
Flist_fonts.  What is wrong is to call font_list_entities with these 
attributes non-nil in


>>> why do you consider the family attribute of a face be more important
>>> than other attributes?  if not all the attributes of a spec are "equal"
>>> in their importance, which attributes are more important, and why?
>>
>> Indeed, the attributes are not equal, in fact none of the attributes are
>> ever equal in their importance.  The family is the most important one,
>> followed by the foundry, the registry, the additional style (in that
>> order, see the loop at the end of font_find_for_lface in which Emacs tries
>> to make each of these attributes less specific in turn, starting with the
>> least important one, namely the additional style), followed by the width,
>> height (or size), weight, slant (in the order specified by the variable
>> face-font-selection-order).
>
> That is not the relative importance of interest in the context of this
> discussion, because Emacs already does look for a suitable font in the order
> of the importance you describe.
>
> My question was not about this basic relative importance, it was about
> something else: when none of the fonts of the given FAMILY fits the font
> spec, why do you consider keeping the family to be more important than
> keeping the weight?
>
> And another question: if we are to follow face-font-selection-order, to
> observe the relative importance of the attributes as set by the user, then
> why did your patch only consider relaxing the weight (which is in the
> penultimate place in the order of importance), and not the slant (which is
> the least important attribute, in the default order we use)?
>
>> It is also in that loop (at the end of font_find_for_lface) that
>> face-font-family-alternatives are used.  If the generic "Sans Serif",
>> "Monospace" and "Monospace Serif" families that Emacs uses are not a
>> recognized by the font driver (IOW, if font_list_entities returns an empty
>> result for these families), Emacs falls back to some hard-coded, less
>> generic, family names.
>
> I'm not sure I agree with this part of your description.  The code looks up
> face-font-family-alternatives _before_ the loop in font_find_for_lface,
> i.e., _before_ font_list_entities is called.  Where exactly do you see what
> you describe above?
>
>>> and if bold is fine when semi-bold was requested, what about other
>>> weights, like ultra-light -- are they also okay? if not, why not?
>>
>> Yes, ultra-light is also okay.  If a program requests a font in the Sans
>> Serif family with a semi-bold weight, and the only available font on a
>> given system in that family is a ultra-light one, it's the best possible
>> match for that font specification.  It's up to the user to install a font
>> in the Sans Serif family which has a semi-bold variant on their system, if
>> they need a font in the Sans Serif family with a semi-bold variant (or to
>> install another font that is closer to semi-bold than ultra-light, e.g.
>> one with a bold variant).
>>
>>>
>>> what are the criteria here and with other similar attributes?
>>>
>>
>> The family, foundry, registry and additional style attributes are passed
>> "as is" to the font driver, which returns a list of fonts matching these
>> attributes.  The width, weight and/or slant are converted to numerical
>> values (with font-{width,weight,slant}-table), and font_score, called by
>> font_sort_entities, called by font_select_entity, which is applied on the
>> list of fonts returned by font_list_entities, selects the best match in
>> that list (according the the preferences in face-font-selection-order).
>> If the width, weight and/or slant were already passed to
>> font_list_entities, the list of fonts passed to font_select_entity
>> contains only fonts that match these width, weight and/or slant, and that
>> mechanism is bypassed.
>
> IOW, you want to disable the filtering of candidate fonts in
> font_list_entities, and instead consider _all_ the candidates, selecting the
> best match for the numerical attributes: width, height, weight, and slant.
> And you don't want to relax the non-numerical attributes (family, foundry,
> registry, adstyle) unless there's really no font, of any
> width/height/weight/slant, installed for the specified
> family/foundry/registry/adstyle.  Is that right?
>
> If that is what you want us to do, then I must ask at least about the
> height: is it really reasonable to prefer _any_ height from the given
> family, even if it's radically different from what was requested?
>
> Also, the patch you suggested to install in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#77 doesn't do the above,
> it is basically a minor semi-kludgey change of the existing code, which only
> considers 'normal' weight when 'medium' was requested.  Why didn't you
> submit a patch that follows your description and your critique to the
> logical conclusion?
>
> The rest of what I write below is based on the assumption that my
> understanding of your critique of the current code is as I describe above;
> if it is wrong, please ignore what's below, and please help me understand
> what is it that you are actually proposing and I misunderstood.
>
> So I see the following issues with your proposal (which AFAIU is different
> from the patch you actually posted):
>
> . we will examine much more fonts than we do now: the current code only
>   examines matching fonts and returns the first one that satisfies the
>   spec; your proposal will require us to examine all of them, in order to
>   find the best match out of many
> . your logic, which says that the family is so much more important than the
>   other attributes is not necessarily correct in all the cases where this
>   code is executed: I can easily imagine cases where the requested weight
>   is so important that no other "close" weight will do, and the caller
>   really wants to get an empty list rather than a deviant font
>
> So I can only agree to installing the patch along the lines of the above
> logic, i.e. to make the code relax the numerical attributes trying to keep
> the family, on the following conditions:
>
> . we add an additional loop, like the one in font_find_for_lface, after the
>   original one, and in that additional loop implement the examination of
>   candidates without filtering then by numerical attributes up front; that
>   additional loop will run only if the one before it came up with no fonts
>   that match the family
> . whether the additional loop will actually run should be controlled by a
>   variable exposed to Lisp, so that if this change causes regressions, we
>   could easily find out this is the reason, and users could work around the
>   regressions without rebuilding Emacs
>
> OK?  And note that my agreement is not to the patch you posted, but to a
> more general change in the logic of examining the candidate fonts.  This is
> how I understand what you think Emacs should do; if I misunderstood, please
> correct me.
>
> Thanks.
>
>
>
>

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

[Sorry, please ignore my previous post.]

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

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


>
> I will note right here that Emacs has no way of knowing whether the 
> fonts returned by the font driver are or aren't variable-pitch.  In 
> fact, AFAIR it is a tricky and not very reliable to try deducing that 
> from the font data Emacs records about each font (see 'font-info').  We 
> just blindly trust the font driver to give us the appropriate list of 
> fonts.  IOW, for Emacs the family is just a meaningless string.
>

In a sense the family name is just a meaningless string indeed.  The names 
"Serif", "Sans Serif" and "Monospace" are just a convention.  And indeed, 
Emacs trusts the font driver, why wouldn't it?  And what else could it do? 
The font driver itself calculates the "monospace" or "proportional" 
property based on the actual glyph widths in each font (at least that's 
what Fontconfig does).  When all glyphs have the same width, the font is 
considered monospace and its 'spacing' property is set to 100.  Otherwise 
the font is considered proportional and its 'spacing' property is set to 
0.  And if for some reason Fontconfig does not set that property correctly 
for a font, it can be forced by the user.

I don't understand what you mean by "try deducing that from the font data 
Emacs records about each font".  We could double-check that when we want a 
fixed-pitch font max-width == average-width == space-width, and when we 
want a variable-pitch font max-width != average-width != space-width, but 
what would be the benefit of doing that?

>>> why do you consider the family attribute of a face be more important 
>>> than other attributes?  if not all the attributes of a spec are 
>>> "equal" in their importance, which attributes are more important, and 
>>> why?
>>
>> Indeed, the attributes are not equal, in fact none of the attributes 
>> are ever equal in their importance.  The family is the most important 
>> one, followed by the foundry, the registry, the additional style (in 
>> that order, see the loop at the end of font_find_for_lface in which 
>> Emacs tries to make each of these attributes less specific in turn, 
>> starting with the least important one, namely the additional style), 
>> followed by the width, height (or size), weight, slant (in the order 
>> specified by the variable face-font-selection-order).
>
> That is not the relative importance of interest in the context of this 
> discussion, because Emacs already does look for a suitable font in the 
> order of the importance you describe.
>

The problem is precisely that currently it doesn't do that, when faces 
such as variable-pitch are realized.  The font list returned by 
font_list_entities called in font_find_for_lface (called by 
font_load_for_lface, called by realize_gui_face) is erroneously limited to 
fonts which have the exact same width/slant/weight attributes as the 
default face (which is _not_ the font that is being realized).  If the 
default face has for example weight = medium, and Emacs realizes the 
variable-pitch face whose only non-nil attribute (in emacs -Q) is "family 
= Sans Serif", and if there are no fonts in the Sans Serif family with a 
weight equal to medium, font_list_entities returns an empty list.  Which 
is wrong.

>
> My question was not about this basic relative importance, it was about 
> something else: when none of the fonts of the given FAMILY fits the font 
> spec, why do you consider keeping the family to be more important than 
> keeping the weight?
>

I don't understand your question.  If we agree that there is an order of 
importance in the attributes of a font spec, and that the family is the 
most important one, it seems clear to me that keeping the family is more 
important than keeping the weight.  What am I missing?  By the way, that's 
what Emacs already does, in most cases (the exception being the current 
bug).  If (in emacs -Q) you

(set-face-attribute 'variable-pitch nil :weight medium)

and if (1) there are no fonts in the Sans Serif family with a medium 
weight on your system but (2) there are fonts in the Monospace family with 
a medium weight, Emacs will not suddenly select a fixed pitch font for the 
variable-pitch face.

>
> And another question: if we are to follow face-font-selection-order, to 
> observe the relative importance of the attributes as set by the user, 
> then why did your patch only consider relaxing the weight (which is in 
> the penultimate place in the order of importance), and not the slant 
> (which is the least important attribute, in the default order we use)?
>

That's not what the last patch I had sent did (see 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#164).  In that patch 
all these attributes (weight/slant/width) were set to nil.

However, after spending a few more hours on this, I concluded that the fix 
I proposed in that patch was placed a bit too low in the abstraction 
layers, and that it is safer to place it where it belongs, namely in 
realize_gui_face.  font_find_for_lface has other callers, which may depend 
in subtle ways on its current behavior.  I attach that new, and hopefully 
final, patch.

I checked in particular it with the recipes of bug#37473, bug#57555, 
bug#59347 and bug#59371, and with some variants.  All seem to work 
correctly.

>> It is also in that loop (at the end of font_find_for_lface) that 
>> face-font-family-alternatives are used.  If the generic "Sans Serif", 
>> "Monospace" and "Monospace Serif" families that Emacs uses are not a 
>> recognized by the font driver (IOW, if font_list_entities returns an 
>> empty result for these families), Emacs falls back to some hard-coded, 
>> less generic, family names.
>
> I'm not sure I agree with this part of your description.  The code looks 
> up face-font-family-alternatives _before_ the loop in 
> font_find_for_lface, i.e., _before_ font_list_entities is called. Where 
> exactly do you see what you describe above?
>

The code in font_find_for_lface just above the final loop that looks up 
face-font-family-alternatives only populates the 'family' array. Nothing 
"concrete" happens in font_find_for_lface before the final loop: the code 
only populates the 'family', 'foundry', 'registry' and 'adstyle' arrays, 
as well as the 'work' font spec.

>>> what are the criteria here and with other similar attributes?
>>
>> The family, foundry, registry and additional style attributes are 
>> passed "as is" to the font driver, which returns a list of fonts 
>> matching these attributes.  The width, weight and/or slant are 
>> converted to numerical values (with font-{width,weight,slant}-table), 
>> and font_score, called by font_sort_entities, called by 
>> font_select_entity, which is applied on the list of fonts returned by 
>> font_list_entities, selects the best match in that list (according the 
>> the preferences in face-font-selection-order). If the width, weight 
>> and/or slant were already passed to font_list_entities, the list of 
>> fonts passed to font_select_entity contains only fonts that match these 
>> width, weight and/or slant, and that mechanism is bypassed.
>
> IOW, you want to disable the filtering of candidate fonts in 
> font_list_entities, and instead consider _all_ the candidates, selecting 
> the best match for the numerical attributes: width, height, weight, and 
> slant.
>

Yes, that's still what I want to do, but in realize_gui_face and not in 
font_find_for_lface anymore.

>
> And you don't want to relax the non-numerical attributes (family, 
> foundry, registry, adstyle) unless there's really no font, of any 
> width/height/weight/slant, installed for the specified 
> family/foundry/registry/adstyle.
>

It is not necessary to change anything there, because the loop at the end 
of font_find_for_lface already relaxes these non-numerical attributes when 
necessary: if there is no font of any width/height/weight/slant for the 
specified family/foundry/registry/adstyle, Emacs tries to set adstyle to 
nil (if it isn't already), then to set registry to nil (if it isn't 
already), then to set foundry to nil (if it isn't already).  And if doing 
that had no effect, Emacs tries the alternative family names listed in 
face-font-family-alternatives.

>
> If that is what you want us to do, then I must ask at least about the 
> height: is it really reasonable to prefer _any_ height from the given 
> family, even if it's radically different from what was requested?
>

The height (or size) attribute already receives a special treatment in 
font_find_for_lface, where it is already set to nil before being passed to 
font_list_entities.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Unset-the-weight-slant-width-in-the-spec-when-realiz.patch --]
[-- Type: text/x-diff; name=Unset-the-weight-slant-width-in-the-spec-when-realiz.patch, Size: 2825 bytes --]

From 47b4f09786f1edff0a65a9c52eb4f62612f3f5e3 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Wed, 7 Dec 2022 23:15:06 +0000
Subject: [PATCH] Unset the weight/slant/width in the spec when realizing a
 font

Between commits bf0d3f76dc (2014) and 6b1ed2f2c9 (2022),
realize_gui_face called font_load_for_lface with an empty or
partly emptied font spec, i.e. it ignored a part of its attrs
argument.  The rationale given in bug#17973, which led to
bf0d3f76dc, is not clear.  However, 6b1ed2f2c9, which passes
the full font spec to font_load_for_lface and
font_find_for_lface, leads to suboptimal font choices, for
example when the font chosen for the default face has a
weight, slant or width that is not supported by other
available fonts on the system, such as 'medium' or 'heavy'.

If these attributes are not unset here, the call to
font_list_entities in font_find_for_lface arbitrarily limits
the candidate font list to those that are perfect matches for
these attributes, which means that the scoring mechanism is
bypassed.  Note that the size attribute in spec is also unset,
in font_find_for_lface.

* src/xfaces.c (realize_gui_face): Unset the weight, slant and
width of the font spec.  Fixes bug#57555 and bug#59347.
---
 src/xfaces.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/src/xfaces.c b/src/xfaces.c
index df078227c8..71042a3126 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -6071,8 +6071,24 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE]
 	    emacs_abort ();
 	}
       if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
-	attrs[LFACE_FONT_INDEX]
-	  = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]);
+	{
+	  Lisp_Object spec = copy_font_spec (attrs[LFACE_FONT_INDEX]);
+	  /* Unset the weight, slant and width in spec.  The best
+	     possible values for these attributes is determined in
+	     font_find_for_lface, called by font_load_for_lface, when
+	     the candidate list returned by font_list_entities is
+	     sorted by font_select_entity (which calls
+	     font_sort_entities, which calls font_score).  If these
+	     attributes are not unset here, the candidate font list
+	     returned by font_list_entities only contains fonts that
+	     are exact matches for these weight, slant and width
+	     attributes, which leads to suboptimal or wrong font
+	     choices.  See bug#59347.  */
+	  ASET (spec, FONT_WEIGHT_INDEX, Qnil);
+	  ASET (spec, FONT_SLANT_INDEX, Qnil);
+	  ASET (spec, FONT_WIDTH_INDEX, Qnil);
+	  attrs[LFACE_FONT_INDEX] = font_load_for_lface (f, attrs, spec);
+	}
       if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
 	{
 	  face->font = XFONT_OBJECT (attrs[LFACE_FONT_INDEX]);
-- 
2.35.1

bug#59347: 29.0.50; `:family` face setting ignored

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

>> My question was not about this basic relative importance, it was about
>> something else: when none of the fonts of the given FAMILY fits the font
>> spec, why do you consider keeping the family to be more important than
>> keeping the weight?
> I don't understand your question.  If we agree that there is an order of
> importance in the attributes of a font spec,

Why should we agree on that?

When I specify the `:family` property on the `variable-pitch` face,
I definitely want it to take precedence over the `:weight` of the
default face, yes.

But when I specify the `weight` property of the `bold` face, it's not
clear at all that the `:family` of the default face should take precedence
over the `:weight` of the `bold` face.

FWIW, I've been running with your patch and I like the result.  I think
it's better overall, but I suspect that we still have a fundamental
problem with this notion of precedence/ordering.

Maybe the ordering should depend on the "stacking order" of the faces
and their properties.  I.e. instead of merging `bold+variable-pitch+default` to get
a set of properties on which we apply a globally-imposed ordering, we
could keep track of the relative ordering of the properties: `bold` was
on top, so the `:weight` property comes first, then came
`variable-pitch` so its `:family` property comes second and the second
comes afterwards.

So `bold+variable-pitch+default` could result in a different font than
`variable-pitch+bold+default` even if the combined properties (i.e. the
merged face) are identical.


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> But when I specify the `weight` property of the `bold` face, it's not 
> clear at all that the `:family` of the default face should take 
> precedence over the `:weight` of the `bold` face.
>

I'm not sure I understand what you mean.

Do you mean that if a user chooses a font for the default face that has a 
single variant (say 'regular'), then the 'bold' face (which does not 
specify any family) should be realized with another font which has a bold 
variant?  And that the 'italic' face should likewise be realized with 
another font which has an italic variant?

Or do you mean that if a user chooses a font for the default face, and 
then updates the weight attribute of the 'bold' face to a weight value 
that is not explicitly supported by the font of the default face (say 
'ultra-bold'), then the 'bold' face should be realized with another font 
that explicitly supports that variant?

Or do you mean something else?

FWIW, I don't think either of these options are reasonable.  IMO in the 
first case the user should just use a font which has more variants for the 
default face (there are plenty of excellent fonts), and in the second case 
it is fine to approximate the weight with the weights that are available 
in the default font.

>
> Maybe the ordering should depend on the "stacking order" of the faces 
> and their properties.  I.e. instead of merging 
> `bold+variable-pitch+default` to get a set of properties on which we 
> apply a globally-imposed ordering, we could keep track of the relative 
> ordering of the properties: `bold` was on top, so the `:weight` property 
> comes first, then came `variable-pitch` so its `:family` property comes 
> second and the second comes afterwards.
>
> So `bold+variable-pitch+default` could result in a different font than 
> `variable-pitch+bold+default` even if the combined properties (i.e. the 
> merged face) are identical.
>

Why not.  But it is already possible to fine-tune each individual face 
with the existing mechanisms, so I'm not sure the added complexity is 
worth the price.

bug#59347: 29.0.50; `:family` face setting ignored

[Yuan Fu]

> On Dec 7, 2022, at 4:27 PM, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
> 
>>> My question was not about this basic relative importance, it was about
>>> something else: when none of the fonts of the given FAMILY fits the font
>>> spec, why do you consider keeping the family to be more important than
>>> keeping the weight?
>> I don't understand your question.  If we agree that there is an order of
>> importance in the attributes of a font spec,
> 
> Why should we agree on that?
> 
> When I specify the `:family` property on the `variable-pitch` face,
> I definitely want it to take precedence over the `:weight` of the
> default face, yes.
> 
> But when I specify the `weight` property of the `bold` face, it's not
> clear at all that the `:family` of the default face should take precedence
> over the `:weight` of the `bold` face.
> 
> FWIW, I've been running with your patch and I like the result.  I think
> it's better overall, but I suspect that we still have a fundamental
> problem with this notion of precedence/ordering.
> 
> Maybe the ordering should depend on the "stacking order" of the faces
> and their properties.  I.e. instead of merging `bold+variable-pitch+default` to get
> a set of properties on which we apply a globally-imposed ordering, we
> could keep track of the relative ordering of the properties: `bold` was
> on top, so the `:weight` property comes first, then came
> `variable-pitch` so its `:family` property comes second and the second
> comes afterwards.
> 
> So `bold+variable-pitch+default` could result in a different font than
> `variable-pitch+bold+default` even if the combined properties (i.e. the
> merged face) are identical.

IIUC currently all faces are realized into a “realized face”, where each attribute is filled in with parent faces’ attributes. So there is no difference between an explicitly assigned attribute and an inherited attribute at the time when Emacs selects fonts. But if I assign only :family attribute to a face, and that face inherits a :weight attribute, naturally the :family face should take precedence when selecting fonts. OTOH if I explicitly assign a :weight attribute, and the :family attribute is inherited, then :weight should probably take precedence.

IIUC you are just describing a generalized version of this strategy, right? I think it’s a good idea. Even if we don’t generalize it into a “stacking order”, but only record what’s inherited and what’s assigned explicitly, and prioritize the explicitly assigned attributes, it would produce more intuitive results, I think.

Yuan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Wed, 07 Dec 2022 23:19:57 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 

Thanks for the detailed response.

I don't want to restart this long discussion from the beginning, so I
will limit myself only to the a few comments, and try to focus on the
patch you suggest.  We don't need to agree about the rest.

> I don't understand what you mean by "try deducing that from the font data 
> Emacs records about each font".  We could double-check that when we want a 
> fixed-pitch font max-width == average-width == space-width, and when we 
> want a variable-pitch font max-width != average-width != space-width, but 
> what would be the benefit of doing that?

(The check you are suggesting above doesn't work reliably, IME.)  My
point was that _if_ we wanted to implement some logic in Emacs that a
family implying variable-pitch fonts must yield only variable-pitch
fonts (and similarly for fixed-pitch fonts), we'd need to have code
for doing that, something that we don't have and AFAIR cannot be
implemented for all the font backends we want to support.

You don't suggest adding such a test, so we don't need to discuss this
tangent.

> > My question was not about this basic relative importance, it was about 
> > something else: when none of the fonts of the given FAMILY fits the font 
> > spec, why do you consider keeping the family to be more important than 
> > keeping the weight?
> 
> I don't understand your question.  If we agree that there is an order of 
> importance in the attributes of a font spec, and that the family is the 
> most important one, it seems clear to me that keeping the family is more 
> important than keeping the weight.  What am I missing?

The order on which we agreed is only about the numerical attributes:
width, height, weight, and slant.  I'm asking about the other
attributes, and about their importance relative to the numerical
ones.  You seem to say that this order is self-evident, and I'm
questioning that.

But we don't need to keep arguing about this tangent, either.

> I checked in particular it with the recipes of bug#37473, bug#57555, 
> bug#59347 and bug#59371, and with some variants.  All seem to work 
> correctly.

What about bug#51768, bug#52493, bug#52888, and the problem reported
in https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01643.html?

Also, did you test Emacs invocation as in "emacs -fn FONT" where FONT
is specified as Fontconfig and XLFD patterns documented in the "Fonts"
node of the Emacs user manual?  E.g., what happens if you use the
Fontconfig pattern such as
"Sans Serif-12:weight=black:slant=oblique:width=condensed"? -- does
Emacs start with a font with the expected attributes, both when
such a font which matches exactly exists and when an exact match
doesn't exist?

I'm asking this because AFAIR realize_gui_face is called at startup
for the default face of the initial frame, and we need to make sure
your proposed patch works in that case as well, even though it
basically throws away the weight, slant, and width attributes that
were requested.

> diff --git a/src/xfaces.c b/src/xfaces.c
> index df078227c8..71042a3126 100644
> --- a/src/xfaces.c
> +++ b/src/xfaces.c
> @@ -6071,8 +6071,24 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE]
>  	    emacs_abort ();
>  	}
>        if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
> -	attrs[LFACE_FONT_INDEX]
> -	  = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]);
> +	{
> +	  Lisp_Object spec = copy_font_spec (attrs[LFACE_FONT_INDEX]);
> +	  /* Unset the weight, slant and width in spec.  The best
> +	     possible values for these attributes is determined in
> +	     font_find_for_lface, called by font_load_for_lface, when
> +	     the candidate list returned by font_list_entities is
> +	     sorted by font_select_entity (which calls
> +	     font_sort_entities, which calls font_score).  If these
> +	     attributes are not unset here, the candidate font list
> +	     returned by font_list_entities only contains fonts that
> +	     are exact matches for these weight, slant and width
> +	     attributes, which leads to suboptimal or wrong font
> +	     choices.  See bug#59347.  */
> +	  ASET (spec, FONT_WEIGHT_INDEX, Qnil);
> +	  ASET (spec, FONT_SLANT_INDEX, Qnil);
> +	  ASET (spec, FONT_WIDTH_INDEX, Qnil);
> +	  attrs[LFACE_FONT_INDEX] = font_load_for_lface (f, attrs, spec);
> +	}
>        if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
>  	{
>  	  face->font = XFONT_OBJECT (attrs[LFACE_FONT_INDEX]);

As I mentioned earlier, any such change must be controlled by a
variable exposed to Lisp, which could then be used to investigate and
perhaps countermand any regressions it could cause.  If you agree to
adding such a variable, I'm okay with installing this on the emacs-29
branch.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  59347@debbugs.gnu.org
> Date: Wed, 07 Dec 2022 19:27:28 -0500
> 
> >> My question was not about this basic relative importance, it was about
> >> something else: when none of the fonts of the given FAMILY fits the font
> >> spec, why do you consider keeping the family to be more important than
> >> keeping the weight?
> > I don't understand your question.  If we agree that there is an order of
> > importance in the attributes of a font spec,
> 
> Why should we agree on that?
> 
> When I specify the `:family` property on the `variable-pitch` face,
> I definitely want it to take precedence over the `:weight` of the
> default face, yes.
> 
> But when I specify the `weight` property of the `bold` face, it's not
> clear at all that the `:family` of the default face should take precedence
> over the `:weight` of the `bold` face.

If we want to distinguish between explicitly requested attributes and
inherited attributes, we need to store this information inside the
font spec.  (We have the :user-spec attribute, but it is used for
slightly different purposes.)

Please also note that explicit requests for attributes can come from a
Lisp program, not from the user.

> FWIW, I've been running with your patch and I like the result.

Which patch is that?  The one proposed in the message to which you are
responding, or one of the earlier ones?

> Maybe the ordering should depend on the "stacking order" of the faces
> and their properties.  I.e. instead of merging `bold+variable-pitch+default` to get
> a set of properties on which we apply a globally-imposed ordering, we
> could keep track of the relative ordering of the properties: `bold` was
> on top, so the `:weight` property comes first, then came
> `variable-pitch` so its `:family` property comes second and the second
> comes afterwards.
> 
> So `bold+variable-pitch+default` could result in a different font than
> `variable-pitch+bold+default` even if the combined properties (i.e. the
> merged face) are identical.

How would you determine the order in the stack?  IOW, which attributes
will be "the first"?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Thu, 08 Dec 2022 01:07:25 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 59347@debbugs.gnu.org
> 
> Do you mean that if a user chooses a font for the default face that has a 
> single variant (say 'regular'), then the 'bold' face (which does not 
> specify any family) should be realized with another font which has a bold 
> variant?  And that the 'italic' face should likewise be realized with 
> another font which has an italic variant?

I don't think these situations are possible, at least not all of them,
because Emacs will not use a font for the default face if that font
doesn't have at least the bold or italic variant.

> FWIW, I don't think either of these options are reasonable.

You keep saying that, but you don't explain why this must be the
truth.  A user or a Lisp program can reasonably want an ultra-bold
font and consider that more important than keeping the family.  You
never explained why you thought this to be an unreasonable request.

> IMO in the first case the user should just use a font which has more
> variants for the default face (there are plenty of excellent fonts),
> and in the second case it is fine to approximate the weight with the
> weights that are available in the default font.

The questions is what should Emacs do in this case, not what the user
should do.

When I want Emacs to render text in some script, I would naturally
prefer _any_ font that is capable of supporting that script, even if
it doesn't belong to the family from which the default font is taken.
Why should width or slant or weight be treated differently?

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

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


Thanks for your detailed feedback.

>> I don't understand your question.  If we agree that there is an order 
>> of importance in the attributes of a font spec, and that the family is 
>> the most important one, it seems clear to me that keeping the family is 
>> more important than keeping the weight.  What am I missing?
>
> The order on which we agreed is only about the numerical attributes: 
> width, height, weight, and slant.  I'm asking about the other 
> attributes, and about their importance relative to the numerical ones. 
> You seem to say that this order is self-evident, and I'm questioning 
> that.
>

Okay, now I see what you mean.  It is not self-evident indeed, it is the 
intended behavior that is visible (or at least that I see) in the existing 
code, and it seems to me that it is the most natural behavior, because 
changing the font itself, e.g. from DejaVu to Courier, has more effect / 
creates more visual diversity than only changing the 
width/height/weight/slant attributes, and in graphical user interfaces 
more uniformity is better than more diversity.

>> I checked in particular it with the recipes of bug#37473, bug#57555, 
>> bug#59347 and bug#59371, and with some variants.  All seem to work 
>> correctly.
>
> What about bug#51768, bug#52493, bug#52888, and the problem reported in 
> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01643.html?
>

bug#51768: Works as expected here, with '(default ((t (:family "Source 
Code Pro" :foundry "outline" :slant normal :weight medium :height 90 
:width normal)))).

bug#52493: Works as expected here, the Inconsolata_dz font is used and 
rendered correctly.  But the original recipe doesn't work anymore (it does 
not work in Emacs 28 either), it should be :font "Inconsolata_dz" instead 
of :family "Inconsolata_dz".

bug#52888: That bug seems unrelated to the current bug, but I see no 
difference in behavior between Emacs 28 and Emacs 29 with the patch.

problem reported on emacs-devel: The medium weight is selected both for 
frames that are created by calling emacs and for frames that are created 
by calling emacsclient.

>
> Also, did you test Emacs invocation as in "emacs -fn FONT" where FONT is 
> specified as Fontconfig and XLFD patterns documented in the "Fonts" node 
> of the Emacs user manual?  E.g., what happens if you use the Fontconfig 
> pattern such as "Sans 
> Serif-12:weight=black:slant=oblique:width=condensed"? -- does Emacs 
> start with a font with the expected attributes, both when such a font 
> which matches exactly exists and when an exact match doesn't exist?
>

emacs -Q -fn 'Sans Serif-12:slant=oblique:width=condensed'

works as expected and behaves like Emacs 28: the font for the default face 
is a condensed and oblique variable-pitch sans serif font.

emacs-28 -Q -fn 'Sans Serif-12:weight=black:slant=oblique:width=condensed'

displays the same error in Emacs 28, 29, and 29 with the patch:

Font 'Sans Serif-12:weight=black:slant=oblique:width=condensed' is not 
defined

>
> As I mentioned earlier, any such change must be controlled by a variable 
> exposed to Lisp, which could then be used to investigate and perhaps 
> countermand any regressions it could cause.  If you agree to adding such 
> a variable, I'm okay with installing this on the emacs-29 branch.
>

Okay, so here is an updated patch.  To make it easier to investigate bugs 
in this area, I think it makes sense to control each field separately, and 
also to allow unsetting other attributes, which is what the new variable 
does.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Unset-the-weight-slant-width-in-the-spec-when-realiz.patch --]
[-- Type: text/x-diff; name=Unset-the-weight-slant-width-in-the-spec-when-realiz.patch, Size: 4715 bytes --]

From 60cae79ac38a2860579532bf8450d8d81688f380 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Thu, 8 Dec 2022 12:45:06 +0000
Subject: [PATCH] Unset the weight/slant/width in the spec when realizing a
 font

Between commits bf0d3f76dc (2014) and 6b1ed2f2c9 (2022),
realize_gui_face called font_load_for_lface with an empty or
partly emptied font spec, i.e. it ignored a part of its attrs
argument.  The rationale given in bug#17973, which led to
bf0d3f76dc, is not clear.  However, 6b1ed2f2c9, which passes
the full font spec to font_load_for_lface and
font_find_for_lface, leads to suboptimal font choices, for
example when the font chosen for the default face has a
weight, slant or width that is not supported by other
available fonts on the system, such as 'medium' or 'heavy'.

If these attributes are not unset here, the call to
font_list_entities in font_find_for_lface arbitrarily limits
the candidate font list to those that are perfect matches for
these attributes, which means that the scoring mechanism is
bypassed.  Note that the size attribute in spec is also unset,
in font_find_for_lface.

Also allow unsetting the other attributes, for debugging purposes.

* src/xfaces.c (realize_gui_face): Unset the weight, slant and
width of the font spec.  Fixes bug#57555 and bug#59347.
(syms_of_xfaces): New variable
'realize-gui-face-ignored-spec-attributes'.
---
 src/xfaces.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/src/xfaces.c b/src/xfaces.c
index df078227c8..c335193999 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -6071,8 +6071,42 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE]
 	    emacs_abort ();
 	}
       if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
-	attrs[LFACE_FONT_INDEX]
-	  = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]);
+	{
+	  Lisp_Object spec = copy_font_spec (attrs[LFACE_FONT_INDEX]);
+#define   MAYBE_UNSET_ATTRIBUTE(ATTR)			\
+	  if (realize_gui_face_ignored_spec_attributes	\
+	      & (1 << FONT_##ATTR##_INDEX))		\
+	    ASET (spec, FONT_##ATTR##_INDEX, Qnil);
+	  /* The default value of
+	     realize_gui_face_ignored_spec_attributes unsets the
+	     weight, slant and width in spec.  The best possible
+	     values for these attributes is determined in
+	     font_find_for_lface, called by font_load_for_lface, when
+	     the candidate list returned by font_list_entities is
+	     sorted by font_select_entity (which calls
+	     font_sort_entities, which calls font_score).  If these
+	     attributes are not unset here, the candidate font list
+	     returned by font_list_entities only contains fonts that
+	     are exact matches for these weight, slant and width
+	     attributes, which leads to suboptimal or wrong font
+	     choices.  See bug#59347.  */
+	  MAYBE_UNSET_ATTRIBUTE (WEIGHT);
+	  MAYBE_UNSET_ATTRIBUTE (SLANT);
+	  MAYBE_UNSET_ATTRIBUTE (WIDTH);
+	  /* Also allow unsetting other attributes for debugging
+	     purposes.  */
+	  MAYBE_UNSET_ATTRIBUTE (FAMILY);
+	  MAYBE_UNSET_ATTRIBUTE (FOUNDRY);
+	  MAYBE_UNSET_ATTRIBUTE (REGISTRY);
+	  MAYBE_UNSET_ATTRIBUTE (ADSTYLE);
+	  MAYBE_UNSET_ATTRIBUTE (SIZE);
+	  MAYBE_UNSET_ATTRIBUTE (DPI);
+	  MAYBE_UNSET_ATTRIBUTE (SPACING);
+	  MAYBE_UNSET_ATTRIBUTE (AVGWIDTH);
+	  MAYBE_UNSET_ATTRIBUTE (EXTRA);
+#undef    MAYBE_UNSET_ATTRIBUTE
+	  attrs[LFACE_FONT_INDEX] = font_load_for_lface (f, attrs, spec);
+	}
       if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
 	{
 	  face->font = XFONT_OBJECT (attrs[LFACE_FONT_INDEX]);
@@ -7360,6 +7394,23 @@ syms_of_xfaces (void)
 clear the face cache, see `clear-face-cache'.  */);
   face_near_same_color_threshold = 30000;
 
+  DEFVAR_INT ("realize-gui-face-ignored-spec-attributes",
+	      realize_gui_face_ignored_spec_attributes,
+	      doc: /* Ignored font-spec attributes in realize_gui_face.
+
+The value is an integer number and represents a bit mask.
+The attribute corresponding to each bit that is set is cleared in
+realize_gui_face.  The bits are: 1 = :foundry, 2 = :family,
+3 = :adstyle, 4 = :registry, 5 = :weight, 6 = :slant, 7 = :width,
+8 = :size, 9 = :dpi, 10 = :spacing, 11 = :avgwidth, 12 = extra
+attributes (:name, :script, :lang and :otf).
+
+There is no reason to change that value except for debugging purposes.  */);
+  realize_gui_face_ignored_spec_attributes =
+    (1 << FONT_WEIGHT_INDEX) |
+    (1 << FONT_SLANT_INDEX) |
+    (1 << FONT_WIDTH_INDEX);
+
 #ifdef HAVE_WINDOW_SYSTEM
   defsubr (&Sbitmap_spec_p);
   defsubr (&Sx_list_fonts);
-- 
2.35.1

bug#59347: 29.0.50; `:family` face setting ignored

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

> Do you mean that if a user chooses a font for the default face that has
> a single variant (say 'regular'), then the 'bold' face (which does not
> specify any family) should be realized with another font which has a bold
> variant?

Yes.

> And that the 'italic' face should likewise be realized with
> another font which has an italic variant?

Exactly.

> FWIW, I don't think either of these options are reasonable.

I can see reasons why some users would consider it not just reasonable
but "The Right Thing" in their specific situation.  The argument would
be as simple as "Which part of `bold` don't you understand?" and would
fundamentally be just the same as the argument that we should not use
a monospace font when the "sans-serif" family is specified.

> Why not.  But it is already possible to fine-tune each individual face with
> the existing mechanisms, so I'm not sure the added complexity is worth
> the price.

I'm not sure either, but I think the current discussion around
`variable-pitch` is similarly influenced by the fact that that we
specified the `:family` (and on top of that the face is called
"variable-pitch"), so it's obvious (to us human) that the desired result
should not be a monospace font.

IOW the context of this discussion implies a bias towards putting more
precedence on `:family` but we could restart this discussion replacing
"variable-pitch" with "bold" and "family" with "weight" and most of the
arguments would hold just as well, just favoring `:weight` this time
around :-(

In any case, I do support inclusion of your patch on the `emacs-29`
branch as "the best solution so far".


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Thu, 08 Dec 2022 12:53:15 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > The order on which we agreed is only about the numerical attributes: 
> > width, height, weight, and slant.  I'm asking about the other 
> > attributes, and about their importance relative to the numerical ones. 
> > You seem to say that this order is self-evident, and I'm questioning 
> > that.
> 
> Okay, now I see what you mean.  It is not self-evident indeed, it is the 
> intended behavior that is visible (or at least that I see) in the existing 
> code

Well, you just explained in so many words why some of the existing
code is wrong in your opinion, so arguments based on the existing code
are not very convincing...

> and it seems to me that it is the most natural behavior, because 
> changing the font itself, e.g. from DejaVu to Courier, has more effect / 
> creates more visual diversity than only changing the 
> width/height/weight/slant attributes, and in graphical user interfaces 
> more uniformity is better than more diversity.

You again seem to implicitly assume that the presence of the family
attribute means the caller must have that family or something close to
it.  But that needs not be the case, and OTOH the presence of some
other attribute, like weight, might by the same logic mean that the
caller must have that weight no matter the family.

> emacs -Q -fn 'Sans Serif-12:slant=oblique:width=condensed'
> 
> works as expected and behaves like Emacs 28: the font for the default face 
> is a condensed and oblique variable-pitch sans serif font.

And the size is indeed 12?

> Okay, so here is an updated patch.  To make it easier to investigate bugs 
> in this area, I think it makes sense to control each field separately, and 
> also to allow unsetting other attributes, which is what the new variable 
> does.

This is fine with me, although I tend to think that unsetting all the
attributes is too much.

> +  DEFVAR_INT ("realize-gui-face-ignored-spec-attributes",
> +	      realize_gui_face_ignored_spec_attributes,
> +	      doc: /* Ignored font-spec attributes in realize_gui_face.
> +
> +The value is an integer number and represents a bit mask.
> +The attribute corresponding to each bit that is set is cleared in
> +realize_gui_face.  The bits are: 1 = :foundry, 2 = :family,
> +3 = :adstyle, 4 = :registry, 5 = :weight, 6 = :slant, 7 = :width,
> +8 = :size, 9 = :dpi, 10 = :spacing, 11 = :avgwidth, 12 = extra
> +attributes (:name, :script, :lang and :otf).
> +
> +There is no reason to change that value except for debugging purposes.  */);

I suggest to describe the default value in the doc string, since
gleaning that from a (decimal) value displayed by Emacs by default is
not that easy.  Maybe also add a sentence which explains why that is
the default.

Thanks.

bug#59347: 29.0.50; `:family` face setting ignored

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

>> But when I specify the `weight` property of the `bold` face, it's not
>> clear at all that the `:family` of the default face should take precedence
>> over the `:weight` of the `bold` face.
>
> If we want to distinguish between explicitly requested attributes and
> inherited attributes, we need to store this information inside the
> font spec.  (We have the :user-spec attribute, but it is used for
> slightly different purposes.)

Indeed.

>> FWIW, I've been running with your patch and I like the result.
>
> Which patch is that?  The one proposed in the message to which you are
> responding, or one of the earlier ones?

See the hunk below.

> How would you determine the order in the stack?  IOW, which attributes
> will be "the first"?

For attributes specified directly in a face the relative order is not
specified, but attributes directly specified would come before
inherited attributes, and similarly when we merge several faces,
attributes from the first face would come before those of later faces.


        Stefan



@@ -3003,6 +3012,10 @@ font_find_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec, int
     }
   ASET (work, FONT_SIZE_INDEX, Qnil);
 
+  /* Also ignore the font weight, which when set leads to suboptimal
+     font choices.  See bug#59347.  */
+  ASET (work, FONT_WEIGHT_INDEX, Qnil);
+
   /* Foundry specification alternatives: from the most specific to the
      least specific and finally an unspecified one.  */
   foundry[0] = AREF (work, FONT_FOUNDRY_INDEX);

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gregory@heytings.org,  59347@debbugs.gnu.org
> Date: Thu, 08 Dec 2022 09:17:12 -0500
> 
> > How would you determine the order in the stack?  IOW, which attributes
> > will be "the first"?
> 
> For attributes specified directly in a face the relative order is not
> specified, but attributes directly specified would come before
> inherited attributes, and similarly when we merge several faces,
> attributes from the first face would come before those of later faces.

I'm not sure this will give correct results, especially in the
merge-face case: in many cases the faces being merged are of equal
"importance".

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> Do you mean that if a user chooses a font for the default face that has 
>> a single variant (say 'regular'), then the 'bold' face (which does not 
>> specify any family) should be realized with another font which has a 
>> bold variant?  And that the 'italic' face should likewise be realized 
>> with another font which has an italic variant?
>
> I don't think these situations are possible, at least not all of them, 
> because Emacs will not use a font for the default face if that font 
> doesn't have at least the bold or italic variant.
>

Hmmm... here at least it does.  With Fixedsys500c.ttf in 
http://www.ler.is.edu.ro/~ema/proiecte/soft/2005/apm/+predesign/fonts/fixedsys500c.zip 
(which has no variants) and (set-face-attribute 'default nil :font 
"FixedSysTTF"), the bold, italic and bold-italic faces are identical.

>> FWIW, I don't think either of these options are reasonable.
>
> You keep saying that, but you don't explain why this must be the truth. 
> A user or a Lisp program can reasonably want an ultra-bold font and 
> consider that more important than keeping the family.  You never 
> explained why you thought this to be an unreasonable request.
>

It's only my opinion, indeed.  I don't think it's a completely 
unreasonable request, but it's not what Emacs has been doing so far, and I 
do think that it's not what Emacs should do by default.  It is better to 
preserve a visual coherence / uniformity.  Also note that allowing that 
would mean that Emacs would need to consider all fonts when realizing a 
face, instead of what it does now, namely to relax the family/... 
attributes only when necessary, that is, to consider more fonts only when 
necessary.

And also note that, should a user really want a specific ultra-bold font 
for a certain face, that is already possible with the existing 
infrastructure, by making that choice explicit, e.g. (set-face-attribute 
'bold nil :font "Desired Font" :weight 'ultra-bold).  And it is also 
possible, with the existing infrastructure, to list the available fonts 
with given attribute values, e.g. with (list-fonts (font-spec :weight 
'ultra-bold)), and to select the best one in that list with an appropriate 
fourth argument to list-fonts.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Thu, 08 Dec 2022 14:59:25 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> And also note that, should a user really want a specific ultra-bold font 
> for a certain face, that is already possible with the existing 
> infrastructure, by making that choice explicit, e.g. (set-face-attribute 
> 'bold nil :font "Desired Font" :weight 'ultra-bold).  And it is also 
> possible, with the existing infrastructure, to list the available fonts 
> with given attribute values, e.g. with (list-fonts (font-spec :weight 
> 'ultra-bold)), and to select the best one in that list with an appropriate 
> fourth argument to list-fonts.

The use case which bothers me is similar to bug#51768, where users
specify certain weight or width because they like the appearance of
the resulting font, and expect Emacs to come up with the exact match,
not the best approximation.  When the family value actually names a
font (i.e., it is a very "narrow" family), that should work even if we
relax the numerical attributes, but if the family is much more
general, like "Sans Serif", the result could be different because we
still return whenever we find a first valid "approximation".

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> Okay, now I see what you mean.  It is not self-evident indeed, it is 
>> the intended behavior that is visible (or at least that I see) in the 
>> existing code
>
> Well, you just explained in so many words why some of the existing code 
> is wrong in your opinion, so arguments based on the existing code are 
> not very convincing...
>

;-)  The fact that there is a bug in the current code doesn't mean that 
its general structure (and in this case the meaning and intent of 
font_find_for_lface) is not visible.  But I may very well misunderstand 
that structure, or see things that are in fact not visible.

>> emacs -Q -fn 'Sans Serif-12:slant=oblique:width=condensed'
>>
>> works as expected and behaves like Emacs 28: the font for the default 
>> face is a condensed and oblique variable-pitch sans serif font.
>
> And the size is indeed 12?
>

I think so, yes.  The size is different with -10, -11, -12, -13, -14. 
With -12 on my computer I get the x:-urw-nimbus sans 
l-regular-i-condensed--32-231-100-100-p-144-iso8859-1 font.

>
> I suggest to describe the default value in the doc string, since 
> gleaning that from a (decimal) value displayed by Emacs by default is 
> not that easy.  Maybe also add a sentence which explains why that is the 
> default.
>

Okay, I'll do that.  Should I post the updated version of the patch before 
pushing?

bug#59347: 29.0.50; `:family` face setting ignored

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

> I'm not sure this will give correct results,

FWIW, I'm not sure either.
I suspect the only generally-valid answer is to find a way to provide
more control (e.g. add a face attribute that specifies some kind of
precedence, or tweaks the weights given to various attributes).

I'm not sure we need to go there, tho.
I think Gregory's patch is "good enough for now".


        Stean

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> I can see reasons why some users would consider it not just reasonable 
> but "The Right Thing" in their specific situation.  The argument would 
> be as simple as "Which part of `bold` don't you understand?" and would 
> fundamentally be just the same as the argument that we should not use a 
> monospace font when the "sans-serif" family is specified.
>

This (a user choosing a font for the default face that has no bold and/or 
italic variant) is really an exceptional case, in fact it wasn't easy to 
find one to test that case.  So I think the answer "The font you have 
chosen for the default (or variable-pitch, or...) face has no bold (or 
italic, or...) variant" is more than satisfactory for such exceptional 
cases, and I think that adding more complexity to an already rather 
complex code to handle that exceptional case better is not reasonable. 
Also, I'm pretty sure that with the better solution you suggest, other 
users would complain and ask "why is Emacs using so many different 
fonts?".  Again, this is just my opinion.

Perhaps the most reasonable thing to do here would be to display warnings 
in such cases.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Thu, 08 Dec 2022 15:17:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> > I suggest to describe the default value in the doc string, since 
> > gleaning that from a (decimal) value displayed by Emacs by default is 
> > not that easy.  Maybe also add a sentence which explains why that is the 
> > default.
> 
> Okay, I'll do that.  Should I post the updated version of the patch before 
> pushing?

No need, just go ahead and install.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gregory@heytings.org,  59347@debbugs.gnu.org
> Date: Thu, 08 Dec 2022 10:24:50 -0500
> 
> I think Gregory's patch is "good enough for now".

I certainly hope so.  We'll see soon enough.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> And also note that, should a user really want a specific ultra-bold font 
> for a certain face, that is already possible with the existing 
> infrastructure, by making that choice explicit, e.g. (set-face-attribute 
> 'bold nil :font "Desired Font" :weight 'ultra-bold).  And it is also 
> possible, with the existing infrastructure, to list the available fonts 
> with given attribute values, e.g. with (list-fonts (font-spec :weight 
> 'ultra-bold)), and to select the best one in that list with an 
> appropriate fourth argument to list-fonts.
>

FWIW, here is a macro to do that:

(defmacro set-mandatory-face-attribute (face frame &rest args)
   "Set attributes of FACE on FRAME from ARGS.

This function behaves like `set-face-attribute', which see,
except that attributes must match exactly, and that all available
fonts are considered."
   `(let ((spec (font-spec ,@args)))
      (let ((candidates
             (list-fonts
              spec ,frame 1
              (font-spec :width (face-attribute 'default :width)
                         :size (face-attribute 'default :height)
                         :weight (face-attribute 'default :weight)
                         :slant (face-attribute 'default :slant)))))
        (if candidates
            (set-face-attribute
             ,face ,frame
             :font (format "%s" (font-get (car candidates) :family))
             ,@args)
       (error "No available font for the specified attributes")))))

bug#59347: 29.0.50; `:family` face setting ignored

[Drew Adams]

(Mille excuses - not following this thread.
Ignore if irrelevant.)

Does some of the "problem" figuring out what to
do here perhaps come from the (misguided?)
decision to name some faces (basic/common ones,
no less) after particular face/font attributes,
such as "bold"?  Is it a good idea to have such
faces?

Maybe that's considered unavoidable, as these
are so basic/common that their names can't
really be based on any particular _use_ of the
face?  We could have an `emphasis' face, but
face `italic' is apparently meant to really
express/~hard-code "italic" appearance instead.

Nevertheless, isn't this perhaps at the root of
the problem - trying to decide how to deal with
a face whose name shouts "bold" or "fixed pitch"?

We've only got a few such appearance-name faces.
We don't have a face called "ten-point", for
instance.  Do we really need/want to have _any_
such faces?  (Abstracting from an already-sailed
argument.)

If such faces were named neutrally (e.g. `foo')
would there still be a problem/discussion here?
____

As for grouping into families: is the intention
to hard-code such groups or let users/code do
the grouping?  Is Stefan's idea to give users
and code some control over this?

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Eli Zaretskii <eliz@gnu.org>,
>         "59347@debbugs.gnu.org"
> 	<59347@debbugs.gnu.org>
> Date: Thu, 8 Dec 2022 17:29:26 +0000
> 
> Does some of the "problem" figuring out what to
> do here perhaps come from the (misguided?)
> decision to name some faces (basic/common ones,
> no less) after particular face/font attributes,
> such as "bold"?

No, that's completely unrelated.

> Nevertheless, isn't this perhaps at the root of
> the problem - trying to decide how to deal with
> a face whose name shouts "bold" or "fixed pitch"?

fixed-pitch is not a face attribute, so there's no problem whatsoever
to have a face by that name (assuming its font is specified
accordingly).

> Do we really need/want to have _any_ such faces?

It's convenient, because such a name speaks about itself.

In addition, popular font-handling systems that Emacs supports have
such broad "families" of fonts defined, whether we want that or not.
For example, "Monospace".

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> No need, just go ahead and install.
>

Now done (30e3cb2135), and closing this bug.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

Amazing.  I thought this exhausting discussion was over, but no, Po Lu 
came and "improved" the code that was agreed upon only a couple of hours 
after it was pushed, disregarding this entire discussion, the docstring of 
the variable that the commit introduced, the commit message, and without 
asking any questions.  How can that be right, how can that be acceptable?

Po Lu's commit said "there is no reason any user should have to think 
about bitmasks" even though the docstring said "there is no reason to 
change that value except for debugging purposes."  (Of course, that 
sentence was also removed from the "improved" version of the docstring.) 
It is on purpose that that variable was a bitmask and not a list, it is on 
purpose that that variable was used in a macro and not in a function: 
there is no reason that each face realization in each Emacs instance 
should spend unnecessary CPU cycles (a function call and traversing a 
list) on a variable that should never (or hardly ever) be changed, and 
that was introduced only to help debugging other potential problems in 
that subtle area of Emacs' code.

The name of the variable was changed, and the docstring was "improved", 
and became completely wrong.  It is simply untrue that this is a list of 
attributes that Emacs will "ignore when realizing a face", or in fact that 
this changes anything fundamental in the way Emacs realizes faces.

Here is again, in every possible detail, but this time in a single post, 
the analysis of this subtle bug, and the rationale of the patch that was 
agreed upon.  I explain this bug with an concrete example, with the 
'variable-pitch' face and a font with a 'medium' weight.  That example is 
only meant to illustrate the bug: the same reasoning applies for other 
faces and other font attributes (slant or width).

(1) The first (and perhaps most important) thing to note is that, before 
or after this bug fix,

(set-face-attribute 'variable-pitch nil :weight 'medium)

does _not_ change the font that is used for the 'variable-pitch' face, 
unless the font that Emacs would have selected for the 'variable-pitch' 
face without that call to set-face-attribute happens too have a 'medium' 
variant.  Fonts with an explicit 'medium' variant are rare, so most likely 
(that is, on most computers) after this call to set-face-attribute, the 
weight of the font for the 'variable-pitch' face will still be 'regular' 
(or 'normal').  IOW, when the weight/slant/width attribute of a face is 
set, Emacs tries to find a good match among the available fonts, and does 
not consider (and never considered) these attributes as strict 
requirements, _even if they are explicitly specified in the face itself_. 
Clearly, that should remain the case when these attributes are 
_unspecified_ in a face.

(2) Now suppose that a user has, in their init file, the following line:

(set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium)

That "Source Code Pro" font has more variants than most fonts, and in 
particular it has a variant with a 'medium' weight, which is slightly 
thicker than the 'regular' weight (the difference is probably only visible 
on HiDPI screens).  That apparently anecdotal detail is important: it 
implies that the weight of the default face is set to 'medium' (see 
below).

The 'variable-pitch' face is defined as follows in emacs -Q:

Family: Sans Serif
Foundry: unspecified
Width: unspecified
Height: unspecified
Weight: unspecified
Slant: unspecified

Note that, apart from the family, all other attributes are unspecified in 
that face (which means implicitly that it should be similar, with respect 
to its width/height/weight/slant, to the default face).

What happens when a buffer with a text with the 'variable-pitch' face is 
displayed is this:

(2.1) face_at_buffer_position is called, and finds (with 
Fget_text_property) that the face is 'variable-pitch'.  A few lines below, 
the following code:

/* Begin with attributes from the default face.  */
memcpy (attrs, default_face->lface, sizeof(attrs));

copies the attributes of the default face into the Lisp_Object attrs. The 
last statement of that function is:

return lookup_face (f, attrs);

which means that lookup_face is called with 'attrs' set the attributes of 
the default face, merged with the attributes of the 'variable-pitch' face 
which are, except for the family, unspecified. At that point, 'attrs' also 
contains, in its 'font' slot, a font-spec corresponding to the default 
face.  Therefore lookup_face is called with attrs[weight] = 'medium' and 
attrs[font][weight] = 'medium'. (Note that we now have _two_ copies of the 
same information ("the weight of the default face is 'medium'") in the 
same Lisp_Object.)

(2.2) lookup_face calls realize_face without changing its 'attr' 
parameter, which means that it calls realize_face with attr[weight] = 
'medium' and attrs[font][weight] = 'medium'.

(2.3) realize_face calls realize_gui_face without changing its 'attrs' 
parameter, which means that it calls realize_gui_face with attrs[weight] = 
'medium' and attrs[font][weight] = 'medium'.

(2.4) In realize_gui_face, the conditional 'if (! FONT_OBJECT_P 
(attrs[LFACE_FONT_INDEX]))' is taken, because the 'font' slot of 'attrs' 
contains a font-spec, not a font object (see 2.1).

(2.5) realize_gui_face calls copy_font_spec, which copies the font-spec 
from the 'font' slot of 'attrs' into the Lisp_Object 'spec'. Therefore 
spec[weight] = 'medium'.  I'm explaining the bug, so for now I suppose 
that the code that unsets weight in 'spec' isn't present.

(2.6) realize_gui_face calls font_load_for_lface, with 'attrs' (in which 
attrs[weight] = 'medium' and attrs[font][weight] = 'medium'), and with 
'spec' (in which spec[weight] = 'medium').  (Yes, there are now _three_ 
copies of the same information.)

(2.7) font_load_for_lface calls font_find_for_lface, with 'attrs' and 
'spec' unmodified.  Therefore attrs[weight] = 'medium', 
attrs[font][weight] = 'medium', and spec[weight] = 'medium'.

(2.8) font_find_for_lface calls copy_font_spec, and puts a copy of the 
font-spec 'spec' into the Lisp_Object 'work'.  The weight slot of 'work' 
is not modified in font_find_for_lface.

(2.9) font_find_for_lface calls (in the final loop) font_list_entities 
with 'work'.  Therefore font_list_entities is called with work[weight] = 
'medium'.  And, given that the 'variable-pitch' face is being realized, we 
also have work[family] = Sans Serif.

(2.10) font_list_entities checks the weight slot of its 'spec' parameter, 
it is set to 'medium', therefore need_filtering is set to true. 
font_list_entities also populates the Lisp_Object 'scratch_font_spec' with 
some of the attributes coming from its 'spec' parameter, in particular the 
family.  Note also that the weight slot of 'scratch_font_spec' is set to 
nil.  Therefore the 'list' function of the font driver is called with 
scratch_font_spec[family] = Sans Serif and scratch_font_spec[weight] = 
nil.  This returns a list of candidate fonts from the Sans Serif family, 
of any weight (given that scratch_font_spec[weight] = nil).

(2.11) needs_filtering is true, therefore font_delete_unmatched is called 
with 'spec' (remember that spec[weight] = 'medium').  This removes all 
fonts, from the list returned by the 'list' function, that do not have an 
explicit 'medium' variant.  As noted above, fonts with a 'medium' variant 
are comparatively rare.  On computers on which there are no fonts in the 
Sans Serif family with an explicit 'medium' variant, font_delete_unmatch 
returns an _empty_ list.  Therefore font_list_entities returns an _empty_ 
list, even if there are fonts on the computer with a weight that is close 
to the 'medium' weight, such as a 'regular' weight (see weight_table).

(2.12) Therefore, in font_find_for_lface, the call to font_select_entity, 
which is supposed to "select the best match for PIXEL_SIZE and attributes 
in ATTRS if there are several candidates", is bypassed.  Remember that 
attrs[weight] = 'medium', so if font_list_entities had for example 
returned a list with one or more fonts in the Sans Serif family with a 
'regular' weight, one of them would have been selected as the best match, 
because attrs[weight] = 'medium'.

(2.13) The fact that attrs[weight] = 'medium' (and attrs[font][weight] = 
'medium') in font_find_for_lface shows clearly that the 'medium' weight is 
not at all "ignored" by Emacs when realizing the 'variable-pitch' face. 
It is (or rather, should be) used to find a font that is similar, with 
respect to its width/height/weight/slant, to the font of the default face. 
Note that this is exactly what happens in case (1) above: when the weight 
of the font of the default face is not 'medium', setting the weight of the 
'variable-pitch' face to 'medium' does _not_ change the font of the 
'variable-pitch' face, instead Emacs selects the best possible match among 
the available fonts.

(2.14) Therefore font_find_for_lface tries to relax the 
family/foundry/registry/adstyle attributes in 'work', until it finds a 
font with a weight = 'medium'.  All other fonts are rejected, which is 
clearly wrong: the 'variable-pitch' face that is being realized does _not_ 
specify any weight.  It is only a coincidence that the 'default' face has 
a 'medium' variant, and that none of the available fonts in the Sans Serif 
family have a 'medium' variant.

(2.15) In the case that triggered this bug, a font that is not in the Sans 
Serif family but that happens to have a 'medium' variant is selected by 
Emacs, such as a non-antialiased font, or a monospace font.  In the worst 
of the worst cases, even after trying to relax all 
family/foundry/registry/adstyle attributes, no fonts with a 'medium' 
variant has been found, and the 'variable-pitch' face becomes identical to 
the default face.

With the bug fix, in (2.5), spec[weight] is set to nil.  Therefore in 
(2.10), need_filtering remains false, in (2.11) font_delete_unmatch is not 
called and font_list_entities does not return an empty list, but instead 
returns (as it should) a list of candidate fonts in the Sans Serif family, 
and in (2.12) font_select_entity does the job it is supposed to do, and 
selects the best candidate among those fonts and selects the font that is 
as close as possible to attrs[weight] = 'medium'.  Which is again exactly 
what happens in case (1) above, when the height of the default face does 
not happen to be 'medium'.

bug#59347: 29.0.50; `:family` face setting ignored

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

Gregory Heytings <gregory@heytings.org> writes:

> Amazing.  I thought this exhausting discussion was over, but no, Po Lu
> came and "improved" the code that was agreed upon only a couple of
> hours after it was pushed, disregarding this entire discussion, the
> docstring of the variable that the commit introduced, the commit
> message, and without asking any questions.  How can that be right, how
> can that be acceptable?

I did not change the behavior of that commit at all.  That can hardly be
called ``disregarding this entire discussion''.

> Po Lu's commit said "there is no reason any user should have to think
> about bitmasks" even though the docstring said "there is no reason to
> change that value except for debugging purposes."  (Of course, that
> sentence was also removed from the "improved" version of the
> docstring.)

So are you saying that users are not supposed to debug Emacs?  Then
let's stop distributing etc/DEBUG, to save cycles when unpacking Emacs!
While we're at it, let's also strip Emacs binaries by default.

> It is on purpose that that variable was a bitmask and not
> a list, it is on purpose that that variable was used in a macro and
> not in a function: there is no reason that each face realization in
> each Emacs instance should spend unnecessary CPU cycles (a function
> call and traversing a list) on a variable that should never (or hardly
> ever) be changed, and that was introduced only to help debugging other
> potential problems in that subtle area of Emacs' code.

And what was the problem with a list?  How many cycles is traversing a
list?  How many time will it take for your CPU to perform everything?
Premature optimization is the root of all evil.

If you think that is likely to lead to a real performance problem, then
you're more or less 60 years out of touch with the performance of modern
computer technology.  So, please, demonstrate that searching for a
symbol through a list with 3 elements leads to a performance problem.

Can you find any other ``debug variable'' that is a bitmask?  What if we
add different font spec attributes in the future, that bump the index
past 29 bits?  And why should Lisp have to know about bitmasks at all?

> The name of the variable was changed, and the docstring was
> "improved", and became completely wrong.  It is simply untrue that
> this is a list of attributes that Emacs will "ignore when realizing a
> face", or in fact that this changes anything fundamental in the way
> Emacs realizes faces.

Then I guess you only read the first sentence of the doc string.  Read
it again, specifically:

  tells Emacs to ignore the `:weight', `:slant' and `:width' face
  attributes when searching for a font and an exact match could not be
				       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  found for the font attributes specified in the face being realized.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What is inaccurate about that statement? Unlike your doc string, it does
not need the caller to know about the inner workings of the face code
(how many of our users even know about the function realize_gui_face?)

But anyway if you respond with some more nonsense, don't expect me to
reply.  Please demonstrate:

  - There is a real performance problem with searching through a list
    with three elements upon face realization.

  - My change actually changes the behavior of the variable, leading to
    this bug not being fixed.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> It is on purpose that that variable was a bitmask and not a list, it is 
>> on purpose that that variable was used in a macro and not in a 
>> function: there is no reason that each face realization in each Emacs 
>> instance should spend unnecessary CPU cycles (a function call and 
>> traversing a list) on a variable that should never (or hardly ever) be 
>> changed, and that was introduced only to help debugging other potential 
>> problems in that subtle area of Emacs' code.
>
> And what was the problem with a list?  How many cycles is traversing a 
> list?  How many time will it take for your CPU to perform everything?
>

My measurements indicate that the "improved" code is ~20 slower in an 
optimized build, and I care about performance.  That's a lot to handle a 
variable that is, in fact, a near-constant.

Once again, that variable isn't supposed to be changed by users.  It is 
there for one purpose: if a user reports a bug about font selection, it 
will be possible to ask them to set that variable to this-and-that value 
(most probably 0 and most-positive-fixnum) to check whether Emacs behaves 
better.

Of course, brave souls can also try to change it, if they want.

>
> So, please, demonstrate that searching for a symbol through a list with 
> 3 elements leads to a performance problem.
>

It is not "searching for a symbol through a list with three elements", it 
is 12 function calls, each of which traverses a list of three elements.

>> and an exact match could not be found for the font attributes specified 
>> in the face being realized.
>
> What is inaccurate about that statement?
>

The post to which you are replying explains in every possible detail why 
that statement is wrong.  That you don't have the patience to read a 300 
posts long bug thread is one thing, that you don't have the patience to 
read a 100 lines long explanation, and bluntly declare that it is 
"nonsense", is another.

>
> Unlike your doc string, it does not need the caller to know about the 
> inner workings of the face code (how many of our users even know about 
> the function realize_gui_face?)
>

And the purpose of that variable is precisely that: making it possible to 
dynamically control an implementation detail.  It is _not_ supposed to be 
set by users who do not know about the inner workings of the face code.

bug#59347: 29.0.50; `:family` face setting ignored

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

Gregory Heytings <gregory@heytings.org> writes:

> My measurements indicate that the "improved" code is ~20 slower in an
> optimized build, and I care about performance.  That's a lot to handle
> a variable that is, in fact, a near-constant.

And how many microseconds is ``~20x slower''? Do you actually see the
drop in performance?

You remind me of the people who painstakingly profile GL, and get angry
over a drop in performance from ``26450fps'' to ``9300fps'', when the
end result is still more than sufficient to match the display refresh.

With the following instrumentation:

diff --git a/src/xfaces.c b/src/xfaces.c
index 88d3a79f8c0..0eced7b7be5 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -6089,8 +6089,15 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE]
 	}
       if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
 	{
+	  unsigned long long t1, t2;
+	  struct timespec timespec;
+
 	  spec = copy_font_spec (attrs[LFACE_FONT_INDEX]);
 
+	  clock_gettime (CLOCK_THREAD_CPUTIME_ID, &timespec);
+	  t1 = (timespec.tv_sec * 1000000
+		+ timespec.tv_nsec / 1000);
+
 	  /* Unset several values in SPEC, usually the width, slant,
 	     and weight.  The best possible values for these
 	     attributes is determined in font_find_for_lface, called
@@ -6117,6 +6124,11 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE]
 	  font_unset_attribute (spec, FONT_SPACING_INDEX, QCspacing);
 	  font_unset_attribute (spec, FONT_AVGWIDTH_INDEX, QCavgwidth);
 
+	  clock_gettime (CLOCK_THREAD_CPUTIME_ID, &timespec);
+	  t2 = (timespec.tv_sec * 1000000
+		+ timespec.tv_nsec / 1000);
+	  fprintf (stderr, "that was: %ull us\n", t2 - t1);
+
 	  attrs[LFACE_FONT_INDEX] = font_load_for_lface (f, attrs, spec);
 	}
       if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))

all that code takes somewhere between 2 to 4 microseconds to complete
for me, in a build with optimizations enabled.  I don't know how many
faces you think people have to realize, or what kind of 1950s computer
you have in mind, but on any reasonably modern computer it will take
somewhere around 500,000 to 250,000 faces for this extra code to make a
single seconds' difference.

> Once again, that variable isn't supposed to be changed by users.  It
> is there for one purpose: if a user reports a bug about font
> selection, it will be possible to ask them to set that variable to
> this-and-that value (most probably 0 and most-positive-fixnum) to
> check whether Emacs behaves better.
>
> Of course, brave souls can also try to change it, if they want.

No matter whether or not a variable is supposed to be changed by the
user, it must not be a bitmask!  And in general, it must not be
confusing to users.  Users are supposed to debug Emacs.

> It is not "searching for a symbol through a list with three elements",
> it is 12 function calls, each of which traverses a list of three
> elements.

And how many microseconds is that?  How is it significant, compared to
the time it takes to send the glyphs in the resulting font off to the X
server and wait for a reply?  Or to allocate all the colors in the face?
Or to simply search through the color cache for all those colors?

> The post to which you are replying explains in every possible detail
> why that statement is wrong.  That you don't have the patience to read
> a 300 posts long bug thread is one thing, that you don't have the
> patience to read a 100 lines long explanation, and bluntly declare
> that it is "nonsense", is another.

Then feel free to write a better doc string, instead of outright
reverting the change.  The only requirement is that it must describe the
variable in terms that users can understand, even if it is somewhat
vague.

> And the purpose of that variable is precisely that: making it possible
> to dynamically control an implementation detail.  It is _not_ supposed
> to be set by users who do not know about the inner workings of the
> face code.

If users are not supposed to set the variable, then delete it
completely.  Otherwise, users will set it, and documentation they cannot
understand is just asking for trouble.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> No matter whether or not a variable is supposed to be changed by the 
> user, it must not be a bitmask!  And in general, it must not be 
> confusing to users.  Users are supposed to debug Emacs.
>

They are not supposed to debug a (very subtle) part of the code they do 
not understand.

>
> Then feel free to write a better doc string, instead of outright 
> reverting the change.  The only requirement is that it must describe the 
> variable in terms that users can understand, even if it is somewhat 
> vague.
>

That's not possible.  You would understand that if you had read the post 
upthread in which I describe in every detail what that variable does and 
why.  But you don't care, apparently.

>
> If users are not supposed to set the variable, then delete it 
> completely.  Otherwise, users will set it, and documentation they cannot 
> understand is just asking for trouble.
>

That variable was added because Eli asked for it, to help debugging future 
problems in that (very subtle) area on the code.  But I already said that 
three or four times, and you don't care, apparently.

bug#59347: 29.0.50; `:family` face setting ignored

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

Gregory Heytings <gregory@heytings.org> writes:

> They are not supposed to debug a (very subtle) part of the code they
> do not understand.

By that logic, I should just delete the entire "If you encounter X
protocol errors" section from etc/DEBUG.

> That's not possible.  You would understand that if you had read the
> post upthread in which I describe in every detail what that variable
> does and why.  But you don't care, apparently.

Yes, I don't.  The fundamental problem I have with the doc string is
that it did not say what it does, or what it is supposed to debug, in a
manner users can understand.

If someone finds a problem that can be fixed by removing ":medium" from
the list, he will type "C-h a font attributes RET" and come across the
variable, change it, and find out that it is fixed that way.  Then, when
the bug is reported, we will immediately know roughly where the problem
lies, skipping past a whole week of pain and anguish.

A doc string which only talks about realize_gui_face and bits in a
bitmask will at most lead to confusion and an immediate bug report.
That's assuming the variable can be found at all.

Even the following doc string helps more in that situation:

  "This variable controls some aspects of how Emacs understands
   font-related face attributes in face specifications.  Try removing or
   adding new elements to this list should you come across problems with
   Emacs ignoring fonts that do not have certain weights or widths."

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> That's not possible.  You would understand that if you had read the 
>> post upthread in which I describe in every detail what that variable 
>> does and why.  But you don't care, apparently.
>
> Yes, I don't.  The fundamental problem I have with the doc string is 
> that it did not say what it does, or what it is supposed to debug, in a 
> manner users can understand.
>

If that was actually your concern, you would have asked a question here, 
something like "Can we perhaps clarify this-or-that aspect of the 
docstring".  Instead you brutally changed everything to "improve" it 
according to your own, and only your own, understanding of "improvement".

That's not how things are supposed to happen here, sorry.

>
> If someone finds a problem that can be fixed by removing ":medium" from 
> the list, he will type "C-h a font attributes RET" and come across the 
> variable, change it, and find out that it is fixed that way.
>

C-h a does not search in docstrings.

bug#59347: 29.0.50; `:family` face setting ignored

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

Gregory Heytings <gregory@heytings.org> writes:

> If that was actually your concern, you would have asked a question
> here, something like "Can we perhaps clarify this-or-that aspect of
> the docstring".  Instead you brutally changed everything to "improve"
> it according to your own, and only your own, understanding of
> "improvement".
>
> That's not how things are supposed to happen here, sorry.

The way it works here, AFAICT, is that someone who sees a problem with a
recently installed change will correct it first.  If you wanted to make
further adjustments to the doc string after that (Eli already did), you
could have gone ahead and avoided the entire discussion, but instead you
chose to revert the change and go back to using a bitmask and the old
doc string.

> C-h a does not search in docstrings.

Then maybe the _new_ variable names (both mine and Eli's) match.  The
conclusion is the same, because the doc string is printed in the
Apropros buffer.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, Po Lu <luangruo@yahoo.com>, 
>     59347@debbugs.gnu.org
> 
> 
> Amazing.  I thought this exhausting discussion was over, but no, Po Lu 
> came and "improved" the code that was agreed upon only a couple of hours 
> after it was pushed, disregarding this entire discussion, the docstring of 
> the variable that the commit introduced, the commit message, and without 
> asking any questions.  How can that be right, how can that be acceptable?

This discussion went overboard, IMO.  I indeed think that Po Lu should
have discussed his changes before doing them, but your reaction, in
particular the revert, is also overreaction.

> The name of the variable was changed, and the docstring was "improved", 
> and became completely wrong.  It is simply untrue that this is a list of 
> attributes that Emacs will "ignore when realizing a face", or in fact that 
> this changes anything fundamental in the way Emacs realizes faces.

If this is the doc string you saw, you were not looking at an
up-to-date tree.  I renamed the variable and rewrote the doc string
soon after Po Lu made his changes; the word "ignore" (which I agree is
inaccurate) is no longer there.  If you still have comments on the
current doc string, please speak up.

> Here is again, in every possible detail, but this time in a single post, 
> the analysis of this subtle bug, and the rationale of the patch that was 
> agreed upon.  I explain this bug with an concrete example, with the 
> 'variable-pitch' face and a font with a 'medium' weight.  That example is 
> only meant to illustrate the bug: the same reasoning applies for other 
> faces and other font attributes (slant or width).

Thanks.  This is a good description, and it is good to have it in the
bug discussion, for posterity.

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>
> 
>   - unsetting the "extra" attribute is not safe on the Haiku port.

If this is so, why not disable that only for Haiku?

>   - the bitmask variable is a real nusiance for anyone trying to
>     debug Emacs or change the layout of the font attribute index
>     enumerator.

"Nuisance" is an exaggeration.  But I agree that using more
descriptive values is more convenient, if and when someone needs to
change the default value.  And I have a proposal for how to do this
without sacrificing performance; read on.

> Just because a bug has been closed does NOT mean the change in it is no
> longer subject to scrutiny.

But, after such a long and painful discussion, it would have been
prudent to talk first and cut the metal later.  And, btw, your change
had two copy/paste typos, which would have probably be avoided if you
posted the patch first.

> all that code takes somewhere between 2 to 4 microseconds to complete
> for me, in a build with optimizations enabled.  I don't know how many

People are reportedly running Emacs sessions with several thousands of
faces, in which case 2 to 4 usec per face could add up to a
significant number.  So it cannot do any harm to try to make the
"usual" case faster.

> From: Gregory Heytings <gregory@heytings.org>
> To: Po Lu <luangruo@yahoo.com>
> cc: emacs-devel@gnu.org
>
> >> Of course I did.  That you did not read it is another thing.
> >
> > You did not.  The only real technical argument you put forth was some 
> > nonsense about FOR_EACH_TAIL being slow.
> >
> 
> "Nonsense", again?  Thank you!

Yes, let's please avoid nasty unfriendly language.

> From: Po Lu <luangruo@yahoo.com>
> To: Gregory Heytings <gregory@heytings.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  monnier@iro.umontreal.ca,
>   59347@debbugs.gnu.org
> 
> The fundamental problem I have with the doc string is
> that it did not say what it does, or what it is supposed to debug, in a
> manner users can understand.

Does the current doc string have any such problems you can spot?

Anyway, here's my proposal:

 . we change the default value of the variable to be t, and document
   that this stands for (:weight :width :slant)
 . we change the code to reset only those 3 attributes when the
   value is t, and to reset nothing when the value is nil
 . the (slower) code which loops over the list will only run if the
   value of the variable is neither nil nor t
 . we avoid resetting the :extra attribute on Haiku

Is this okay with you both?  I volunteer to make these changes if you
agree.

Thanks.

bug#59347: 29.0.50; `:family` face setting ignored

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

> And what was the problem with a list?  How many cycles is traversing a
> list?  How many time will it take for your CPU to perform everything?
> Premature optimization is the root of all evil.

It was not premature optimization.
It was the simpler way to write the code.

Your patch made the C code more complex (not just slower) for the
benefit of a cleaner ELisp-level interface.  A better way to get that
same result would be to write an ELisp function on top of Gregory's
bitmask variable.
This way, you'd get a clean&simple&efficient C code still with
a convenient ELisp API.

Any chance someone could do that so we can move on?


        Stefan

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Gregory Heytings <gregory@heytings.org>,  Eli Zaretskii <eliz@gnu.org>,
>   59347@debbugs.gnu.org
> Date: Mon, 12 Dec 2022 10:30:10 -0500
> 
> Your patch made the C code more complex (not just slower) for the
> benefit of a cleaner ELisp-level interface.  A better way to get that
> same result would be to write an ELisp function on top of Gregory's
> bitmask variable.
> This way, you'd get a clean&simple&efficient C code still with
> a convenient ELisp API.
> 
> Any chance someone could do that so we can move on?

I suggested a simple way out of this, I hope you like it.  If there
are no objections, I will implement it soon.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>
> your reaction, in particular the revert, is also overreaction.
>

Okay.  But note that it wasn't a blunt revert, it was accompanied with a 
long, precise, detailed rationale.  Unlike the commit it reverted, and the 
revert revert.

>> The fundamental problem I have with the doc string is that it did not 
>> say what it does, or what it is supposed to debug, in a manner users 
>> can understand.
>
> Does the current doc string have any such problems you can spot?
>

Yes.  The gist of the original docstring, which was correct (and I think 
understandable even by non-experts), is this:

"When the font chosen for the default face has a weight, slant or width 
that is not supported by other available fonts on the system, such as 
'medium', Emacs may select suboptimal fonts for other faces."

As I explained, the root of this bug is an undesirable interaction with 
the weight/slant/widht (and possibly other attributes, time will tell us) 
of the _default_ face, when they are set to unusual/less common values, 
with the fonts that are selected for _other faces_ in which these 
attributes are _unspecified_.

That is a very specific corner case, and the current variable name and 
docstring does not reflect this (namely, that it's a very specific corner 
case, in a very specific area of code).  The current docstring means 
something completely different.  Saying for example that "face attributes 
will be treated as "soft" constraints when looking for suitable fonts: if 
an exact match is not possible, a font can be selected that is a close, 
but not an exact, match" means that when an attribute is _specified_ Emacs 
will treat that attribute value in a lax manner, which is already (and has 
always been) the case, and when the purpose of that variable is to affect 
font selection for faces whose attributes are _unspecified_.

This was also important:

"There is no reason to change that value except for debugging purposes."

Of course users are free to ignore that warning, but at least they have 
been warned.

>
> Anyway, here's my proposal:
>
> . we change the default value of the variable to be t, and document that 
> this stands for (:weight :width :slant)
>
> . we change the code to reset only those 3 attributes when the value is 
> t, and to reset nothing when the value is nil
>
> . the (slower) code which loops over the list will only run if the value 
> of the variable is neither nil nor t
>
> . we avoid resetting the :extra attribute on Haiku
>

As long as we don't traverse a Lisp list each time a face is realized in 
the default case, I'm fine with this.  I think Stefan's proposal (write an 
Elisp-level interface) is slightly better, though, because if we find out 
in Emacs 30 or 31 that some other attribute must also be unset, the 
meaning of 't' would have to change.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 16:12:22 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> Yes.  The gist of the original docstring, which was correct (and I think 
> understandable even by non-experts), is this:
> 
> "When the font chosen for the default face has a weight, slant or width 
> that is not supported by other available fonts on the system, such as 
> 'medium', Emacs may select suboptimal fonts for other faces."

This was important when the default value was hard to understand.  It
is less important when the default value is easily understood and
interpreted.  I will add something along these lines when I will
change the default to t, because then the effect will again be less
clear.

> As I explained, the root of this bug is an undesirable interaction with 
> the weight/slant/widht (and possibly other attributes, time will tell us) 
> of the _default_ face, when they are set to unusual/less common values, 
> with the fonts that are selected for _other faces_ in which these 
> attributes are _unspecified_.

That is the case that was in your mind, but that is not the only case
where realize_gui_face is called.  It is also called when faces are
merged (which happens a lot in Emacs), and in a few other cases.  In
those cases I think the situation is less black-and-white, since each
attribute can come from a different face, or be inherited.

> That is a very specific corner case, and the current variable name and 
> docstring does not reflect this (namely, that it's a very specific corner 
> case, in a very specific area of code).  The current docstring means 
> something completely different.  Saying for example that "face attributes 
> will be treated as "soft" constraints when looking for suitable fonts: if 
> an exact match is not possible, a font can be selected that is a close, 
> but not an exact, match" means that when an attribute is _specified_ Emacs 
> will treat that attribute value in a lax manner, which is already (and has 
> always been) the case, and when the purpose of that variable is to affect 
> font selection for faces whose attributes are _unspecified_.

When you say that it "is already (and has always been) the case",
AFAIU you are talking about the lower-level code, not about the level
on which this new variable makes a difference.  On this level, the
match is required to be exact, and clearing some attributes allows it
to be "lax".  Otherwise, why did we make this change, if the
constraints were already not "hard"?

> This was also important:
> 
> "There is no reason to change that value except for debugging purposes."

I will add something like that.

> > Anyway, here's my proposal:
> >
> > . we change the default value of the variable to be t, and document that 
> > this stands for (:weight :width :slant)
> >
> > . we change the code to reset only those 3 attributes when the value is 
> > t, and to reset nothing when the value is nil
> >
> > . the (slower) code which loops over the list will only run if the value 
> > of the variable is neither nil nor t
> >
> > . we avoid resetting the :extra attribute on Haiku
> >
> 
> As long as we don't traverse a Lisp list each time a face is realized in 
> the default case, I'm fine with this.

OK, thanks.

> I think Stefan's proposal (write an Elisp-level interface) is
> slightly better, though, because if we find out in Emacs 30 or 31
> that some other attribute must also be unset, the meaning of 't'
> would have to change.

I wouldn't invest more energy in this at this point, since we don't
yet know whether it is needed and how badly.  Our hope, after all, is
that no one will ever need to change the default value of this
variable.  From that perspective, inventing fancy functions to make it
easier to customize a bitmap is overkill.

bug#59347: 29.0.50; `:family` face setting ignored

[Gregory Heytings]

>> Yes.  The gist of the original docstring, which was correct (and I 
>> think understandable even by non-experts), is this:
>>
>> "When the font chosen for the default face has a weight, slant or width 
>> that is not supported by other available fonts on the system, such as 
>> 'medium', Emacs may select suboptimal fonts for other faces."
>
> This was important when the default value was hard to understand.  It is 
> less important when the default value is easily understood and 
> interpreted.  I will add something along these lines when I will change 
> the default to t, because then the effect will again be less clear.
>

Indeed, but what I meant is that the conditions in which that variable is 
useful / has an effect, and the intended effect, were indicated in the 
original docstring:

If the font chosen for the _default_ face has an attribute value that is 
not supported by other available fonts on the system,

then the font chosen for _other_ faces [in which that attribute is 
unspecified] may be suboptimal.

The part between brackets was missing from the original docstring.

>> As I explained, the root of this bug is an undesirable interaction with 
>> the weight/slant/widht (and possibly other attributes, time will tell 
>> us) of the _default_ face, when they are set to unusual/less common 
>> values, with the fonts that are selected for _other faces_ in which 
>> these attributes are _unspecified_.
>
> That is the case that was in your mind, but that is not the only case 
> where realize_gui_face is called.  It is also called when faces are 
> merged (which happens a lot in Emacs), and in a few other cases.  In 
> those cases I think the situation is less black-and-white, since each 
> attribute can come from a different face, or be inherited.
>

Would you mind giving a few more details?  I don't really understand what 
you mean here.

>> That is a very specific corner case, and the current variable name and 
>> docstring does not reflect this (namely, that it's a very specific 
>> corner case, in a very specific area of code).  The current docstring 
>> means something completely different.  Saying for example that "face 
>> attributes will be treated as "soft" constraints when looking for 
>> suitable fonts: if an exact match is not possible, a font can be 
>> selected that is a close, but not an exact, match" means that when an 
>> attribute is _specified_ Emacs will treat that attribute value in a lax 
>> manner, which is already (and has always been) the case, and when the 
>> purpose of that variable is to affect font selection for faces whose 
>> attributes are _unspecified_.
>
> When you say that it "is already (and has always been) the case", AFAIU 
> you are talking about the lower-level code, not about the level on which 
> this new variable makes a difference.  On this level, the match is 
> required to be exact, and clearing some attributes allows it to be 
> "lax".  Otherwise, why did we make this change, if the constraints were 
> already not "hard"?
>

Again I'm not sure I understand what you mean.  What I meant is that Emacs 
treats the attribute values of faces in a lax way, and always did.  After

(set-face-attribute 'variable-pitch nil :weight 'medium)

there is no guarantee that the font used for the variable-pitch face has a 
medium weight, IOW, that weight is not a hard constraint.  The only 
guarantee is that, after this call, Emacs will prefer, for that face, a 
regular font to a light one, or a semi-bold font to a bold one.

The fact that, after 6b1ed2f2c9, the attribute values of the default face 
became hard constraints for other faces in which these attributes are 
unspecified is a bug, that this change fixes.

bug#59347: 29.0.50; `:family` face setting ignored

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

Eli Zaretskii <eliz@gnu.org> writes:

> If this is so, why not disable that only for Haiku?

It's also rather pointless to disable just :extra, as it's a property
list of extra properties, which should have their individual options.

> "Nuisance" is an exaggeration.  But I agree that using more
> descriptive values is more convenient, if and when someone needs to
> change the default value.  And I have a proposal for how to do this
> without sacrificing performance; read on.

> People are reportedly running Emacs sessions with several thousands of
> faces, in which case 2 to 4 usec per face could add up to a
> significant number.  So it cannot do any harm to try to make the
> "usual" case faster.

I agree it can't do harm, but 2 to 4 usec times a few thousand faces is
still probably going to be less than 50 msec, so that still won't hurt.
And that's assuming all the faces are realized at once.

> Anyway, here's my proposal:
>
>  . we change the default value of the variable to be t, and document
>    that this stands for (:weight :width :slant)
>  . we change the code to reset only those 3 attributes when the
>    value is t, and to reset nothing when the value is nil
>  . the (slower) code which loops over the list will only run if the
>    value of the variable is neither nil nor t
>  . we avoid resetting the :extra attribute on Haiku
>
> Is this okay with you both?  I volunteer to make these changes if you
> agree.

I'm fine with that, thanks.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 21:28:58 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
> 
> 
> >> "When the font chosen for the default face has a weight, slant or width 
> >> that is not supported by other available fonts on the system, such as 
> >> 'medium', Emacs may select suboptimal fonts for other faces."
> >
> > This was important when the default value was hard to understand.  It is 
> > less important when the default value is easily understood and 
> > interpreted.  I will add something along these lines when I will change 
> > the default to t, because then the effect will again be less clear.
> >
> 
> Indeed, but what I meant is that the conditions in which that variable is 
> useful / has an effect, and the intended effect, were indicated in the 
> original docstring:
> 
> If the font chosen for the _default_ face has an attribute value that is 
> not supported by other available fonts on the system,
> 
> then the font chosen for _other_ faces [in which that attribute is 
> unspecified] may be suboptimal.
> 
> The part between brackets was missing from the original docstring.

I don't see it as an important part of the doc string.  The purpose of
the doc string is not to explain how Emacs finds fonts, it is to
explain what's this variable's effect on that.

> >> As I explained, the root of this bug is an undesirable interaction with 
> >> the weight/slant/widht (and possibly other attributes, time will tell 
> >> us) of the _default_ face, when they are set to unusual/less common 
> >> values, with the fonts that are selected for _other faces_ in which 
> >> these attributes are _unspecified_.
> >
> > That is the case that was in your mind, but that is not the only case 
> > where realize_gui_face is called.  It is also called when faces are 
> > merged (which happens a lot in Emacs), and in a few other cases.  In 
> > those cases I think the situation is less black-and-white, since each 
> > attribute can come from a different face, or be inherited.
> >
> 
> Would you mind giving a few more details?  I don't really understand what 
> you mean here.

I don't really see what more could I say.  I'm talking about face
merging, when none of the faces is 'default'.  If this is still not
enough, please look at the callers of realize_gui_face, and I hope you
will see what I mean.

> >> That is a very specific corner case, and the current variable name and 
> >> docstring does not reflect this (namely, that it's a very specific 
> >> corner case, in a very specific area of code).  The current docstring 
> >> means something completely different.  Saying for example that "face 
> >> attributes will be treated as "soft" constraints when looking for 
> >> suitable fonts: if an exact match is not possible, a font can be 
> >> selected that is a close, but not an exact, match" means that when an 
> >> attribute is _specified_ Emacs will treat that attribute value in a lax 
> >> manner, which is already (and has always been) the case, and when the 
> >> purpose of that variable is to affect font selection for faces whose 
> >> attributes are _unspecified_.
> >
> > When you say that it "is already (and has always been) the case", AFAIU 
> > you are talking about the lower-level code, not about the level on which 
> > this new variable makes a difference.  On this level, the match is 
> > required to be exact, and clearing some attributes allows it to be 
> > "lax".  Otherwise, why did we make this change, if the constraints were 
> > already not "hard"?
> 
> Again I'm not sure I understand what you mean.  What I meant is that Emacs 
> treats the attribute values of faces in a lax way, and always did.  After
> 
> (set-face-attribute 'variable-pitch nil :weight 'medium)
> 
> there is no guarantee that the font used for the variable-pitch face has a 
> medium weight, IOW, that weight is not a hard constraint.  The only 
> guarantee is that, after this call, Emacs will prefer, for that face, a 
> regular font to a light one, or a semi-bold font to a bold one.
> 
> The fact that, after 6b1ed2f2c9, the attribute values of the default face 
> became hard constraints for other faces in which these attributes are 
> unspecified is a bug, that this change fixes.

Look farther back in history than just 6b1ed2f2c9, and you will see
that 6b1ed2f2c9 simply restored the situation which existed until
not-so-long before that.  It is NOT the change which introduced this
issue, it is a change that fixed another issue.  So yes, these
attributes were "hard" constraints for most of the history of the
current display engine.  And for good reasons, I might add.

bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  monnier@iro.umontreal.ca,
>   59347@debbugs.gnu.org
> Date: Tue, 13 Dec 2022 09:16:48 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If this is so, why not disable that only for Haiku?
> 
> It's also rather pointless to disable just :extra, as it's a property
> list of extra properties, which should have their individual options.

I eventually came to the conclusion that there's no such attribute as
:extra, it is just our internal implementation detail.  So I removed
it from this stuff.

> > Is this okay with you both?  I volunteer to make these changes if you
> > agree.
> 
> I'm fine with that, thanks.

OK, so I've now made those changes on the emacs-29 branch.