empty charset registry?

[stephen at xemacs.org]

Ilya N. Golubev writes:

 > `NEWS'.  One of incompatibilities is that currently the call:
 > 
 > (set-charset-registry 'ascii "")

That's pretty unreliable in principle.  If your usage is always
unibyte and very consistent (which it probably is), you'll rarely have
trouble, of course.  But for example, if you have Japanese in the
buffer, you'll need a multibyte font, I think; almost surely this is
very broken for multibyte fonts.  (And if your Chinese font precedes
the desired unibyte font, you'll get rather bizarre results, I should
think.)

Doesn't (set-charset-registry 'ascii "iso8859-1") do what you want,
more reliably?

 > 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.

Doesn't (set-charset-registry 'control-1 "koi8-r") do what you want?

 > How do we view raw text in user specified font after the change?

I don't know what "raw text" is.  All text in buffers, including
'binary buffers, is Mule-encoded in Mule XEmacsen.

The latin-unity package provides *some* help in this, by detecting the
charset information placed in the buffer by Mule, and allowing two
kinds of translation, a remapping (the identity of the character is
correct, but to reduce the number of charsets in the buffer, the same
character in a different charset is substituted) and a recoding (the
identity of the character is incorrect, but the correct character has
the same code point in a different character set).  At a minimum
you'll find that it doesn't handle Cyrillic characters or Control-1
characters automatically, and perhaps not even manually---it will need
work for your purposes as I guess them.

 > How do we check whether `set-charset-registry' in given version and
 > build implements old or new data format?  Please document.

Doesn't (fboundp 'charset-registries) do what you want?