[COMMIT] Mule-CCL couldn't handle control-1 characters either.

NOTE: This patch has been committed. APPROVE COMMIT RECOMMEND 21.4, SXEmacs I was aware CCL was doing something like this for a long time; I just told myself that the code was part of XEmacs, it must be me who was getting stuff wrong. There’s an EBCDIC coding system, for example, at http://parhasard.net/ebcdic-na.el that works after this change has been applied. Also, writing a Windows-1252 coding system now becomes possible. src/ChangeLog addition: 2005-04-05 Aidan Kehoe <kehoea(a)parhasard.net&gt; * mule-ccl.c (ccl_driver): Calculate the charset and position code for control-1 characters properly, both when reading multibyte characters and writing them. XEmacs Trunk source patch: Diff command: cvs -q diff -u Files affected: src/mule-ccl.c Index: src/mule-ccl.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mule-ccl.c,v retrieving revision 1.25 diff -u -u -r1.25 mule-ccl.c --- src/mule-ccl.c 2004/09/20 19:19:52 1.25 +++ src/mule-ccl.c 2005/04/05 17:34:57 ＠＠ -1302,6 +1302,13 ＠＠ reg[RRR] = i; reg[rrr] = (*src++ & 0x7F); } + else if (LEADING_BYTE_CONTROL_1 == i) + { + if (src >= src_end) + goto ccl_read_multibyte_character_suspend; + reg[RRR] = i; + reg[rrr] = (*src++ - 0xA0); + } else if (i <= MAX_LEADING_BYTE_OFFICIAL_2) { if ((src + 1) >= src_end) ＠＠ -1349,7 +1356,7 ＠＠ case CCL_WriteMultibyteChar2: i = reg[RRR]; /* charset */ - if (i == LEADING_BYTE_ASCII) + if (i == LEADING_BYTE_ASCII || i == LEADING_BYTE_CONTROL_1) i = reg[rrr] & 0xFF; else if (XCHARSET_DIMENSION (charset_by_leading_byte (i)) == 1) i = (((i - FIELD2_TO_OFFICIAL_LEADING_BYTE) << 7) -- “I, for instance, am gung-ho about open source because my family is being held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle, when we say something in public? No-one!” -- Danny O’Brien