1Things 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 28Long range: 29 30 Ideas for extending GNU Emacs to deal with arbitrary character sets. 31 32I would like GNU Emacs to be extended to handle all the world's alphabets 33and word signs. I don't expect to have time to do such a thing in the next 34few 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 45in the sequence. Thus, 0200...0207 could start two-character sequences, 460210...0227 could start three-character sequences, and 0230 could start 47four-character sequences. (Codes 0231...0237 would be reserved.) 48 49* Several common alphabets, and some mathematical symbols, would get 50two-character sequences. (Probably Greek, Russian, Hebrew(?), Arabic(?), 51Korean, and Japanese kana). The remaining alphabets, and some versions of 52Chinese, would get three-character sequences. Other sets of Chinese 53characters would get four-character sequences. 54 55Each country that uses Chinese characters has its own standard character 56set, and it is not easy to correlate them to avoid overlap. So there may 57need to be several sets of Chinese characters. That is why they need so 58much code space. 59 60True support for Hebrew and Arabic requires dealing with the problem of 61writing direction for mixed text; I don't know what to do for that. 62 63* The functions that use syntax table would determine the 64syntax of a sequence from its first character. 65 66* Functions in indent.c for computing widths and columns would 67determine the width of a sequence from its first character. 68So would display routines. 69 70* Only a few other editing routines would need any change. In 71particular, searching and regexp matching might not need any change. 72 73* Most of the work required would be in redisplay. The only case that 74needs to be supported is with X windows, since ordinary terminals 75can't display all these characters anyway. 76 77* There might need to be code to translate files from this format 78to whatever format is typically stored on disk. 79 80 81I would be very unhappy with half-measures, such as support for 82Japanese only. 83 84