* bug#64270: 30.0.50; Font update for no toolkit menu
@ 2023-06-24 17:00 Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-24 17:16 ` Eli Zaretskii
2023-06-25 0:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-24 17:00 UTC (permalink / raw
To: 64270
[-- 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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-24 17:00 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
@ 2023-06-24 17:16 ` Eli Zaretskii
2023-06-27 7:04 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-25 0:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2023-06-24 17:16 UTC (permalink / raw
To: Manuel Giraud; +Cc: 64270
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-24 17:00 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
2023-06-24 17:16 ` Eli Zaretskii
@ 2023-06-25 0:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 7:08 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-25 0:36 UTC (permalink / raw
To: Manuel Giraud; +Cc: 64270
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'.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-24 17:16 ` Eli Zaretskii
@ 2023-06-27 7:04 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 11:26 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 7:04 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-25 0:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 7:08 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 7:48 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 7:08 UTC (permalink / raw
To: Po Lu; +Cc: 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 7:08 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 7:48 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 8:25 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 8:37 ` Robert Pluim
0 siblings, 2 replies; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 7:48 UTC (permalink / raw
To: Manuel Giraud; +Cc: 64270
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...
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 7:48 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 8:25 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 8:37 ` Robert Pluim
1 sibling, 0 replies; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 8:25 UTC (permalink / raw
To: Po Lu; +Cc: 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 7:48 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 8:25 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 8:37 ` Robert Pluim
2023-06-27 8:47 ` Robert Pluim
1 sibling, 1 reply; 27+ messages in thread
From: Robert Pluim @ 2023-06-27 8:37 UTC (permalink / raw
To: Manuel Giraud; +Cc: Po Lu, 64270
>>>>> 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
--
^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 8:37 ` Robert Pluim
@ 2023-06-27 8:47 ` Robert Pluim
2023-06-27 8:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 27+ messages in thread
From: Robert Pluim @ 2023-06-27 8:47 UTC (permalink / raw
To: Manuel Giraud; +Cc: Po Lu, 64270
>>>>> 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
--
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 8:47 ` Robert Pluim
@ 2023-06-27 8:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:42 ` Robert Pluim
0 siblings, 1 reply; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 8:55 UTC (permalink / raw
To: Robert Pluim; +Cc: 64270, Manuel Giraud
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 8:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 9:42 ` Robert Pluim
2023-06-27 9:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 11:30 ` Eli Zaretskii
0 siblings, 2 replies; 27+ messages in thread
From: Robert Pluim @ 2023-06-27 9:42 UTC (permalink / raw
To: Po Lu; +Cc: 64270, Manuel Giraud
>>>>> 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
--
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 9:42 ` Robert Pluim
@ 2023-06-27 9:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:53 ` Robert Pluim
2023-06-27 9:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 11:30 ` Eli Zaretskii
1 sibling, 2 replies; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 9:49 UTC (permalink / raw
To: Robert Pluim; +Cc: 64270, Manuel Giraud
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 9:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 9:53 ` Robert Pluim
2023-06-27 12:06 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 27+ messages in thread
From: Robert Pluim @ 2023-06-27 9:53 UTC (permalink / raw
To: Po Lu; +Cc: 64270, Manuel Giraud
>>>>> 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
--
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 9:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:53 ` Robert Pluim
@ 2023-06-27 9:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 12:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 9:59 UTC (permalink / raw
To: Po Lu; +Cc: Robert Pluim, 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 7:04 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 11:26 ` Eli Zaretskii
2023-06-27 14:13 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2023-06-27 11:26 UTC (permalink / raw
To: Manuel Giraud; +Cc: 64270
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 9:42 ` Robert Pluim
2023-06-27 9:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 11:30 ` Eli Zaretskii
1 sibling, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2023-06-27 11:30 UTC (permalink / raw
To: Robert Pluim; +Cc: luangruo, 64270, manuel
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 9:53 ` Robert Pluim
@ 2023-06-27 12:06 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 12:06 UTC (permalink / raw
To: Robert Pluim; +Cc: 64270, Manuel Giraud
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 9:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 12:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 14:02 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 12:10 UTC (permalink / raw
To: Manuel Giraud; +Cc: Robert Pluim, 64270
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 12:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 14:02 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 14:02 UTC (permalink / raw
To: Po Lu; +Cc: Robert Pluim, 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 11:26 ` Eli Zaretskii
@ 2023-06-27 14:13 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 15:54 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 14:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 14:13 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 15:54 ` Eli Zaretskii
2023-06-27 16:07 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2023-06-27 15:54 UTC (permalink / raw
To: Manuel Giraud; +Cc: 64270
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 15:54 ` Eli Zaretskii
@ 2023-06-27 16:07 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 18:18 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-27 16:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 16:07 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-27 18:18 ` Eli Zaretskii
2023-06-28 0:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 7:38 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2023-06-27 18:18 UTC (permalink / raw
To: Manuel Giraud; +Cc: 64270
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 18:18 ` Eli Zaretskii
@ 2023-06-28 0:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 7:50 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 7:38 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-28 0:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 64270, Manuel Giraud
>> >> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-27 18:18 ` Eli Zaretskii
2023-06-28 0:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-28 7:38 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-28 7:38 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-28 0:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-28 7:50 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 9:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 27+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-28 7:50 UTC (permalink / raw
To: Po Lu; +Cc: Eli Zaretskii, 64270
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#64270: 30.0.50; Font update for no toolkit menu
2023-06-28 7:50 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-06-28 9:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 27+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-28 9:20 UTC (permalink / raw
To: Manuel Giraud; +Cc: Eli Zaretskii, 64270
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2023-06-28 9:20 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-24 17:00 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
2023-06-24 17:16 ` Eli Zaretskii
2023-06-27 7:04 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 11:26 ` Eli Zaretskii
2023-06-27 14:13 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 15:54 ` Eli Zaretskii
2023-06-27 16:07 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 18:18 ` Eli Zaretskii
2023-06-28 0:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 7:50 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 9:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-28 7:38 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-25 0:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 7:08 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 7:48 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 8:25 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 8:37 ` Robert Pluim
2023-06-27 8:47 ` Robert Pluim
2023-06-27 8:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:42 ` Robert Pluim
2023-06-27 9:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:53 ` Robert Pluim
2023-06-27 12:06 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 9:59 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 12:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 14:02 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-27 11:30 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.