annotate etc/=TO-DO @ 16842:72276b334084 before-thomas-posix1996 glibc-2_0_2 libc-970108 libc-970109 libc-970110 libc-970111 libc-970112 libc-970113 libc-970114 libc-970115 libc-970116 libc-970117 libc-970118 libc-970119 libc-970120 libc-970121 libc-970122 libc-970123 libc-970124 libc-970125 libc-970126 libc-970127 libc-970128 libc-970129 libc-970130 libc-970131 libc-970201 libc-970202 libc-970203 libc-970204 libc-970205 libc-970206 libc-970207 libc-970208 libc-970209 libc-970210 libc-970211 libc-970212 libc-970213 libc-970214 libc-970215 libc-970216 libc-970217 libc-970218 libc-970219 libc-970220 libc-970221 libc-970222 libc-970223 libc-970224 libc-970225 libc-970226 libc-970227 libc-970228 libc-970301 libc-970302 libc-970303 libc-970304 libc-970305 libc-970306 libc-970307 libc-970308 libc-970309 libc-970310 libc-970311 libc-970312 libc-970313 libc-970314 libc-970315 libc-970316 libc-970317 libc-970318 libc-970319 libc-970320 libc-970321 libc-970322 libc-970323 libc-970324 libc20x-970306 libc20x-97031 libc20x-970316 libc20x-970318 libc20x-970319 libc20x-970404 root-libc-2_0_x-branch

Add hppa1.1-hitachi-hiuxmpp support, passed along by rms.

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.