bug#64270: 30.0.50; Font update for no toolkit menu

bug#64270: 30.0.50; Font update for no toolkit menu

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

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


Hi,

I'd like to be able to update the menu font (for the no toolkit build)
at runtime.  For this, my idea was to pass the font (from say the menu
face) to the XMenuCreate call in x_menu_show.

I thought that the font's XLFD string would be a good candidate to pass
this information since it should be understood by XLoadQueryFont.  But
unfortunately, the XLFD returned by font_unparse_xlfd are not.

For instance, XLoadQueryFont can understand
"-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*" but not
"-misc-fixed-regular-r-normal-*-22-*-*-*-*-*-*-*".  Do you think I need
a function to « normalize » the XLFD returned by font_unparse_xlfd?  Or
maybe I'm missing something?

FTR, here is a patch of what I have started:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: menu.patch --]
[-- Type: text/x-patch, Size: 5245 bytes --]

diff --git a/oldXMenu/Create.c b/oldXMenu/Create.c
index 9518b2833a2..27cf14b0529 100644
--- a/oldXMenu/Create.c
+++ b/oldXMenu/Create.c
@@ -120,7 +120,8 @@ XAllocDisplayColor(Display *display, Colormap map, char const *colorName,
 
 
 XMenu *
-XMenuCreate(Display *display, Window parent, register char const *def_env)
+XMenuCreate(Display *display, Window parent, register char const *def_env,
+	    register char const *def_font)
                                 /* ID of previously opened display */
                   		/* Window ID of the menu's parent window. */
                            	/* X Defaults program environment name. */
@@ -322,7 +323,10 @@ XMenuCreate(Display *display, Window parent, register char const *def_env)
   }
 
   def_val = x_get_resource_string ("paneFont", "PaneFont");
-  if (def_val != NULL) p_fnt_name = def_val;
+  if (def_val != NULL)
+    p_fnt_name = def_val;
+  else if (def_font != NULL)
+    p_fnt_name = def_font;
 
   def_val = x_get_resource_string ("paneForeground", "PaneForeground");
   if (
@@ -378,7 +382,10 @@ XMenuCreate(Display *display, Window parent, register char const *def_env)
   }
 
   def_val = x_get_resource_string ("selectionFont", "SelectionFont");
-  if (def_val != NULL) s_fnt_name = def_val;
+  if (def_val != NULL)
+    s_fnt_name = def_val;
+  else if (def_font != NULL)
+    s_fnt_name = def_font;
 
   def_val = x_get_resource_string ("selectionForeground", "SelectionForeground");
   if (
@@ -568,15 +575,22 @@ XMenuCreate(Display *display, Window parent, register char const *def_env)
 
   p_fnt_info = XLoadQueryFont(display, p_fnt_name);
   if (p_fnt_info == NULL) {
-    _XMErrorCode = XME_OPEN_FONT;
-    return(NULL);
-
+    /* Retry with most basic default.  */
+    p_fnt_info = XLoadQueryFont(display, DEF_P_FNT_NAME);
+    if (p_fnt_info == NULL) {
+      _XMErrorCode = XME_OPEN_FONT;
+      return(NULL);
+    }
   }
 
   s_fnt_info = XLoadQueryFont(display, s_fnt_name);
   if (s_fnt_info == NULL) {
-    _XMErrorCode = XME_OPEN_FONT;
-    return(NULL);
+    /* Retry with most basic default.  */
+    s_fnt_info = XLoadQueryFont(display, DEF_S_FNT_NAME);
+    if (s_fnt_info == NULL) {
+      _XMErrorCode = XME_OPEN_FONT;
+      return(NULL);
+    }
   }
   /*
    * Calculate the fixed padding value in pixels for each font.
diff --git a/oldXMenu/XMenu.h b/oldXMenu/XMenu.h
index 2eee18a3844..e920f266697 100644
--- a/oldXMenu/XMenu.h
+++ b/oldXMenu/XMenu.h
@@ -263,7 +263,7 @@ #define XME_CREATE_TRANSP	16
 /*
  * XMenu library routine declarations.
  */
-XMenu *XMenuCreate(Display *display, Window parent, char const *def_env);
+XMenu *XMenuCreate(Display *display, Window parent, char const *def_env, char const *def_font);
 int XMenuAddPane(Display *display, XMenu *menu, char const *label, int active);
 int XMenuAddSelection(Display *display, XMenu *menu, int p_num, char *data, char *label, int active, char const *help);
 int XMenuInsertPane(XMenu *menu, int p_num, char *label, int active);
diff --git a/src/msdos.c b/src/msdos.c
index 75a39045cee..f380bef7c51 100644
--- a/src/msdos.c
+++ b/src/msdos.c
@@ -2947,7 +2947,7 @@ IT_menu_display (XMenu *menu, int y, int x, int pn, int *faces, int disp_help)
 /* Create a brand new menu structure.  */
 
 XMenu *
-XMenuCreate (Display *foo1, Window foo2, char *foo3)
+XMenuCreate (Display *foo1, Window foo2, char *foo3, char *foo4)
 {
   return IT_menu_create ();
 }
diff --git a/src/msdos.h b/src/msdos.h
index 94878d25b35..aac6d8d65ca 100644
--- a/src/msdos.h
+++ b/src/msdos.h
@@ -143,7 +143,7 @@ #define ButtonReleaseMask 0
   const char **help_text;
 } XMenu;
 
