Mercurial > emacs
view etc/=TO-DO @ 20892:18f3cb26243f before-miles-orphaned-changes gcc-2_8_1-980401 gcc-2_8_1-980407 gcc-2_8_1-980412 gcc-2_8_1-980413 gcc-2_8_1-RELEASE gcc_2_8_1-980315 libc-980214 libc-980215 libc-980216 libc-980217 libc-980218 libc-980219 libc-980220 libc-980221 libc-980222 libc-980223 libc-980224 libc-980225 libc-980226 libc-980227 libc-980228 libc-980301 libc-980302 libc-980303 libc-980304 libc-980306 libc-980307 libc-980308 libc-980309 libc-980310 libc-980311 libc-980312 libc-980313 libc-980314 libc-980315 libc-980316 libc-980317 libc-980318 libc-980319 libc-980320 libc-980321 libc-980322 libc-980323 libc-980324 libc-980325 libc-980326 libc-980327 libc-980328 libc-980329 libc-980330 libc-980331 libc-980401 libc-980402 libc-980403 libc-980404 libc-980405 libc-980406 libc-980407 libc-980408 libc-980409 libc-980410 libc-980411 libc-980412 libc-980413 libc-980414 libc-980428 libc-980429 libc-980430 libc-980501 libc-980502 libc-980503 libc-980504 libc-980505 libc-980506 libc-980507 libc-980508 libc-980509 libc-980510 libc-980512 libc-980513 libc-980514 libc-980515 libc-980516 libc-980517 libc-980518 libc-980519 libc-980520 libc-980521 libc-980522 libc-980523 libc-980524 libc-980525 libc-980526 libc-980527 libc-980528 libc-980529 libc-980530 libc-980531 libc-980601 libc-980602 libc-980603 libc-980604 libc-980605 libc-980606 libc-980607 libc-980608 libc-980609 libc-980610 libc-980611 libc-980612 libc-980613
Add PentiumII (i786). Add '7' to all i[3456] entries.
Add AMD and Cyrix names for P5 and P6.
author | Richard Kenner <kenner@gnu.org> |
---|---|
date | Fri, 13 Feb 1998 12:16:46 +0000 |
parents | 59c8668f70c7 |
children |
line wrap: on
line source
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.