home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / SIMTEL / EMACS / BIN / POSTING.0 < prev    next >
Text File  |  2000-06-30  |  13KB  |  318 lines
  1.  
  2. This is the first posting of the Z80 microemacs source.
  3.  
  4. 1. HISTORY
  5.  
  6. I started with microemacs 3.6, which said
  7. " * This program is in public domain; written by Dave G. Conroy."
  8.  
  9. All the files being edited in the buffers are kept in
  10. memory; it was fairly easy to compile the version of
  11. microemacs I used, and produce a runnable program, but the
  12. first version had no space at all for files!
  13. (March 1989).
  14.  
  15. Porting to cp/m was easy because I used AZTEC C ( version
  16. 1.05c, from 1982 ). I really would have preferred BDS/C
  17. because compilation is so fast, but: no static initializers,
  18. no typedefs, no "long"... I'm not sure if BDS has overlays.
  19.  
  20.     If BDS has overlays, it would be worth while porting my
  21.     version to BDS. If it doesn't, an overlay system could
  22.     be added.
  23.  
  24. I started making overlays and optimizing, and soon
  25. ( June 1989 )
  26. could edit about 24KB of one file ( 58KB TPA ).
  27.  
  28. As soon as I could edit 3K, I started using the editor to
  29. maintain itself; editors are always well-tested if you use
  30. them to maintain themselves.
  31.  
  32.         This is why the original files were split up into very
  33.         small pieces, and some comments removed.
  34.         The comments removed include the microemacs authors'
  35.         names, but microemacs is freely available with
  36.         attribution. No attempt to hide the origin is intended.
  37.  
  38.         I think the version of microemacs I used was 3.6,
  39.         but I can't be sure.
  40.  
  41. Then I stopped and created a program for customization of
  42. the binaries, figuring to distribute the z80me program in
  43. that fashion.
  44.  
  45. There is one customization program that patches
  46. terminal-control sequences into the binary, and another that
  47. patches keystroke-to-command bindings.
  48.  
  49. I could find no CP/M BBS to post it to, and gave up.
  50. ( July 1989 ).
  51.  
  52. Documentation was never written, especially for the
  53. customization, and now I have to work from memory.
  54.  
  55.     In fact, I find no program to patch terminal-control;
  56.     the term-control module was written to make this
  57.     possible, though.
  58.  
  59. In August or September, 1991, I saw a message in comp.os.cpm
  60. asking about editors. I posted a notice about microemacs for
  61. cp/m and got many helpful and encouraging replies.
  62.  
  63. ----------------------------
  64.  
  65. 2.      PHILOSOPHY AND FEATURES
  66.  
  67. This program also embodies some of my thoughts about the
  68. nature of editors. Programmers use the editor more than any
  69. tool, and think about it less than any other. Even with a simple
  70. editor like vi, most programmers don't bother to learn every
  71. command...
  72.  
  73. The version of microemacs that I started with was an awful
  74. editor, and I hated it. Some things had to change if I was
  75. to use it, so I changed them.
  76.  
  77. If an editor's bindings are perfect from the standpoint of
  78. having neat little mnemonics ( ^N for "next line" ), they
  79. may are unlikely to be perfect from the standpoint of making
  80. frequently-used commands easy to type. A prime example is
  81. the emacs binding of Meta-f for "word forwards"; this is a
  82. frequently-used command, and should be ONE KEYSTROKE!
  83.  
  84.         The default Z80EMACS word forward is ^F, word back is
  85.         ^B, del word forward is ^W.
  86.  
  87. If an editor's bindings are perfect from both of the above
  88. standpoints, they still will run into trouble with the
  89. keyboard: yes, the dreaded ARROW KEYS.
  90.  
  91.         If you're alert, and leaning forward over the keyboard,
  92.         you may not want to use the arrow keys; such is the
  93.         argument in favor of vi's "hjkl".
  94.  
  95.         If you're thinking instead of typing, browsing instead
  96.         of hacking, you want the arrow keys to work.
  97.  
  98.                 Z80EMACS has predefined arrow keys that fit most
  99.                 ASCII terminals, ^H^J^K^L, and ^V the same as ^J.
  100.  
  101. If a command is hard to type, so what? If you use it twice
  102. in a row, simply use the "REPEAT LAST COMMAND" key!
  103. It appears that I never put this feature into Z80EMACS.
  104.  
  105. vi has two different kinds of word commands, "W" and "w"
  106. ( it also provides forward, backward, and forward-to-end
  107. directions for them ).
  108. Z80EMACS has word-forward and word-backward commands, just
  109. two commands, but there is another command that changes the
  110. way these two work -- you can use vi-style or emacs-style
  111. words, and stop at end-of-word or at beginning-of-word.
  112.  
  113. Z80EMACS doesn't implement the vi ^^ ( control-carat )
  114. command, that you use to toggle between buffers, but it does
  115. have the vi :n command, that you use to sequentially walk
  116. the linked list of buffers. It is inexcusable for any editor
  117. to be without at least one of these two commands.
  118. Both commands SHOULD exist.
  119.  
  120. Z80EMACS can display more than one buffer on the screen at
  121. the same time; this capability was part of the original
  122. microemacs. With more than one buffer on the screen,
  123. however, you must remember to type very slowly!
  124.  
  125. Z80EMACS stores its keyboard macro in a file; it uses the
  126. same mechanism as the "execute-file" command, which
  127. microemacs didn't have.
  128. Keyboard macro execution is slow, but it's better than
  129. retyping commands.
  130. Storing the keyboard macro in a file means that you can use
  131. it again after you exit and restart the editor.
  132.  
  133.     It looks like Z80EMACS still doesn't have "execute
  134.     file"; however, internally, "execfile" would use the same
  135.     mechanisms that you use to execute the keyboard macro
  136.     from a file, and so "exec file" can be added with
  137.     relative ease.
  138.  
  139. Z80EMACS makes ".BAK" files when it saves or writes.
  140.  
  141. Z80EMACS has the "vikill" command; kills whole lines, no
  142. matter where the cursor is in the line. I despise the emacs
  143. ^K command, except when used as "kill-to-end" ( the
  144. emacs-style kill is still there ).
  145.  
  146. Z80EMACS has funny vertical arrows. Up-arrow moves two
  147. lines. Both up-arrow and down-arrow can wrap from the last
  148. line of the buffer to the first line. These are both bugs
  149. that would have been easy to fix; both are interesting
  150. features.
  151.  
  152.         I put the funny up-arrow in my unix version of emacs,
  153.         and used it for at least a year before deciding I
  154.         didn't like it after all ( it was that close to being a
  155.         wash! ). The idea is, if you don't specify a parameter,
  156.         up-arrow moves by two lines; if you do specify, it moves
  157.         the correct number. If you want to move up 1, 2, 3, 4,
  158.         5, or 6 lines, it takes 2, 1, 3, 2, 4, or 3 keystrokes
  159.         instead of 1, 2, 3, 4, 5, or 6 keystrokes; an average
  160.         savings of one keystroke per line. However, moving up 1
  161.         line is the most common case, and the extra mental
  162.         effort involved in overshooting and moving down one is
  163.         distracting. ( As I type this, I have funny-up-arrow in
  164.         effect on UNIX; you really do get used to it. )
  165.  
  166. Z80EMACS has two different command introducers; one for
  167. positive values ( ^U, "universal parameter" ), one for
  168. negative ( ^\ ). Many commands have special meanings with
  169. negative parameters.
  170.  
  171.     According to my editor theories, it's easier to learn
  172.     and remember some of the odd commands if they're
  173.     shoehorned onto normal commands with special parameters.
  174.  
  175.     For example, take the "go-to-start-of-line" command,
  176.     with the normal emacs binding of ^A; if you just enter
  177.     ^A with no parameters, you go to column 0; with the
  178.     "shoehorn" theory in effect, if you specify a positive
  179.     parameter, you go to column N, and if you specify a
  180.     negative parameter, you go to the first non-white-space
  181.     character in the line. I feel this is better than having
  182.     three separate commands ( vi "0", "|", and "_",
  183.     respectively.
  184.  
  185. Metadigits start arguments.
  186. They start arguments between those who like their emacs to
  187. accept escape-9 as a command, and those who like it to
  188. supply an argument of 9 to the next command.
  189. I am in the latter camp, so in Z80EMACS,
  190. Metadigits start arguments.
  191.  
  192. Z80EMACS has the vi "find-character-in-line" command.
  193.  
  194. Z80EMACS has the "goto line by line number" command.
  195. (but doesn't display line numbers, so it's not as useful a
  196. command as it should be).
  197.  
  198. Z80EMACS allows you to change the buffer name as well as the
  199. file name.
  200.  
  201. Z80EMACS has the vi "go to column number" command: "go to
  202. start of line" with a positive parameter goes to a specific
  203. column in the line. ( with a negative parameter, it goes to
  204. end-of-line. )
  205.  
  206. -----------------------------------------------
  207.  
  208. Alas, no regular expressions, no search-replace.
  209.  
  210. -----------------------------------------------
  211.  
  212. 3.      OPTIMIZATION TO SAVE SPACE
  213.  
  214. In order to have more room for editing files, the program
  215. had to be made smaller. A large part of this was done by
  216. moving things to overlays, but some of it was pure
  217. byte-squeezing.
  218.  
  219. Most of the optimization was done in the root segment, but
  220. several overlays were optimized to make the overlay area
  221. smaller.
  222.  
  223. The key to good performance with overlays is to have all the
  224. most-often-used commands in one overlay: this is ovudfb31.c
  225. ( overlay up down forward back, overlay 31 )
  226.  
  227. Almost every file was touched.
  228.  
  229. Simple things like "putting the most-often-used structure
  230. member first in the structure" can save a lot of bytes.
  231. Using exactly the right number of register variables helps.
  232. Making exactly the right variables into registers helps.
  233. You have to experiment with your compiler...
  234.  
  235. #define temp_int (*(int *)0xc0)
  236. saves bytes, compared to a stack variable; if ZCPR uses this
  237. area, too bad. I used a simple CP/M 2.2, with CCPPLUS,
  238. and the original ( Digital Research ) BDOS.
  239. I used zsid on the program to find out where in main() the
  240. main processing loop starts, and used up those addresses as
  241. variable addresses; I also discovered that nobody was using
  242. 0xc0 to 0xcf, and used those locations as well.
  243.  
  244. Using temporary variables instead of repeated
  245. curwp->w_bufp->b_dotp->something->something_else
  246. saves a lot of bytes.
  247.  
  248. Rewriting the whole thing with a better algorithm also saves
  249. a lot sometimes!
  250.  
  251. When microemacs lengthens a line, or when it creates a new
  252. line, it allocates 16 bytes. Z80EMACS allocates 4 bytes.
  253. The savings is tremendous, especially when there are blank
  254. lines in the file.
  255.  
  256.         This is in line.c; for a while, I had COHERENT 3.0,
  257.         which came with microemacs 3.8 as its only editor.
  258.         I made the same change there, because they only had
  259.         small-model compiler, and it dumped core!
  260.  
  261. The AZTEC C library was available in source form. I chopped
  262. it down by quite a few bytes. Goodbye, stderr!
  263.  
  264. Replacing shared, duplicated code with a "goto" is an
  265. optimization that a real C compiler will perform.
  266. The one that comes free with UNIX doesn't do it, and neither
  267. does CP/M AZTEC C. ( "gcc" does, though. )
  268.  
  269. Making the messages more terse saves bytes!
  270.  
  271. 4.      STRUCTURE OF THE PROGRAM AND OF THE POSTINGS
  272.  
  273. comp.os.cpm isn't a "source-files" newsgroup.
  274. The whole source adds up to just under 600KB, uncompressed.
  275. One is not supposed to post so much to comp.os.cpm...
  276.  
  277. I don't have direct internet access, so I can't just pop it
  278. into an archive site.
  279.  
  280. I've decided to handle the source by mailing it to a volunteer
  281. >> acknowledged in the Internet version ofthis file <<
  282. who can simply stick it into an internet archive site.
  283.  
  284.     This will be part00, and it will run to about 8 parts.
  285.  
  286. The Z80EMACS editing system now consists of 3 ".COM" files,
  287. a slew of overlay files, a text data file, a ".SYM" file,
  288. source of one module, and minimal documentation.
  289.  
  290. It supports ASCII and ANSI terminals, but the user has to
  291. patch it by hand; this uses the source file and the ".SYM"
  292. file.
  293.  
  294. Binding of keystrokes to editor commands is a two-step
  295. procedure, using two of the ".COM" files, the text file, and
  296. the ".SYM" file. mapkeys.com makes a mapping, writing it to
  297. an intermediate file; meconfig.com uses the intermediate
  298. file to patch ME.COM.
  299.  
  300. Z80EMACS can find its overlays if they are on the current
  301. drive, on drive a:, or on drive b:, or on drive c:, but only
  302. ( I think ) in the current user area -- checking other user
  303. areas is a job for a more advanced BDOS than the one I used,
  304. not a job for an application program.
  305.  
  306. There are only two known bugs:
  307.  
  308. 1.      Random crashes, about once every three or four hours.
  309.         No clues, and it doesn't happen often enough to make it
  310.         easy to track down.
  311.  
  312. 2.      The file you name on the command line doesn't get read
  313.         in. The buffer gets named okay, but the file is never
  314.         read.
  315.  
  316. Note: both the bugs were fixed since the above was written.
  317. Several other things were also corrected.
  318.