view etc/=TO-DO @ 19860:c17fd465ea95 libc-970911 libc-970912 libc-970913 libc-970914 libc-970915 libc-970916 libc-970917 libc-970918 libc-970919 libc-970920 libc-970921 libc-970922 libc-970923 libc-970924 libc-970925 libc-970926 libc-970927 libc-970928 libc-970929 libc-970930 libc-971001 libc-971018 libc-971019 libc-971020 libc-971021 libc-971022 libc-971023 libc-971024 libc-971025 libc-971026 libc-971027 libc-971028 libc-971029 libc-971030 libc-971031 libc-971101 libc-971102 libc-971103 libc-971104 libc-971105 libc-971106 libc-971107 libc-971108 libc-971109 libc-971110 libc-971111 libc-971112 libc-971113 libc-971114 libc-971115 libc-971116 libc-971117 libc-971118 libc-971120 libc-971121 libc-971122 libc-971123 libc-971124 libc-971125 libc-971126 libc-971127 libc-971128 libc-971129 libc-971130 libc-971201 libc-971203 libc-971204 libc-971205 libc-971206 libc-971207 libc-971208 libc-971209 libc-971210 libc-971211 libc-971212 libc-971213 libc-971214 libc-971217 libc-971218 libc-971219 libc-971220 libc-971221 libc-971222 libc-971223 libc-971224 libc-971225 libc-971226 libc-971227 libc-971228 libc-971229 libc-971230 libc-971231 libc-980103 libc-980104 libc-980105 libc-980106 libc-980107 libc-980108 libc-980109 libc-980110 libc-980111 libc-980112 libc-980114 libc-980115 libc-980116 libc-980117 libc-980118 libc-980119 libc-980120 libc-980121 libc-980122 libc-980123 libc-980124 libc-980125 libc-980126 libc-980127 libc-980128

typos.
author Jeff Law <law@redhat.com>
date Wed, 10 Sep 1997 21:16:20 +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.