-XMenu *XMenuCreate (Display *, Window, char *);
+XMenu *XMenuCreate (Display *, Window, char *, char *);
 int XMenuAddPane (Display *, XMenu *, char const *, int);
 int XMenuAddSelection (Display *, XMenu *, int, int, char *, int, char const *);
 void XMenuLocate (Display *, XMenu *, int, int, int, int,
diff --git a/src/xmenu.c b/src/xmenu.c
index 6d32aa3e078..8beb6534bdf 100644
--- a/src/xmenu.c
+++ b/src/xmenu.c
@@ -2564,6 +2564,11 @@ x_menu_show (struct frame *f, int x, int y, int menuflags,
   int maxwidth;
   int dummy_int;
   unsigned int dummy_uint;
+  struct face *face;
+  Lisp_Object font_object;
+  /* char xlfd[512] = "-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*"; */
+  char xlfd[512];
+
   specpdl_ref specpdl_count = SPECPDL_INDEX ();
 
   eassert (FRAME_X_P (f) || FRAME_MSDOS_P (f));
@@ -2586,8 +2591,20 @@ x_menu_show (struct frame *f, int x, int y, int menuflags,
 		&dummy_int, &dummy_int, &dummy_uint, &dummy_uint,
 		&dummy_uint, &dummy_uint);
 
-  /* Make the menu on that window.  */
-  menu = XMenuCreate (FRAME_X_DISPLAY (f), root, "emacs");
+  /* Get default frame font's XLFD and make the menu on that
+     window.  */
+  face = FACE_FROM_ID_OR_NULL (f, MENU_FACE_ID);
+  if (face && face->font) {
+    XSETFONT (font_object, face->font);
+    if (font_unparse_xlfd (font_object, 0, xlfd, 512) <= 0)
+      {
+	*error_name = "XLFD unparse failed";
+	return Qnil;
+      }
+    menu = XMenuCreate (FRAME_X_DISPLAY (f), root, "emacs", xlfd);
+  } else
+    menu = XMenuCreate (FRAME_X_DISPLAY (f), root, "emacs", NULL);
+
   if (menu == NULL)
     {
       *error_name = "Can't create menu";

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


Best regards,



In GNU Emacs 30.0.50 (build 2, x86_64-unknown-openbsd7.3, cairo version
 1.17.8) of 2023-06-23 built on computer
Repository revision: c31688cb061bf76c5300abadaf6fe589603b0184
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101006
System Description: OpenBSD computer 7.3 GENERIC.MP#1125 amd64

Configured using:
 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin
 --with-x-toolkit=no --without-sound --without-compress-install
 CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBXML2 MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG
SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  gnus-message-citation-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  gdb-many-windows: t
  display-time-mode: t
  display-battery-mode: t
  server-mode: t
  mml-mode: t
  shell-dirtrack-mode: t
  override-global-mode: t
  repeat-mode: t
  desktop-save-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
/home/manuel/.el/nov hides /home/manuel/.emacs.d/elpa/nov-20230421.1548/nov
/home/manuel/.emacs.d/elpa/ef-themes-1.1.1/theme-loaddefs hides /home/manuel/emacs/share/emacs/30.0.50/lisp/theme-loaddefs

Features:
(shadow emacsbug whitespace vc-annotate mailalias flow-fill sort
gnus-cite mail-extr textsec uni-scripts idna-mapping ucs-normalize
uni-confusable textsec-check gnus-async gnus-bcklg gnus-ml gnus-topic
mm-archive url-cache qp utf-7 imap rfc2104 nndoc nndraft nnmh
network-stream nnfolder nnml gnus-agent gnus-srvr gnus-score score-mode
nnvirtual nntp gnus-cache nnrss find-dired ffap two-column
detached-shell dabbrev magit-extras face-remap magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func magit-diff
smerge-mode diff git-commit log-edit add-log magit-core magit-autorevert
magit-margin magit-transient magit-process with-editor magit-mode
transient magit-git magit-section magit-utils dash gdb-mi bindat gud
misearch multi-isearch pulse descr-text ibuf-ext ibuffer
ibuffer-loaddefs asm-mode css-mode imenu make-mode org-indent org-agenda
warnings 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 sh-script smie treesit executable pascal view org-element
org-persist org-id org-refile avl-tree oc-basic ol-eww eww url-queue
mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview
doc-view jka-compr image-mode exif ol-bibtex 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-src ob-comint org-pcomplete org-list org-footnote
org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table
ol org-fold org-fold-core org-keys oc org-loaddefs org-version
org-compat org-macs mule-util gnus-dired vc-cvs vc-rcs log-view
pcvs-util vc-hg conf-mode vc-git diff-mode vc bug-reference
vc-dispatcher vc-svn paredit time battery cus-load exwm-randr xcb-randr
exwm-config ido exwm exwm-input xcb-keysyms xcb-xkb exwm-manage
exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core
xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types xcb-debug server
modus-operandi-theme modus-themes zone speed-type url-http url-auth
url-gw nsm compat ytdious mingus libmpdee reporter edebug debug
backtrace detached-init detached autorevert filenotify transmission
color calc-bin calc-ext calc calc-loaddefs rect calc-macs supercite regi
ebdb-message ebdb-gnus gnus-msg 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 gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
yank-media puny rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range
mm-util mail-prsvr wid-edit ebdb-mua ebdb-com crm ebdb-format ebdb
mailabbrev eieio-opt speedbar ezimage dframe find-func eieio-base pcase
timezone icalendar visual-basic-mode cl web-mode derived disp-table
erlang-start smart-tabs-mode skeleton cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs slime-asdf grep
slime-tramp tramp rx tramp-loaddefs trampver tramp-integration files-x
tramp-compat xdg shell pcomplete parse-time iso8601 time-date
format-spec slime-fancy slime-indentation slime-cl-indent cl-indent
slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree advice slime-scratch slime-presentations
bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse slime
apropos compile text-property-search etags fileloop generator xref
project arc-mode archive-mode noutline outline icons pp comint ansi-osc
ansi-color ring hyperspec thingatpt slime-autoloads edmacro kmacro
use-package-bind-key bind-key appt diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs dired-x dired-aux dired dired-loaddefs
notifications dbus xml cl-extra help-mode use-package-core repeat
easy-mmode desktop frameset debbugs-autoloads detached-autoloads
ebdb-autoloads ef-themes-autoloads exwm-autoloads hyperbole-autoloads
magit-autoloads git-commit-autoloads finder-inf magit-section-autoloads
dash-autoloads nov-autoloads esxml-autoloads kv-autoloads osm-autoloads
paredit-autoloads rust-mode-autoloads speed-type-autoloads
transmission-autoloads visual-fill-column-autoloads
with-editor-autoloads info compat-autoloads ytdious-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 cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv 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 oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind kqueue lcms2 dynamic-setting system-font-setting
font-render-setting cairo xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 2106933 883109) (symbols 48 78760 81)
 (strings 32 379449 53218) (string-bytes 1 11549873)
 (vectors 16 201452) (vector-slots 8 3851627 142928)
 (floats 8 717 6576) (intervals 56 260191 18474) (buffers 984 187))

-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

[Eli Zaretskii]

> Date: Sat, 24 Jun 2023 19:00:04 +0200
> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I'd like to be able to update the menu font (for the no toolkit build)
> at runtime.  For this, my idea was to pass the font (from say the menu
> face) to the XMenuCreate call in x_menu_show.

Doesn' paneFont X resource already allow that?

> I thought that the font's XLFD string would be a good candidate to pass
> this information since it should be understood by XLoadQueryFont.  But
> unfortunately, the XLFD returned by font_unparse_xlfd are not.
> 
> For instance, XLoadQueryFont can understand
> "-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*" but not
> "-misc-fixed-regular-r-normal-*-22-*-*-*-*-*-*-*".  Do you think I need
> a function to « normalize » the XLFD returned by font_unparse_xlfd?  Or
> maybe I'm missing something?
> 
> FTR, here is a patch of what I have started:

Did you try a font name instead?

bug#64270: 30.0.50; Font update for no toolkit menu

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

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> I thought that the font's XLFD string would be a good candidate to pass
> this information since it should be understood by XLoadQueryFont.  But
> unfortunately, the XLFD returned by font_unparse_xlfd are not.
>
> For instance, XLoadQueryFont can understand
> "-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*" but not
> "-misc-fixed-regular-r-normal-*-22-*-*-*-*-*-*-*".  Do you think I need
> a function to « normalize » the XLFD returned by font_unparse_xlfd?  Or
> maybe I'm missing something?

I don't understand why you're trying to ``normalize'' the second invalid
XLFD: RELATIVE_SETWIDTH can't be `regular'.

bug#64270: 30.0.50; Font update for no toolkit menu

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 24 Jun 2023 19:00:04 +0200
>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> I'd like to be able to update the menu font (for the no toolkit build)
>> at runtime.  For this, my idea was to pass the font (from say the menu
>> face) to the XMenuCreate call in x_menu_show.
>
> Doesn' paneFont X resource already allow that?

Yes it does and I'm using it.  What I'm trying to achieve here is to be
able to change those menu face dynamically: if a user changes the main
frame font with 'set-frame-font', the menu font is also changed.

>> I thought that the font's XLFD string would be a good candidate to pass
>> this information since it should be understood by XLoadQueryFont.  But
>> unfortunately, the XLFD returned by font_unparse_xlfd are not.
>> 
>> For instance, XLoadQueryFont can understand
>> "-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*" but not
>> "-misc-fixed-regular-r-normal-*-22-*-*-*-*-*-*-*".  Do you think I need
>> a function to « normalize » the XLFD returned by font_unparse_xlfd?  Or
>> maybe I'm missing something?
>> 
>> FTR, here is a patch of what I have started:
>
> Did you try a font name instead?

No I did not try that.
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

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

Po Lu <luangruo@yahoo.com> writes:

> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
>> I thought that the font's XLFD string would be a good candidate to pass
>> this information since it should be understood by XLoadQueryFont.  But
>> unfortunately, the XLFD returned by font_unparse_xlfd are not.
>>
>> For instance, XLoadQueryFont can understand
>> "-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*" but not
>> "-misc-fixed-regular-r-normal-*-22-*-*-*-*-*-*-*".  Do you think I need
>> a function to « normalize » the XLFD returned by font_unparse_xlfd?  Or
>> maybe I'm missing something?
>
> I don't understand why you're trying to ``normalize'' the second invalid
> XLFD: RELATIVE_SETWIDTH can't be `regular'.

Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
what I get with 'C-u C-x =':

    ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

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

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>>
>>> I thought that the font's XLFD string would be a good candidate to pass
>>> this information since it should be understood by XLoadQueryFont.  But
>>> unfortunately, the XLFD returned by font_unparse_xlfd are not.
>>>
>>> For instance, XLoadQueryFont can understand
>>> "-misc-fixed-medium-r-normal-*-22-*-*-*-*-*-*-*" but not
>>> "-misc-fixed-regular-r-normal-*-22-*-*-*-*-*-*-*".  Do you think I need
>>> a function to « normalize » the XLFD returned by font_unparse_xlfd?  Or
>>> maybe I'm missing something?
>>
>> I don't understand why you're trying to ``normalize'' the second invalid
>> XLFD: RELATIVE_SETWIDTH can't be `regular'.
>
> Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
> what I get with 'C-u C-x =':
>
>     ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)

``XLFD'' strings generated by Emacs aren't guaranteed to be
X11-compatible; Emacs is only designed to read them.  I don't remember
whether or not this is intentional, so you will have to ask Kenichi
Handa, but I have a sinking suspicion that he is not around anymore...

bug#64270: 30.0.50; Font update for no toolkit menu

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

Po Lu <luangruo@yahoo.com> writes:

[...]

>> Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
>> what I get with 'C-u C-x =':
>>
>>     ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
>
> ``XLFD'' strings generated by Emacs aren't guaranteed to be
> X11-compatible; Emacs is only designed to read them.

Too bad because I think that it would have been a good way to
communicate this information to oldXMenu.

> I don't remember whether or not this is intentional, so you will have
> to ask Kenichi Handa, but I have a sinking suspicion that he is not
> around anymore...

Hum ok, maybe I could try to contact him by mail.
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

[Robert Pluim]

>>>>> On Tue, 27 Jun 2023 15:48:29 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
    >> Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
    >> what I get with 'C-u C-x =':
    >> 
    >> ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)

    Po Lu> ``XLFD'' strings generated by Emacs aren't guaranteed to be
    Po Lu> X11-compatible; Emacs is only designed to read them.  I don't remember
    Po Lu> whether or not this is intentional, so you will have to ask Kenichi
    Po Lu> Handa, but I have a sinking suspicion that he is not around anymore...

