ignores frame font specification [Re: [COMMIT] Provide a FORCE argument in set-charset-registries]

[Aidan Kehoe]

 Ar an t-ochtú lá déag de mí na Nollaig, scríobh Ilya N. Golubev: 

 > > This commit allows the behaviour you describe;
 > 
 > It did not, in 21.5 as of 2006-12-13 21:07:12 +0000.  When instancing
 > font specifiers (and in redisplay), it ignores non- iso 8859-1 font
 > specifications for frame locale as follows.
 > 
 > [...]
 >
 > It appears that
 > 
 > ((x) . "*-*-*-medium-r-*-*-14-*-*-*-m-*-koi8-r")
 > 
 > specification for
 > 
 > #<x-frame "koi" 0x19eb5b>
 > 
 > is ignored, even with `(charset-registries 'ascii)' as above.
 > 
 > Please fix.

I don’t regard the current behaviour as a problem, and I’ve no intention of
changing what it does. I may better _document_ what it does, if you find it
currently very unclear.

The FORCE argument to set-face-font is only relevant when you’re dealing
with X fonts that don’t follow the XLFD convention. We discussed this at
some length. If, as you are, you’re dealing with fonts that do follow the
XLFD convention, then you can specify an actual REGISTRY-ENCODING
combination for the charset in question, and you should call:

  (set-charset-registries
   'ascii 
   (apply 'vector "koi8-r" (append (charset-registries 'ascii) nil)))
    
instead of using the FORCE argument. 

The specification wasn’t ignored. Previously, the code was very dumb with
regard to the registry and encoding passed to XListFonts. If in 21.4 you
evaluate the following:

(progn
  (set-charset-registry 'cyrillic-iso8859-5 "koi8-r")
  (set-charset-ccl-program 'cyrillic-iso8859-5 ccl-encode-koi8-r-font))

without any XEmacs-relevant X resources set it will run XListFonts on all of
the following patterns:

 "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*"
 "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*"
 "-*-courier-*-r-*-*-*-120-*-*-*-*-iso8859-*"
 "-*-*-medium-r-*-*-*-120-*-*-m-*-iso8859-*"
 "-*-*-medium-r-*-*-*-120-*-*-c-*-iso8859-*"
 "-*-*-*-r-*-*-*-120-*-*-m-*-iso8859-*"
 "-*-*-*-r-*-*-*-120-*-*-c-*-iso8859-*"
 "-*-*-*-r-*-*-*-120-*-*-*-*-iso8859-*"

And check every single one of each of the results against the regexp
"koi8-r". Despite that, were the regexp "koi8-r" to match, it would be for
the wrong reasons (the weight would have to be "koi8"), so all that checking
is a waste of time.

The new code looks at a given font pattern and uses the charset-registries
vector to pass a manipulated pattern to XListFonts. This means a pattern
ending in koi8-r will only be used for a given charset if XEmacs is aware
such a pattern can be approprate for that charset.

You can make XEmacs aware that such a pattern can be appropriate for that
charset using the set-charset-registries call above. Be aware that the order
of the charset-registries matters; 

  (set-charset-registries 'ascii ["koi8-r" "iso8859-1"])

with your pattern gives me a different font on the frame in question than:

  (set-charset-registries 'ascii ["iso8859-1" "koi8-r"])

Working with your X resources,  and 21.4 with Mule, I don’t get any sensible
results--that is, the koi8-r font is never used for cyrillic-iso8859-5 or
latin-iso8859-1. Are there parts of your configuration that you’re omitting?

 > Did anybody ever test the new font instancing routines for mere
 > implementing the documented specifier instancing rules?

The new font instancing routines implement the documented specifier
instancing rules. They do not implement all the detail of the behaviour of
the previous specifier instancing rules, because those rules were not any
more powerful than the current ones, but were significantly slower and less
intuitive to humans. (E.g. if a face used an explicitly specified X11 font
for ISO 8859 1, it did not necessarily prefer the ISO 8859 2 variant of the
same font to display ISO 8859 2.)

 > Never checked the results of changing `charset-registries' for other
 > raw text charsets, `control-1', `latin-iso8859-1', in a similar way.
 > This is perhaps even more desirable than for `ascii' charset.

Sure. But the old code didn’t do it--that is, it didn’t allow non-XLFD fonts
to be specified for control-1 and latin-iso8859-1--and I think it’s a waste
of time to implement such a thing. I implemented it for ASCII for two
reasons, despite also thinking it a waste of time; because the old code did
it, so this made migration easier, and because you evidently felt strongly
about it.

 > A related issue is that there is no obvious way to write `~/.emacs' so
 > that it does the necessary operations on charset registries, and do
 > not signal errors, both in latest 21.5 and in xemacs versions before
 > `set-charset-registry' specification change, including 21.4 and older
 > 21.5.  One has to detect in some obscure way, should the
 > initialization code call `set-charset-registry' in an old way or
 > `set-charset-registries' in a new way. 

(if (fboundp 'set-charset-registries)
    (progn
      ;; Do the manipulation specific to the new model here
      )
  ;; else do the manipulation specific to the new model. 
  (set-charset-registry ....) )

As Lisp code goes, that’s pretty clear and intuitive. Don’t ever load
cl-macs.el if you would find that obscure :-) . 

 > It is at least necessary to document the rules of such a detection.  Even
 > better, have `(set-charset-registry CHARSET "")' for raw text charsets,
 > `ascii', `control-1', `latin-iso8859-1', do the `set-charset-registries'
 > call with FORCE arg `t' as described.

Fuck no! The argument is no longer a regular expression, and it only matches
at the end. I want people to be very uncomfortable using
set-charset-registry with the new font instancing rules; that’s what the
warning’s there for. 

-- 
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.