Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Dave Love <d.love@xxxxxxxx>]

Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx> writes:

> 	* Merge patches from xemacs-mule-sumo-2002-05-22.
> 	* utf.el (utf-8-ccl-decode): Don't read any numbers lager than 24bit.
> 	* reldata/uethiopic.el: Typo fix for (provide 'uethiopic).
> 	  (from Debian xemacs21-mulesupport_2002.05.22-3)
> 
> I'm thinking about updating Debian mule-ucs with this patch.
> (I'm current Debian mule-ucs maintainer since October 25, 2002.)

I haven't studied the patch carefully, but I would make two comments.

Instead of using a constant replacement character for data which can't
be decoded, it would be much better to use the same technique as Emacs
21, and maintain the byte sequence of the input data using eight-bit
charsets.  As it is, Mule-UCS can corrupt correct utf-8 data.  (I
realize this is a fair amount of work.)

Please be careful when including changes that aren't covered by an FSF
copyright assignment, and about recording who contributed the changes.
If someone wants to take code (or, more likely, the data tables) for
use in Emacs, it is a significant problem if it's not clear where they
came from.  For instance, Debian changelogs normally don't record
proper information about the contributions to allow someone to find
out who contributed the change and exactly what it was, and I have had
trouble trying to use Debian changes to Mule-UCS because of that.  [It
was claimed that one of my Mule-UCS changes didn't work, but the same
code in Debian without my name on it did work, so I suppose there
actually may be benefits to doing it that way. :-/]