For at least 15 years prior to Larsʼ changes to support 'medium'
fonts, that would have returned

ftcrhb:-Misc-Fixed-medium-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)

Itʼs easy enough to get that back, if we want.

diff --git a/src/font.c b/src/font.c
index de8748dd857..814a4810a24 100644
--- a/src/font.c
+++ b/src/font.c
@@ -72,7 +72,7 @@ #define DEFAULT_ENCODING Qiso8859_1
   { 40, { "ultra-light", "ultralight", "extra-light", "extralight" }},
   { 50, { "light" }},
   { 55, { "semi-light", "semilight", "demilight" }},
-  { 80, { "regular", "normal", "unspecified", "book" }},
+  { 80, { "normal", "regular", "unspecified", "book" }},
   { 100, { "medium" }},
   { 180, { "semi-bold", "semibold", "demibold", "demi-bold", "demi" }},
   { 200, { "bold" }},


Robert
-- 

bug#64270: 30.0.50; Font update for no toolkit menu

[Robert Pluim]

>>>>> On Tue, 27 Jun 2023 10:37:30 +0200, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Tue, 27 Jun 2023 15:48:29 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
    >>> Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
    >>> what I get with 'C-u C-x =':
    >>> 
    >>> ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)

    Robert>     Po Lu> ``XLFD'' strings generated by Emacs aren't guaranteed to be
    Robert>     Po Lu> X11-compatible; Emacs is only designed to read them.  I don't remember
    Robert>     Po Lu> whether or not this is intentional, so you will have to ask Kenichi
    Robert>     Po Lu> Handa, but I have a sinking suspicion that he is not around anymore...

    Robert> For at least 15 years prior to Larsʼ changes to support 'medium'
    Robert> fonts, that would have returned

    Robert> ftcrhb:-Misc-Fixed-medium-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)

