explicit fonts in specifier code?

[Aidan Kehoe]

 Ar an deichi? l? de m? na Samhain, scr?obh Ilya N. Golubev: 

 > Your 2006-11-05 change of generic `specifier.c'
 > `specifier_instance_from_inst_list' added a very specific processing
 > of `matchspec', with retrieving charsets and other data from
 > `matchspec' just as it is done for font specifiers, one of many
 > specifier types.  It did not merely broke abstractedness of
 > `specifier.c' code.  It is very hard to predict how this change will
 > affect myriads of other uses of other specifier types, including
 > results of documented `specifier-matching-instance' calls for these
 > non- font specifiers.
 > 
 > If it will not change anything except font specifiers, then please add
 > comments explaining the following.
 > 
 > . How this is ensured. 

I think adding these comments to the source code would be overkill, but I
have no objection to explaining what you ask here.

- The differing behaviour only occurs when the charset variable is non-nil;
this check is on line 2871 of specifier.c. The charset variable can only be
non-nil if the matchspec argument is of the correct format for a font
specifier--that is, it must be a cons with the first element a character set
and the second one of the symbols 'initial or 'final. If it is not a cons
with the first element a charset or a symbol naming a charset, it remains
nil; if it is such a cons, but the second element isn?t one of the desired
symbols, an assertion is triggered on line 2850 of specifier.c.

Otherwise, the code is functionally equivalent to the previous code; it
loops through the inst_list, ignoring entries if their tag sets don?t match
the device at hand, trying to instantiate using an entry if they do match,
and returning an instantiator if such an instantiation is successful. 

No extant specifier matchspec, for any specifier type, matches the format
used. There would need to be a local development of the specifier C code
that happened to choose exactly the same format and the same two symbol
names for the changed code to see a matchspec that doesn?t belong to a font
specifier. I am as certain as I can be that this code will not change
anything except font specifiers.

 > . Why it was actually generic `specifier_instance_from_inst_list' that
 > had to be changed.  So that could not put the desired processing in
 > `font_instantiate'.  (Or one or two more additional generic specifier
 > methods.)

Previous to this change, there was no way to set the font used for a face
when using a given non-ASCII Mule charset. Now, such a customisation is
possible, and relatively painless:

(define-specifier-tag 'ipa nil (lambda (charset) (eq charset (find-charset
'ipa))))
(set-face-font 'default "-etl-fixed-medium-r-normal--24-240-72-72-c-120-muleipa-1" '(x ipa))

The way I chose to implement this used the existing specifier tag
infrastructure; the only way to change the calculation of which specifier
tags are relevant to a given instantiation and which are ignored is to
change specifier_instance_from_inst_list. 

 > Still better, please get `specifier_instance_from_inst_list' just as
 > generic as before, with all font specific data processing back in font
 > methods.

I would have preferred not to modify the general specifier code, but since
faces are implemented as specifiers, and there was previously no way for
specifiers to store charset information, I couldn?t think of an
alternative. 

 > Never checked other recent changes of specifier code for this issue.

-- 
Santa Maradona, priez pour moi!