>>>> "njsf" == Nelson Ferreira
<nelson.ferreira(a)ieee.org> writes:
njsf> Articles encoded in iso-8859-15 are filled with "~" on all
njsf> non-ascii characters in a tty, whereas in the X window they
njsf> look fine (they do use a diferent smaller font but that is
njsf> fine... ).
njsf> (if (fboundp 'prefer-coding-system)
njsf> (prefer-coding-system 'iso-8859-1))
This is related. If you use 'iso-8859-15 instead, Latin 1 will be
broken and Latin 9 will appear.
njsf> Am I missing some configuration step/doing anything wrong ?
No. This is a fundamental design choice in Mule, which treats the
members of the ISO 8859 family as separate coded character sets rather
than as different mappings from codes into the same character set.
The designer of Mule is Japanese, and for characters shared with
Chinese, Taiwanese, Korean, and Vietnamese it is arguably necessary to
do this. So as far as it knows, 0xA1 in ISO 8859/1 is as different
from 0xA1 in ISO 8859/15 as it is from 0xA1 in JIS X 0201. :-(
We can work around it, but it's not pretty.
For now you'll have to "wash" the display by hand with
M-x set-terminal-coding-system RET iso-8859-15 RET
(`set-terminal-coding-system' is aka C-x C-m t) and then back to
iso-8859-1 for iso-8859-1 buffers. This command should not affect
your X frames, only TTYs.
FYI, latin-unity is not currently supported on XEmacs 21.5, although
YMMV. I plan to incorporate it in core, and extend it (in particular,
it does nothing useful for your problem yet).
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.