I mean:

ftcrhb:-Misc-Fixed-normal-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)

Robert
-- 

bug#64270: 30.0.50; Font update for no toolkit menu

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

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 27 Jun 2023 10:37:30 +0200, Robert Pluim <rpluim@gmail.com> said:
>
>>>>>> On Tue, 27 Jun 2023 15:48:29 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
>     >>> Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
>     >>> what I get with 'C-u C-x =':
>     >>> 
>     >>> ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
>
>     Robert>     Po Lu> ``XLFD'' strings generated by Emacs aren't guaranteed to be
>     Robert>     Po Lu> X11-compatible; Emacs is only designed to read them.  I don't remember
>     Robert>     Po Lu> whether or not this is intentional, so you will have to ask Kenichi
>     Robert>     Po Lu> Handa, but I have a sinking suspicion that he is not around anymore...
>
>     Robert> For at least 15 years prior to Larsʼ changes to support 'medium'
>     Robert> fonts, that would have returned
>
>     Robert> ftcrhb:-Misc-Fixed-medium-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
>
> I mean:
>
> ftcrhb:-Misc-Fixed-normal-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
>
> Robert

Right, but the problem is different: X doesn't support medium at all,
but calls Emacs's `normal' `medium'.  Here are all the valid values for
an XLFD:

0	Undefined
10	UltraLight
20	ExtraLight	 
30	Light	 
40	SemiLight
50	Medium
60	SemiBold
70	Bold	 
80	ExtraBold
90	UltraBold

bug#64270: 30.0.50; Font update for no toolkit menu

[Robert Pluim]

>>>>> On Tue, 27 Jun 2023 16:55:39 +0800, Po Lu <luangruo@yahoo.com> said:

    Po Lu> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Tue, 27 Jun 2023 10:37:30 +0200, Robert Pluim <rpluim@gmail.com> said:
    >> 
    >>>>>>> On Tue, 27 Jun 2023 15:48:29 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
    >> >>> Ah then I have a bug in Emacs' XLFD generation on my system.  Here is
    >> >>> what I get with 'C-u C-x =':
    >> >>> 
    >> >>> ftcrhb:-Misc-Fixed-regular-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
    >> 
    Robert> Po Lu> ``XLFD'' strings generated by Emacs aren't guaranteed to be
    Robert> Po Lu> X11-compatible; Emacs is only designed to read them.  I don't remember
    Robert> Po Lu> whether or not this is intentional, so you will have to ask Kenichi
    Robert> Po Lu> Handa, but I have a sinking suspicion that he is not around anymore...
    >> 
    Robert> For at least 15 years prior to Larsʼ changes to support 'medium'
    Robert> fonts, that would have returned
    >> 
    Robert> ftcrhb:-Misc-Fixed-medium-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
    >> 
    >> I mean:
    >> 
    >> ftcrhb:-Misc-Fixed-normal-normal-normal-*-18-*-*-*-c-90-iso10646-1 (#x59)
    >> 
    >> Robert

    Po Lu> Right, but the problem is different: X doesn't support medium at all,
    Po Lu> but calls Emacs's `normal' `medium'.  Here are all the valid values for
    Po Lu> an XLFD:

    Po Lu> 0	Undefined
    Po Lu> 10	UltraLight
    Po Lu> 20	ExtraLight	 
    Po Lu> 30	Light	 
    Po Lu> 40	SemiLight
    Po Lu> 50	Medium
    Po Lu> 60	SemiBold
    Po Lu> 70	Bold	 
    Po Lu> 80	ExtraBold
    Po Lu> 90	UltraBold

