1 files changed, 0 insertions, 83 deletions
diff --git a/etc/TO-DO b/etc/TO-DO
deleted file mode 100644
index e5b9a49599b..00000000000
--- a/etc/TO-DO
+++ /dev/null
@@ -1,83 +0,0 @@
-Things useful to do for GNU Emacs:
-
-* Primitive for random access insertion of part of a file.
-
-* Making I/O streams for files, so that read and prin1 can
- be used on files directly.  The I/O stream itself would
- serve as a function to read or write one character.
-
-* If a file you can't write is in a directory you can write,
- make sure it works to modify and save this file.
-
-* Make dired's commands handle correctly the case where
- ls has listed several subdirectories' contents.
- It needs to be able to tell which directory each file
- is really in, by searching backward for the line
- which identifies the start of a directory.
-
-* Add more dired commands, such as sorting (use the
- sort utility through call-process-region).
-
-* Make display.c record inverse-video-ness on
- a character by character basis.  Then make non-full-screen-width
- mode lines inverse video, and display the marked location in
- inverse video.
-
-* VMS code to list a file directory.  Make dired work.
-
-Long range:
-
-   Ideas for extending GNU Emacs to deal with arbitrary character sets.
-
-I would like GNU Emacs to be extended to handle all the world's alphabets
-and word signs.  I don't expect to have time to do such a thing in the next
-few years, so here are my ideas on the best way to do it.
-
-* Each graphic is represented by a sequence of ordinary 8-bit characters.
-
-* All the characters that make up such a sequence have codes >= 0200.
-
-* The first character of such a sequence is between 0200 and 0237.
-
-* The remaining characters of such a sequence are all 0240 or higher.
-
-* The first character of the sequence determines the number of characters
-in the sequence.  Thus, 0200...0207 could start two-character sequences,
-0210...0227 could start three-character sequences, and 0230 could start
-four-character sequences.  (Codes 0231...0237 would be reserved.)
-
-*  Several common  alphabets,  and  some mathematical   symbols,  would get
-two-character sequences.  (Probably Greek,  Russian,  Hebrew(?), Arabic(?),
-Korean, and Japanese kana).  The remaining alphabets, and  some versions of
-Chinese,  would   get  three-character sequences.    Other  sets of Chinese
-characters would get four-character sequences.
-
-Each country that uses Chinese characters has its own standard character
-set, and it is not easy to correlate them to avoid overlap.  So there may
-need to be several sets of Chinese characters.  That is why they need so
-much code space.
-
-True support for Hebrew and Arabic requires dealing with the problem of
-writing direction for mixed text; I don't know what to do for that.
-
-* The functions that use syntax table would determine the
-syntax of a sequence from its first character.
-
-* Functions in indent.c for computing widths and columns would
-determine the width of a sequence from its first character.
-So would display routines.
-
-* Only a few other editing routines would need any change.  In
-particular, searching and regexp matching might not need any change.
-
-* Most of the work required would be in redisplay.  The only case that
-needs to be supported is with X windows, since ordinary terminals
-can't display all these characters anyway.
-
-* There might need to be code to translate files from this format
-to whatever format is typically stored on disk.
-
-
-I would be very unhappy with half-measures, such as support for
-Japanese only.
-