comparison etc/PROBLEMS @ 105001:f665043359a7

Remove obsolete Mule-UCS information (the package is not redundant).

105000:c4fa6fe77406

correctly as UTF-8, assuming you don't break the composed sequences.
If you read such characters from UTF-16 or UTF-7 data, they are
substituted with the Unicode `replacement character', and you lose
information.

** Mule-UCS loads very slowly.

Changes to Emacs internals interact badly with Mule-UCS's `un-define'
library, which is the usual interface to Mule-UCS.  Apply the
following patch to Mule-UCS 0.84 and rebuild it.  That will help,
though loading will still be slower than in Emacs 20.  (Some
distributions, such as Debian, may already have applied such a patch.)

--- lisp/un-define.el	6 Mar 2001 22:41:38 -0000	1.30
+++ lisp/un-define.el	19 Apr 2002 18:34:26 -0000
@@ -610,13 +624,21 @@ by calling post-read-conversion and pre-

  (mapcar
   (lambda (x)
-    (mapcar
-     (lambda (y)
-       (mucs-define-coding-system
-	(nth 0 y) (nth 1 y) (nth 2 y)
-	(nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
-       (coding-system-put (car y) 'alias-coding-systems (list (car x))))
-     (cdr x)))
+    (if (fboundp 'register-char-codings)
+	;; Mule 5, where we don't need the eol-type specified and
+	;; register-char-codings may be very slow for these coding
+	;; system definitions.
+	(let ((y (cadr x)))
+         (mucs-define-coding-system
+          (car x) (nth 1 y) (nth 2 y)
+          (nth 3 y) (nth 4 y) (nth 5 y)))
+      (mapcar
+       (lambda (y)
+        (mucs-define-coding-system
+         (nth 0 y) (nth 1 y) (nth 2 y)
+         (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
+        (coding-system-put (car y) 'alias-coding-systems (list (car x)))))
+      (cdr x)))
   `((utf-8
      (utf-8-unix
       ?u "UTF-8 coding system"

Note that Emacs has native support for Unicode, roughly equivalent to
Mule-UCS's, so you may not need it.

** Mule-UCS compilation problem.

Emacs of old versions and XEmacs byte-compile the form `(progn progn
...)' the same way as `(progn ...)', but Emacs of version 21.3 and the
later process that form just as interpreter does, that is, as `progn'
variable reference.  Apply the following patch to Mule-UCS 0.84 to
make it compiled by the latest Emacs.

--- mucs-ccl.el	2 Sep 2005 00:42:23 -0000	1.1.1.1
+++ mucs-ccl.el	2 Sep 2005 01:31:51 -0000	1.3
@@ -639,10 +639,14 @@
       (mucs-notify-embedment 'mucs-ccl-required name)
       (setq ccl-pgm-list (cdr ccl-pgm-list)))
 ;   (message "MCCLREGFIN:%S" result)
-    `(progn
-       (setq mucs-ccl-facility-alist
-            (quote ,mucs-ccl-facility-alist))
-       ,@result)))
+    ;; The only way the function is used in this package is included
+    ;; in `mucs-package-definition-end-hook' value, where it must
+    ;; return (possibly empty) *list* of forms.  Do this.  Do not rely
+    ;; on byte compiler to remove extra `progn's in `(progn ...)'
+    ;; form.
+    `((setq mucs-ccl-facility-alist
+           (quote ,mucs-ccl-facility-alist))
+      ,@result)))

 ;;; Add hook for embedding translation informations to a package.
 (add-hook 'mucs-package-definition-end-hook

** Accented ISO-8859-1 characters are displayed as | or _.

Try other font set sizes (S-mouse-1).  If the problem persists with
other sizes as well, your text is corrupted, probably through software
that is not 8-bit clean.  If the problem goes away with another font

105001:f665043359a7

correctly as UTF-8, assuming you don't break the composed sequences.
If you read such characters from UTF-16 or UTF-7 data, they are
substituted with the Unicode `replacement character', and you lose
information.

** Accented ISO-8859-1 characters are displayed as | or _.

Try other font set sizes (S-mouse-1).  If the problem persists with
other sizes as well, your text is corrupted, probably through software
that is not 8-bit clean.  If the problem goes away with another font