OK, but we could still fix this niggle in `font_unparse_xlfd' (if I
call it a regression, can it go in emacs-29? 😸)

Robert
-- 

bug#64270: 30.0.50; Font update for no toolkit menu

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

Robert Pluim <rpluim@gmail.com> writes:

> OK, but we could still fix this niggle in `font_unparse_xlfd' (if I
> call it a regression, can it go in emacs-29? 😸)

I'm not so sure... I think it is more important that Emacs be able to
parse its own XLFDs without losing information than it is for XLFDs it
generates to be understood by X, since XLFDs are often used in Lisp as a
printable replacement for font specifications.

bug#64270: 30.0.50; Font update for no toolkit menu

[Robert Pluim]

>>>>> On Tue, 27 Jun 2023 17:49:15 +0800, Po Lu <luangruo@yahoo.com> said:

    Po Lu> Robert Pluim <rpluim@gmail.com> writes:
    >> OK, but we could still fix this niggle in `font_unparse_xlfd' (if I
    >> call it a regression, can it go in emacs-29? 😸)

    Po Lu> I'm not so sure... I think it is more important that Emacs be able to
    Po Lu> parse its own XLFDs without losing information than it is for XLFDs it
    Po Lu> generates to be understood by X, since XLFDs are often used in Lisp as a
    Po Lu> printable replacement for font specifications.

I donʼt think the change I proposed changes the parsing, only the
unparsing: the weights are compared in order when parsing. Or did you
mean you want Emacs to preserve the non-standard 'regular' for some
reason?

Robert
-- 

bug#64270: 30.0.50; Font update for no toolkit menu

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

Po Lu <luangruo@yahoo.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> OK, but we could still fix this niggle in `font_unparse_xlfd' (if I
>> call it a regression, can it go in emacs-29? 😸)
>
> I'm not so sure... I think it is more important that Emacs be able to
> parse its own XLFDs without losing information than it is for XLFDs it
> generates to be understood by X, since XLFDs are often used in Lisp as a
> printable replacement for font specifications.

