some MULE inconsistencies [with patch]
Salam,
I'm installing fresh 21.4.0, trying to learn how it works from the
beginning (I mean I've never before compiled it myself, just used
packages from various distributions). I've always used non-mule
xemacsen with horrible hacks applied to support cyrillic input. This
time I'm trying MULE (also using xkb).
First, I've read through "Mule" chapter and found the following
obsoleted places [read below for continue]:
--- mule.texi Thu Apr 12 22:22:29 2001
+++ mule.texi-new Fri Apr 20 17:26:06 2001
＠＠ -70,7 +70,7 ＠＠
＠cindex language environments
All supported character sets are supported in XEmacs buffers if it is
-compile with mule; there is no need to select a particular language in
+compiled with mule; there is no need to select a particular language in
order to display its characters in an XEmacs buffer. However, it is
important to select a ＠dfn{language environment} in order to set various
defaults. The language environment really represents a choice of
＠＠ -89,8 +89,10 ＠＠
the XEmacs session. The supported language environments include:
＠quotation
-Chinese-BIG5, Chinese-CNS, Chinese-GB, Cyrillic-ISO, English, Ethiopic,
-Greek, Japanese, Korean, Latin-1, Latin-2, Latin-3, Latin-4, Latin-5.
+ASCII, Chinese-BIG5, Chinese-GB, Croatian, Cyrillic-ALT, Cyrillic-ISO,
+Cyrillic-KOI8, Cyrillic-Win, Czech, English, Ethiopic, French, German,
+Greek, Hebrew, IPA, Japanese, Korean, Latin-1, Latin-2, Latin-3, Latin-4,
+Latin-5, Norwegian, Polish, Romanian, Slovenian, Thai-XTIS, Vietnamese.
＠end quotation
Some operating systems let you specify the language you are using by
＠＠ -284,9 +286,9 ＠＠
Display a list of all the supported coding systems.
＠end table
-＠kindex C-h C
+＠kindex C-x ＠key{RET} C
＠findex describe-coding-system
- The command ＠kbd{C-h C} (＠code{describe-coding-system}) displays
+ The command ＠kbd{C-x RET C} (＠code{describe-coding-system}) displays
information about particular coding systems. You can specify a coding
system name as argument; alternatively, with an empty argument, it
describes the coding systems currently selected for various purposes,
Second, the paragraph of mule.texi
These variant coding systems are omitted from the
＠code{list-coding-systems} display for brevity, since they are entirely
predictable. For example, the coding system ＠code{iso-8859-1} has
variants ＠code{iso-8859-1-unix}, ＠code{iso-8859-1-dos} and
＠code{iso-8859-1-mac}.
is no longer true, as you can see from M-x list-coding-systems. I
think that it is "list-coding-systems" needs to be fixed to remove
those variants. (It would also obviously be logical if various line
endings be specified with separate orthogonal trigger, which could be
used e.g. without MULE at all).
Third, XEmacs does not honour my X resources (older XEmacs does,
surely). I have:
XEmacs.default.attributeFont: -adobe_koi8_1-courier-*-r-*-*-14-*-*-*-*-*-koi8-r
XEmacs.italic.attributeFont: -adobe_koi8_1-courier-*-o-*-*-14-*-*-*-*-*-koi8-r
(don't look at "koi8_1", it has nothing to do with encoding, just
trailing "-koi8-r" matters). XEmacs complains:
(1) (font/warning) Unable to instantiate font for face
default, charset cyrillic-iso8859-5"
If that is because I do not have fonts in "iso8859-5", then I think
that it's not so good and it'd be better to just use user-supplied
ordinary koi8-r encoded fonts. Thus, if I'm trying to write something
in Russian, I get only "~~~~~~". Nonetheless, everything else is ok,
for if I'll save the file, it contains the blindly typed words in correct
Russian encoding.
If the mapping between charsets and fonts with MULE is specified
somewhere, then please point me there -- I haven't found anything
(though looked not so carefully -- will do).
--alexm