| 1 | Things useful to do for GNU Emacs: |
| 2 | |
| 3 | * Primitive for random access insertion of part of a file. |
| 4 | |
| 5 | * Making I/O streams for files, so that read and prin1 can |
| 6 | be used on files directly. The I/O stream itself would |
| 7 | serve as a function to read or write one character. |
| 8 | |
| 9 | * If a file you can't write is in a directory you can write, |
| 10 | make sure it works to modify and save this file. |
| 11 | |
| 12 | * Make dired's commands handle correctly the case where |
| 13 | ls has listed several subdirectories' contents. |
| 14 | It needs to be able to tell which directory each file |
| 15 | is really in, by searching backward for the line |
| 16 | which identifies the start of a directory. |
| 17 | |
| 18 | * Add more dired commands, such as sorting (use the |
| 19 | sort utility through call-process-region). |
| 20 | |
| 21 | * Make display.c record inverse-video-ness on |
| 22 | a character by character basis. Then make non-full-screen-width |
| 23 | mode lines inverse video, and display the marked location in |
| 24 | inverse video. |
| 25 | |
| 26 | * VMS code to list a file directory. Make dired work. |
| 27 | |
| 28 | Long range: |
| 29 | |
| 30 | Ideas for extending GNU Emacs to deal with arbitrary character sets. |
| 31 | |
| 32 | I would like GNU Emacs to be extended to handle all the world's alphabets |
| 33 | and word signs. I don't expect to have time to do such a thing in the next |
| 34 | few years, so here are my ideas on the best way to do it. |
| 35 | |
| 36 | * Each graphic is represented by a sequence of ordinary 8-bit characters. |
| 37 | |
| 38 | * All the characters that make up such a sequence have codes >= 0200. |
| 39 | |
| 40 | * The first character of such a sequence is between 0200 and 0237. |
| 41 | |
| 42 | * The remaining characters of such a sequence are all 0240 or higher. |
| 43 | |
| 44 | * The first character of the sequence determines the number of characters |
| 45 | in the sequence. Thus, 0200...0207 could start two-character sequences, |
| 46 | 0210...0227 could start three-character sequences, and 0230 could start |
| 47 | four-character sequences. (Codes 0231...0237 would be reserved.) |
| 48 | |
| 49 | * Several common alphabets, and some mathematical symbols, would get |
| 50 | two-character sequences. (Probably Greek, Russian, Hebrew(?), Arabic(?), |
| 51 | Korean, and Japanese kana). The remaining alphabets, and some versions of |
| 52 | Chinese, would get three-character sequences. Other sets of Chinese |
| 53 | characters would get four-character sequences. |
| 54 | |
| 55 | Each country that uses Chinese characters has its own standard character |
| 56 | set, and it is not easy to correlate them to avoid overlap. So there may |
| 57 | need to be several sets of Chinese characters. That is why they need so |
| 58 | much code space. |
| 59 | |
| 60 | True support for Hebrew and Arabic requires dealing with the problem of |
| 61 | writing direction for mixed text; I don't know what to do for that. |
| 62 | |
| 63 | * The functions that use syntax table would determine the |
| 64 | syntax of a sequence from its first character. |
| 65 | |
| 66 | * Functions in indent.c for computing widths and columns would |
| 67 | determine the width of a sequence from its first character. |
| 68 | So would display routines. |
| 69 | |
| 70 | * Only a few other editing routines would need any change. In |
| 71 | particular, searching and regexp matching might not need any change. |
| 72 | |
| 73 | * Most of the work required would be in redisplay. The only case that |
| 74 | needs to be supported is with X windows, since ordinary terminals |
| 75 | can't display all these characters anyway. |
| 76 | |
| 77 | * There might need to be code to translate files from this format |
| 78 | to whatever format is typically stored on disk. |
| 79 | |
| 80 | |
| 81 | I would be very unhappy with half-measures, such as support for |
| 82 | Japanese only. |
| 83 | |