I imagined something like that.  So maybe I need a new function.  For
example `x_normalize_xlfd'?
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 64270@debbugs.gnu.org
> Date: Tue, 27 Jun 2023 09:04:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Sat, 24 Jun 2023 19:00:04 +0200
> >> From:  Manuel Giraud via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> I'd like to be able to update the menu font (for the no toolkit build)
> >> at runtime.  For this, my idea was to pass the font (from say the menu
> >> face) to the XMenuCreate call in x_menu_show.
> >
> > Doesn' paneFont X resource already allow that?
> 
> Yes it does and I'm using it.  What I'm trying to achieve here is to be
> able to change those menu face dynamically: if a user changes the main
> frame font with 'set-frame-font', the menu font is also changed.

Do you mean that the menu font will change to the same font as the
frame's default face?  If so, I'm not sure that's a good idea: menu
fonts are normally different from the default font, and in particular
menus look nicer with variable-pitch fonts, whereas the default face
should preferably use a fixed-pitch font.

If this is not what you meant, then how would Emacs know which font to
select for menus when the default face's font is changed?

bug#64270: 30.0.50; Font update for no toolkit menu

[Eli Zaretskii]

> Cc: 64270@debbugs.gnu.org, Manuel Giraud <manuel@ledu-giraud.fr>
> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 27 Jun 2023 11:42:19 +0200
> 
> OK, but we could still fix this niggle in `font_unparse_xlfd' (if I
> call it a regression, can it go in emacs-29? 😸)

No, of course not.  What real-life problem in Emacs 29 would that
solve?

bug#64270: 30.0.50; Font update for no toolkit menu

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

Robert Pluim <rpluim@gmail.com> writes:

> I donʼt think the change I proposed changes the parsing, only the
> unparsing: the weights are compared in order when parsing. Or did you
> mean you want Emacs to preserve the non-standard 'regular' for some
> reason?

No, my point is neither `normal' nor `regular' are standard.  Only
`medium', which conflicts with Emacs, now that it understands `medium'
as separate from the others.

