Moving it to xemacs-beta. Concerning what is matched against charset
registry while instancing font in X.
> the entire font name, on X devices
it only matches the registry field as defined in the
XLFD standard.
I don't understand what you mean here.
No kidding. It is actual behavior [1]. If this is intolerable, then
`x_find_charset_font' itself needs patch, so that we can remove X
reservation from font instancing documentation.
Footnotes:
[1] My xemacs does call sequences like this. (Will send more gdb
backtraces on request.)
fast_string_match (regexp=1081165372,
nonreloc=0xbfffd730
"-b&h-lucidatypewriter-medium-r-normal-sans-12-120-75-75-m-70-iso8859-1",
reloc=1080332560, offset=0, length=-1, case_fold_search=1,
errb=
{really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666},
no_quit=0) at xemacs-21.5/src/search.c:533
x_font_spec_matches_charset (d=0x8582710, charset=1081689636,
nonreloc=0xbfffd730
"-b&h-lucidatypewriter-medium-r-normal-sans-12-120-75-75-m-70-iso8859-1",
reloc=Qnil, offset=0, length=-1, stage=0)
at xemacs-21.5/src/objects-x.c:965
x_find_charset_font (device=139994896, font=141607140,
charset=1081689636, stage=0)
at xemacs-21.5/src/objects-x.c:933
font_instantiate (specifier=1081807280, matchspec=148726376,
domain=141312384, instantiator=141607140, depth=3)
at xemacs-21.5/src/objects.c:863
A *generic* matching function (knowing nothing about X) is really
applied to entire font name.
Perhaps that is why `x_find_charset_font' contains comment:
/* #### This code seems awfully bogus -- mrb */