empty charset registry?

Ilya N. Golubev gin
Tue Nov 7 14:28:42 EST 2006


Your 2006-11-05 change of how font is searched for given mule charset
when instancing font specifiers is clearly user visible.  Still there
is no documentation changes reflecting that, let alone addition to
`NEWS'.  One of incompatibilities is that currently the call:

(set-charset-registry 'ascii "")

signals error:

(invalid-argument "Not an X11 REGISTRY-ENCODING combination" "")


Before the change doing this particular elisp call had an obvious and
a very useful effect.  That is, user could easily view raw text
without explicit mule decoding.  This is extremely valueable when
viewing data items consisting of snippets of text in different 8-bit
encodings.  Those easily result from erroneous process output, or
simply are some legacy text files.  This was possible because could
obviously specify xemacs to display raw text charsets in the very
first font retrieved from font specifier for particular locale, like
this.

(let ((l '(ascii latin-iso8859-1)))
  (while l
    (set-charset-registry (car l) "")
    (setq l (cdr l))))

Then would just set font specifications in default (or even perhaps
other) face font specifiers for frame (or window), and could rely
xemacs to display raw text in exactly the font as specified.

Another incompatibility is that `control-1' characters are always
displayed as `\OCTAL', not as code points of some 8-bit font.  The
latter may be disired for the same reasons.

How do we view raw text in user specified font after the change?  How
do we check whether `set-charset-registry' in given version and build
implements old or new data format?  Please document.



More information about the XEmacs-Beta mailing list