emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-diffs] Changes to emacs/README.unicode [emacs-unicode-2]


From: Kenichi Handa
Subject: [Emacs-diffs] Changes to emacs/README.unicode [emacs-unicode-2]
Date: Wed, 10 Sep 2003 19:42:38 -0400

Index: emacs/README.unicode
diff -c /dev/null emacs/README.unicode:1.1.4.1
*** /dev/null   Wed Sep 10 19:42:38 2003
--- emacs/README.unicode        Wed Sep 10 19:42:37 2003
***************
*** 0 ****
--- 1,129 ----
+                                             -*-mode: text; coding: latin-1;-*-
+ 
+ Problems, fixmes and other issues in the emacs-unicode branch
+ -------------------------------------------------------------
+ 
+ Notes by fx to record various things of variable importance.  handa
+ needs to check them -- don't take too seriously, especially with
+ regard to completeness.
+ 
+ _Do take seriously that you don't want this branch unless you're
+ actually working on it; you risk your data by actually using it._  If
+ you just want to edit Unicode and/or unify iso-8859 et al, see the
+ existing support and the extra stuff at
+ <URL:ftp://dlpx1.dl.ac.uk/fx/emacs/Mule>, mostly now in the CVS trunk.
+ (Editing support is mostly orthogonal to the internal representation.)
+ 
+  * SINGLE_BYTE_CHAR_P returns true for Latin-1 characters, which has
+    undesirable effects.  E.g.:
+    (multibyte-string-p (let ((s "x")) (aset s 0 ?£) s)) => nil
+    (multibyte-string-p (concat [?£])) => nil
+    (text-char-description ?£) => "M-#"
+ 
+       These examples are all fixed by the change of 2002-10-14, but
+       there still exist questionalble SINGLE_BYTE_CHAR_P in the
+       code.
+ 
+  * Rationalize character syntax and its relationship to the Unicode
+    database.  (Applies mainly to symbol an punctuation syntax.)
+ 
+  * Fontset handling and customization needs work.  We want to relate
+    fonts to scripts, probably based on the Unicode blocks.  The
+    presence of small-repertoire 10646-encoded fonts in XFree 4 is a
+    pain, not currently worked round.
+ 
+       With the change on 2002-07-26, multiple fonts can be
+       specified in a fontset for a specific range of characters.
+       Each range can also be specified by script.  Before using
+       ISO10646 fonts, Emacs checks their repertories to avoid such
+       fonts that don't have a glyph for a specific character.
+ 
+  * Work is also needed on charset and coding system priorities.
+ 
+  * The relevant bits of latin1-disp.el need porting (and probably
+    re-naming/updating).  See also cyril-util.el.
+ 
+  * Quail files need more work now the encoding is irrelevant.
+ 
+  * What to do with the old coding categories stuff?
+ 
+  * The preferred-coding-system property of charsets should probably be
+    junked unless it can be made more useful now.
+ 
+  * find-multibyte-characters needs looking at.
+ 
+  * Implement Korean cp949/UHC, BIG5-HKSCS and any other important missing
+    charsets.
+ 
+  * Check up on definition of alternativnj.
+ 
+  * Lazy-load tables for unify-charset somehow?
+ 
+       Actually, Emacs clear out all charset maps and unify-map just
+       before dumping, and their are loaded again on demand the
+       dumped emacs.  But, those maps (char tables) generated while
+       temacs is running can't be get rid of from the dumped emacs.
+ 
+  * Translation tables for {en,de}code currently aren't supported.
+ 
+       This should be fixed by the changes of 2002-10-14.
+ 
+  * Defining CCL coding systems currently doesn't work.
+ 
+       This should be fixed by the changes of 2003-01-30.
+ 
+  * iso-2022 charsets get unified on i/o.
+ 
+       With the change on 2003-01-06, decoding routines put `charset'
+       property to decoded text, and iso-2022 encoder pay attention
+       to it.  Thus, for instance, reading and writing by
+       iso-2022-7bit preserve the original designation sequences.
+       The property name `preferred-charset' may be better?
+ 
+       We may have to utilize this property to decide a font.
+ 
+  * Revisit locale processing: look at treating the language and
+    charset parts separately.  (Language should affect things like
+    speling and calendar, but that's not a Unicode issue.)
+ 
+  * Handle Unicode combining characters usefully, e.g. diacritics, and
+    handle more scripts specifically (à la Devanagari).  There are
+    issues with canonicalization.
+ 
+  * Bidi is a separate issue with no support currently.
+ 
+  * We need tabular input methods, e.g. for maths symbols.  (Not
+    specific to Unicode.)
+ 
+  * Need multibyte text in menus, e.g. for the above.  (Not specific to
+    Unicode.)
+ 
+  * There's currently no support for Unicode normalization.
+ 
+  * Populate char-width-table correctly for Unicode chanaracters and
+    worry about what happens when double-width charsets covering
+    non-CJK characters are unified.
+ 
+  * Emacs 20/21 .elc files are currently not loadable.  It may or may
+    not be possible to do this properly.
+ 
+       With the change on 2002-07-24, elc files generated by Emacs
+       20.3 and later are correctly loaded (including those
+       containing multibyte characters and compressed).  But, elc
+       files generated by 20.2 and the primer are still not loadable.
+       Is it really worth working on it?
+ 
+  * Rmail won't work with non-ASCII text.  Encoding issues for Babyl
+    files need sorting out, but rms says Babyl will go before this is
+    released.
+ 
+  * Gnus still needs some attention, and we need to get changes
+    accepted by Gnus maintainers...
+ 
+  * There are type errors lurking, e.g. in
+    Fcheck_coding_systems_region.  Define ENABLE_CHECKING to find them.
+ 
+  * You can grep the code for lots of fixmes.
+ 
+  * Old auto-save files, and similar files, such as Gnus drafts,
+    containing non-ASCII characters probably won't be re-read correctly.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]