bug#64270: 30.0.50; Font update for no toolkit menu

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

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> I imagined something like that.  So maybe I need a new function.  For
> example `x_normalize_xlfd'?

Perhaps you should instead consider the reason you need to use XLFDs to
specify fonts.  It is highly unlikely for fonts loaded by FreeType-based
font backends to also exist on the X server, and thus be accessible from
the X core protocol in the first place.

TRT is probably to write a new menu library that uses Emacs's own font
backends for displaying text.

bug#64270: 30.0.50; Font update for no toolkit menu

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

Po Lu <luangruo@yahoo.com> writes:

> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
>> I imagined something like that.  So maybe I need a new function.  For
>> example `x_normalize_xlfd'?
>
> Perhaps you should instead consider the reason you need to use XLFDs to
> specify fonts.  It is highly unlikely for fonts loaded by FreeType-based
> font backends to also exist on the X server, and thus be accessible from
> the X core protocol in the first place.

I know.  I guess that XLFD representation is legacy at this point… but
so is oldXMenu.

> TRT is probably to write a new menu library that uses Emacs's own font
> backends for displaying text.

Yes I know that too.  But the Emacs' display system is quite hard to
grok and I imagine that those menu will end up being child frames (but
maybe that is the way to go).
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 64270@debbugs.gnu.org
>> Date: Tue, 27 Jun 2023 09:04:51 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Sat, 24 Jun 2023 19:00:04 +0200
>> >> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> >> 
>> >> I'd like to be able to update the menu font (for the no toolkit build)
>> >> at runtime.  For this, my idea was to pass the font (from say the menu
>> >> face) to the XMenuCreate call in x_menu_show.
>> >
>> > Doesn' paneFont X resource already allow that?
>> 
>> Yes it does and I'm using it.  What I'm trying to achieve here is to be
>> able to change those menu face dynamically: if a user changes the main
>> frame font with 'set-frame-font', the menu font is also changed.
>
> Do you mean that the menu font will change to the same font as the
> frame's default face?  If so, I'm not sure that's a good idea: menu
> fonts are normally different from the default font, and in particular
> menus look nicer with variable-pitch fonts, whereas the default face
> should preferably use a fixed-pitch font.
>
> If this is not what you meant, then how would Emacs know which font to
> select for menus when the default face's font is changed?

For my usage, I imagine that yes the menu font would change when I
change the frame's default face.  But this because my menu face is
already derived from the default face.

For the general usage, my idea (and what I start doing in my patch, see
my first message) is to query the MENU_FACE_ID.  So the font into the
menus would change if the user modify its menu face.
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 64270@debbugs.gnu.org
> Date: Tue, 27 Jun 2023 16:13:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If this is not what you meant, then how would Emacs know which font to
> > select for menus when the default face's font is changed?
> 
> For my usage, I imagine that yes the menu font would change when I
> change the frame's default face.  But this because my menu face is
> already derived from the default face.
> 
> For the general usage, my idea (and what I start doing in my patch, see
> my first message) is to query the MENU_FACE_ID.  So the font into the
> menus would change if the user modify its menu face.

This is a misunderstanding: I didn't ask what would be the trigger to
change the font.  I asked how would Emacs know _which_ font to choose
for the menus?

bug#64270: 30.0.50; Font update for no toolkit menu

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 64270@debbugs.gnu.org
>> Date: Tue, 27 Jun 2023 16:13:15 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > If this is not what you meant, then how would Emacs know which font to
>> > select for menus when the default face's font is changed?
>> 
>> For my usage, I imagine that yes the menu font would change when I
>> change the frame's default face.  But this because my menu face is
>> already derived from the default face.
>> 
>> For the general usage, my idea (and what I start doing in my patch, see
>> my first message) is to query the MENU_FACE_ID.  So the font into the
>> menus would change if the user modify its menu face.
>
> This is a misunderstanding: I didn't ask what would be the trigger to
> change the font.  I asked how would Emacs know _which_ font to choose
> for the menus?

I also am not sure I understand.  I don't think that Emacs has to choose
a font here.  It would use the font used for the menu face.  What am I
missing?
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 64270@debbugs.gnu.org
> Date: Tue, 27 Jun 2023 18:07:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel@ledu-giraud.fr>
> >> Cc: 64270@debbugs.gnu.org
> >> Date: Tue, 27 Jun 2023 16:13:15 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > If this is not what you meant, then how would Emacs know which font to
> >> > select for menus when the default face's font is changed?
> >> 
> >> For my usage, I imagine that yes the menu font would change when I
> >> change the frame's default face.  But this because my menu face is
> >> already derived from the default face.
> >> 
> >> For the general usage, my idea (and what I start doing in my patch, see
> >> my first message) is to query the MENU_FACE_ID.  So the font into the
> >> menus would change if the user modify its menu face.
> >
> > This is a misunderstanding: I didn't ask what would be the trigger to
> > change the font.  I asked how would Emacs know _which_ font to choose
> > for the menus?
> 
> I also am not sure I understand.  I don't think that Emacs has to choose
> a font here.  It would use the font used for the menu face.  What am I
> missing?

How is this different from what happens today?

bug#64270: 30.0.50; Font update for no toolkit menu

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

>> >> For my usage, I imagine that yes the menu font would change when I
>> >> change the frame's default face.  But this because my menu face is
>> >> already derived from the default face.
>> >> 
>> >> For the general usage, my idea (and what I start doing in my patch, see
>> >> my first message) is to query the MENU_FACE_ID.  So the font into the
>> >> menus would change if the user modify its menu face.
>> >
>> > This is a misunderstanding: I didn't ask what would be the trigger to
>> > change the font.  I asked how would Emacs know _which_ font to choose
>> > for the menus?
>> 
>> I also am not sure I understand.  I don't think that Emacs has to choose
>> a font here.  It would use the font used for the menu face.  What am I
>> missing?

It's unlikely that the font used for the menu face can actually be used
by the XMenu library, since Emacs is in no way limited to utilizing core
X fonts.

I seriously suggest not touching the oldXMenu library and working on
something else.

Thanks.

bug#64270: 30.0.50; Font update for no toolkit menu

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 64270@debbugs.gnu.org
>> Date: Tue, 27 Jun 2023 18:07:33 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> >> Cc: 64270@debbugs.gnu.org
>> >> Date: Tue, 27 Jun 2023 16:13:15 +0200
>> >> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> > If this is not what you meant, then how would Emacs know which font to
>> >> > select for menus when the default face's font is changed?
>> >> 
>> >> For my usage, I imagine that yes the menu font would change when I
>> >> change the frame's default face.  But this because my menu face is
>> >> already derived from the default face.
>> >> 
>> >> For the general usage, my idea (and what I start doing in my patch, see
>> >> my first message) is to query the MENU_FACE_ID.  So the font into the
>> >> menus would change if the user modify its menu face.
>> >
>> > This is a misunderstanding: I didn't ask what would be the trigger to
>> > change the font.  I asked how would Emacs know _which_ font to choose
>> > for the menus?
>> 
>> I also am not sure I understand.  I don't think that Emacs has to choose
>> a font here.  It would use the font used for the menu face.  What am I
>> missing?
>
> How is this different from what happens today?

It does not work today at least for the no-toolkit build.  The menu face
changes the face of the menu bar but not the font in the menus itselves.
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

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

Po Lu <luangruo@yahoo.com> writes:

>>> >> For my usage, I imagine that yes the menu font would change when I
>>> >> change the frame's default face.  But this because my menu face is
>>> >> already derived from the default face.
>>> >> 
>>> >> For the general usage, my idea (and what I start doing in my patch, see
>>> >> my first message) is to query the MENU_FACE_ID.  So the font into the
>>> >> menus would change if the user modify its menu face.
>>> >
>>> > This is a misunderstanding: I didn't ask what would be the trigger to
>>> > change the font.  I asked how would Emacs know _which_ font to choose
>>> > for the menus?
>>> 
>>> I also am not sure I understand.  I don't think that Emacs has to choose
>>> a font here.  It would use the font used for the menu face.  What am I
>>> missing?
>
> It's unlikely that the font used for the menu face can actually be used
> by the XMenu library, since Emacs is in no way limited to utilizing core
> X fonts.

That is interesting.  This means that a face used in a frame might not
exists in a form that is loadable by XLoadQueryFont, right?  So I think
it is real shortcoming of what I wanted to do.

> I seriously suggest not touching the oldXMenu library and working on
> something else.

Yes, I know.  Everytime I'm trying to do something on oldXMenu this idea
keep resurfacing.  But it is quite a task and oldXMenu is already here
and not that bad.  Do you think that child frames could be a starting
point for menus?
-- 
Manuel Giraud

bug#64270: 30.0.50; Font update for no toolkit menu

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

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> That is interesting.  This means that a face used in a frame might not
> exists in a form that is loadable by XLoadQueryFont, right?  So I think
> it is real shortcoming of what I wanted to do.

Yes.  The X core font requests can only utilize fonts that are present
on the X server, which precludes using any font from a FreeType-based
font driver.

> Yes, I know.  Everytime I'm trying to do something on oldXMenu this idea
> keep resurfacing.  But it is quite a task and oldXMenu is already here
> and not that bad.  Do you think that child frames could be a starting
> point for menus?

I don't think so; frames are quite resource intensive and slow to
create.  Child frames have also always been a mess, and they are
obscured by ancestor windows.  If we were to implement menus in terms of
frames, it would be better to apply an owner-events grab to an
override-redirect frame (as usual among X clients), but even that would
be slow.