CBM Funet Archive

home *** CD-ROM | disk | FTP | other *** search

/ CBM Funet Archive / cbm-funet-archive-2003.iso / cpm / editors / z80emacs.pma / POSTING.0 < prev next >

Wrap

Text File | 1979-12-31 | 13KB | 318 lines

tHIS IS THE FIRST POSTING OF THE z80 MICROEMACS SOURCE. 1. history i STARTED WITH MICROEMACS 3.6, WHICH SAID " * tHIS PROGRAM IS IN PUBLIC DOMAIN; WRITTEN BY dAVE g. cONROY." aLL THE FILES BEING EDITED IN THE BUFFERS ARE KEPT IN MEMORY; IT WAS FAIRLY EASY TO COMPILE THE VERSION OF MICROEMACS i USED, AND PRODUCE A RUNNABLE PROGRAM, BUT THE FIRST VERSION HAD NO SPACE AT ALL FOR FILES! (mARCH 1989). pORTING TO CP/M WAS EASY BECAUSE i USED aztec c ( VERSION 1.05C, FROM 1982 ). i REALLY WOULD HAVE PREFERRED bds/c BECAUSE COMPILATION IS SO FAST, BUT: NO STATIC INITIALIZERS, NO TYPEDEFS, NO "LONG"... i'M NOT SURE IF bds HAS OVERLAYS. iF bds HAS OVERLAYS, IT WOULD BE WORTH WHILE PORTING MY VERSION TO bds. iF IT DOESN'T, AN OVERLAY SYSTEM COULD BE ADDED. i STARTED MAKING OVERLAYS AND OPTIMIZING, AND SOON ( jUNE 1989 ) COULD EDIT ABOUT 24kb OF ONE FILE ( 58kb tpa ). aS SOON AS i COULD EDIT 3k, i STARTED USING THE EDITOR TO MAINTAIN ITSELF; EDITORS ARE ALWAYS WELL-TESTED IF YOU USE THEM TO MAINTAIN THEMSELVES. tHIS IS WHY THE ORIGINAL FILES WERE SPLIT UP INTO VERY SMALL PIECES, AND SOME COMMENTS REMOVED. tHE COMMENTS REMOVED INCLUDE THE MICROEMACS AUTHORS' NAMES, BUT MICROEMACS IS FREELY AVAILABLE WITH ATTRIBUTION. nO ATTEMPT TO HIDE THE ORIGIN IS INTENDED. i THINK THE VERSION OF MICROEMACS i USED WAS 3.6, BUT i CAN'T BE SURE. tHEN i STOPPED AND CREATED A PROGRAM FOR CUSTOMIZATION OF THE BINARIES, FIGURING TO DISTRIBUTE THE Z80ME PROGRAM IN THAT FASHION. tHERE IS ONE CUSTOMIZATION PROGRAM THAT PATCHES TERMINAL-CONTROL SEQUENCES INTO THE BINARY, AND ANOTHER THAT PATCHES KEYSTROKE-TO-COMMAND BINDINGS. i COULD FIND NO cp/m bbs TO POST IT TO, AND GAVE UP. ( jULY 1989 ). dOCUMENTATION WAS NEVER WRITTEN, ESPECIALLY FOR THE CUSTOMIZATION, AND NOW i HAVE TO WORK FROM MEMORY. iN FACT, i FIND NO PROGRAM TO PATCH TERMINAL-CONTROL; THE TERM-CONTROL MODULE WAS WRITTEN TO MAKE THIS POSSIBLE, THOUGH. iN aUGUST OR sEPTEMBER, 1991, i SAW A MESSAGE IN COMP.OS.CPM ASKING ABOUT EDITORS. i POSTED A NOTICE ABOUT MICROEMACS FOR CP/M AND GOT MANY HELPFUL AND ENCOURAGING REPLIES. ---------------------------- 2. philosophy and features tHIS PROGRAM ALSO EMBODIES SOME OF MY THOUGHTS ABOUT THE NATURE OF EDITORS. pROGRAMMERS USE THE EDITOR MORE THAN ANY TOOL, AND THINK ABOUT IT LESS THAN ANY OTHER. eVEN WITH A SIMPLE EDITOR LIKE VI, MOST PROGRAMMERS DON'T BOTHER TO LEARN EVERY COMMAND... tHE VERSION OF MICROEMACS THAT i STARTED WITH WAS AN AWFUL EDITOR, AND i HATED IT. sOME THINGS HAD TO CHANGE IF i WAS TO USE IT, SO i CHANGED THEM. iF AN EDITOR'S BINDINGS ARE PERFECT FROM THE STANDPOINT OF HAVING NEAT LITTLE MNEMONICS ( ^n FOR "NEXT LINE" ), THEY MAY ARE UNLIKELY TO BE PERFECT FROM THE STANDPOINT OF MAKING FREQUENTLY-USED COMMANDS EASY TO TYPE. a PRIME EXAMPLE IS THE EMACS BINDING OF mETA-F FOR "WORD FORWARDS"; THIS IS A FREQUENTLY-USED COMMAND, AND SHOULD BE one keystroke! tHE DEFAULT z80emacs WORD FORWARD IS ^f, WORD BACK IS ^b, DEL WORD FORWARD IS ^w. iF AN EDITOR'S BINDINGS ARE PERFECT FROM BOTH OF THE ABOVE STANDPOINTS, THEY STILL WILL RUN INTO TROUBLE WITH THE KEYBOARD: YES, THE DREADED arrow keys. iF YOU'RE ALERT, AND LEANING FORWARD OVER THE KEYBOARD, YOU MAY NOT WANT TO USE THE ARROW KEYS; SUCH IS THE ARGUMENT IN FAVOR OF VI'S "HJKL". iF YOU'RE THINKING INSTEAD OF TYPING, BROWSING INSTEAD OF HACKING, YOU WANT THE ARROW KEYS TO WORK. z80emacs HAS PREDEFINED ARROW KEYS THAT FIT MOST ascii TERMINALS, ^h^j^k^l, AND ^v THE SAME AS ^j. iF A COMMAND IS HARD TO TYPE, SO WHAT? iF YOU USE IT TWICE IN A ROW, SIMPLY USE THE "repeat last command" KEY! iT APPEARS THAT i NEVER PUT THIS FEATURE INTO z80emacs. VI HAS TWO DIFFERENT KINDS OF WORD COMMANDS, "w" AND "W" ( IT ALSO PROVIDES FORWARD, BACKWARD, AND FORWARD-TO-END DIRECTIONS FOR THEM ). z80emacs HAS WORD-FORWARD AND WORD-BACKWARD COMMANDS, JUST TWO COMMANDS, BUT THERE IS ANOTHER COMMAND THAT CHANGES THE WAY THESE TWO WORK -- YOU CAN USE VI-STYLE OR EMACS-STYLE WORDS, AND STOP AT END-OF-WORD OR AT BEGINNING-OF-WORD. z80emacs DOESN'T IMPLEMENT THE VI ^^ ( CONTROL-CARAT ) COMMAND, THAT YOU USE TO TOGGLE BETWEEN BUFFERS, BUT IT DOES HAVE THE VI :N COMMAND, THAT YOU USE TO SEQUENTIALLY WALK THE LINKED LIST OF BUFFERS. iT IS INEXCUSABLE FOR ANY EDITOR TO BE WITHOUT AT LEAST ONE OF THESE TWO COMMANDS. bOTH COMMANDS should EXIST. z80emacs CAN DISPLAY MORE THAN ONE BUFFER ON THE SCREEN AT THE SAME TIME; THIS CAPABILITY WAS PART OF THE ORIGINAL MICROEMACS. wITH MORE THAN ONE BUFFER ON THE SCREEN, HOWEVER, YOU MUST REMEMBER TO TYPE VERY SLOWLY! z80emacs STORES ITS KEYBOARD MACRO IN A FILE; IT USES THE SAME MECHANISM AS THE "EXECUTE-FILE" COMMAND, WHICH MICROEMACS DIDN'T HAVE. kEYBOARD MACRO EXECUTION IS SLOW, BUT IT'S BETTER THAN RETYPING COMMANDS. sTORING THE KEYBOARD MACRO IN A FILE MEANS THAT YOU CAN USE IT AGAIN AFTER YOU EXIT AND RESTART THE EDITOR. iT LOOKS LIKE z80emacs STILL DOESN'T HAVE "EXECUTE FILE"; HOWEVER, INTERNALLY, "EXECFILE" WOULD USE THE SAME MECHANISMS THAT YOU USE TO EXECUTE THE KEYBOARD MACRO FROM A FILE, AND SO "EXEC FILE" CAN BE ADDED WITH RELATIVE EASE. z80emacs MAKES ".bak" FILES WHEN IT SAVES OR WRITES. z80emacs HAS THE "VIKILL" COMMAND; KILLS WHOLE LINES, NO MATTER WHERE THE CURSOR IS IN THE LINE. i DESPISE THE EMACS ^k COMMAND, EXCEPT WHEN USED AS "KILL-TO-END" ( THE EMACS-STYLE KILL IS STILL THERE ). z80emacs HAS FUNNY VERTICAL ARROWS. uP-ARROW MOVES TWO LINES. bOTH UP-ARROW AND DOWN-ARROW CAN WRAP FROM THE LAST LINE OF THE BUFFER TO THE FIRST LINE. tHESE ARE BOTH BUGS THAT WOULD HAVE BEEN EASY TO FIX; BOTH ARE INTERESTING FEATURES. i PUT THE FUNNY UP-ARROW IN MY UNIX VERSION OF EMACS, AND USED IT FOR AT LEAST A YEAR BEFORE DECIDING i DIDN'T LIKE IT AFTER ALL ( IT WAS THAT CLOSE TO BEING A WASH! ). tHE IDEA IS, IF YOU DON'T SPECIFY A PARAMETER, UP-ARROW MOVES BY TWO LINES; IF YOU DO SPECIFY, IT MOVES THE CORRECT NUMBER. iF YOU WANT TO MOVE UP 1, 2, 3, 4, 5, OR 6 LINES, IT TAKES 2, 1, 3, 2, 4, OR 3 KEYSTROKES INSTEAD OF 1, 2, 3, 4, 5, OR 6 KEYSTROKES; AN AVERAGE SAVINGS OF ONE KEYSTROKE PER LINE. hOWEVER, MOVING UP 1 LINE IS THE MOST COMMON CASE, AND THE EXTRA MENTAL EFFORT INVOLVED IN OVERSHOOTING AND MOVING DOWN ONE IS DISTRACTING. ( aS i TYPE THIS, i HAVE FUNNY-UP-ARROW IN EFFECT ON unix; YOU REALLY DO GET USED TO IT. ) z80emacs HAS TWO DIFFERENT COMMAND INTRODUCERS; ONE FOR POSITIVE VALUES ( ^u, "UNIVERSAL PARAMETER" ), ONE FOR NEGATIVE ( ^\ ). mANY COMMANDS HAVE SPECIAL MEANINGS WITH NEGATIVE PARAMETERS. aCCORDING TO MY EDITOR THEORIES, IT'S EASIER TO LEARN AND REMEMBER SOME OF THE ODD COMMANDS IF THEY'RE SHOEHORNED ONTO NORMAL COMMANDS WITH SPECIAL PARAMETERS. fOR EXAMPLE, TAKE THE "GO-TO-START-OF-LINE" COMMAND, WITH THE NORMAL EMACS BINDING OF ^a; IF YOU JUST ENTER ^a WITH NO PARAMETERS, YOU GO TO COLUMN 0; WITH THE "SHOEHORN" THEORY IN EFFECT, IF YOU SPECIFY A POSITIVE PARAMETER, YOU GO TO COLUMN n, AND IF YOU SPECIFY A NEGATIVE PARAMETER, YOU GO TO THE FIRST NON-WHITE-SPACE CHARACTER IN THE LINE. i FEEL THIS IS BETTER THAN HAVING THREE SEPARATE COMMANDS ( VI "0", "{$7c}", AND "_", RESPECTIVELY. mETADIGITS START ARGUMENTS. tHEY START ARGUMENTS BETWEEN THOSE WHO LIKE THEIR EMACS TO ACCEPT ESCAPE-9 AS A COMMAND, AND THOSE WHO LIKE IT TO SUPPLY AN ARGUMENT OF 9 TO THE NEXT COMMAND. i AM IN THE LATTER CAMP, SO IN z80emacs, mETADIGITS START ARGUMENTS. z80emacs HAS THE VI "FIND-CHARACTER-IN-LINE" COMMAND. z80emacs HAS THE "GOTO LINE BY LINE NUMBER" COMMAND. (BUT DOESN'T DISPLAY LINE NUMBERS, SO IT'S NOT AS USEFUL A COMMAND AS IT SHOULD BE). z80emacs ALLOWS YOU TO CHANGE THE BUFFER NAME AS WELL AS THE FILE NAME. z80emacs HAS THE VI "GO TO COLUMN NUMBER" COMMAND: "GO TO START OF LINE" WITH A POSITIVE PARAMETER GOES TO A SPECIFIC COLUMN IN THE LINE. ( WITH A NEGATIVE PARAMETER, IT GOES TO END-OF-LINE. ) ----------------------------------------------- aLAS, NO REGULAR EXPRESSIONS, NO SEARCH-REPLACE. ----------------------------------------------- 3. optimization to save space iN ORDER TO HAVE MORE ROOM FOR EDITING FILES, THE PROGRAM HAD TO BE MADE SMALLER. a LARGE PART OF THIS WAS DONE BY MOVING THINGS TO OVERLAYS, BUT SOME OF IT WAS PURE BYTE-SQUEEZING. mOST OF THE OPTIMIZATION WAS DONE IN THE ROOT SEGMENT, BUT SEVERAL OVERLAYS WERE OPTIMIZED TO MAKE THE OVERLAY AREA SMALLER. tHE KEY TO GOOD PERFORMANCE WITH OVERLAYS IS TO HAVE ALL THE MOST-OFTEN-USED COMMANDS IN ONE OVERLAY: THIS IS OVUDFB31.C ( OVERLAY UP DOWN FORWARD BACK, OVERLAY 31 ) aLMOST EVERY FILE WAS TOUCHED. sIMPLE THINGS LIKE "PUTTING THE MOST-OFTEN-USED STRUCTURE MEMBER FIRST IN THE STRUCTURE" CAN SAVE A LOT OF BYTES. uSING EXACTLY THE RIGHT NUMBER OF REGISTER VARIABLES HELPS. mAKING EXACTLY THE RIGHT VARIABLES INTO REGISTERS HELPS. yOU HAVE TO EXPERIMENT WITH YOUR COMPILER... #DEFINE TEMP_INT (*(INT *)0XC0) SAVES BYTES, COMPARED TO A STACK VARIABLE; IF zcpr USES THIS AREA, TOO BAD. i USED A SIMPLE cp/m 2.2, WITH ccpplus, AND THE ORIGINAL ( dIGITAL rESEARCH ) bdos. i USED ZSID ON THE PROGRAM TO FIND OUT WHERE IN MAIN() THE MAIN PROCESSING LOOP STARTS, AND USED UP THOSE ADDRESSES AS VARIABLE ADDRESSES; i ALSO DISCOVERED THAT NOBODY WAS USING 0XC0 TO 0XCF, AND USED THOSE LOCATIONS AS WELL. uSING TEMPORARY VARIABLES INSTEAD OF REPEATED CURWP->W_BUFP->B_DOTP->SOMETHING->SOMETHING_ELSE SAVES A LOT OF BYTES. rEWRITING THE WHOLE THING WITH A BETTER ALGORITHM ALSO SAVES A LOT SOMETIMES! wHEN MICROEMACS LENGTHENS A LINE, OR WHEN IT CREATES A NEW LINE, IT ALLOCATES 16 BYTES. z80emacs ALLOCATES 4 BYTES. tHE SAVINGS IS TREMENDOUS, ESPECIALLY WHEN THERE ARE BLANK LINES IN THE FILE. tHIS IS IN LINE.C; FOR A WHILE, i HAD coherent 3.0, WHICH CAME WITH MICROEMACS 3.8 AS ITS ONLY EDITOR. i MADE THE SAME CHANGE THERE, BECAUSE THEY ONLY HAD SMALL-MODEL COMPILER, AND IT DUMPED CORE! tHE aztec c LIBRARY WAS AVAILABLE IN SOURCE FORM. i CHOPPED IT DOWN BY QUITE A FEW BYTES. gOODBYE, STDERR! rEPLACING SHARED, DUPLICATED CODE WITH A "GOTO" IS AN OPTIMIZATION THAT A REAL c COMPILER WILL PERFORM. tHE ONE THAT COMES FREE WITH unix DOESN'T DO IT, AND NEITHER DOES cp/m aztec c. ( "GCC" DOES, THOUGH. ) mAKING THE MESSAGES MORE TERSE SAVES BYTES! 4. structure of the program and of the postings COMP.OS.CPM ISN'T A "SOURCE-FILES" NEWSGROUP. tHE WHOLE SOURCE ADDS UP TO JUST UNDER 600kb, UNCOMPRESSED. oNE IS NOT SUPPOSED TO POST SO MUCH TO COMP.OS.CPM... i DON'T HAVE DIRECT INTERNET ACCESS, SO i CAN'T JUST POP IT INTO AN ARCHIVE SITE. i'VE DECIDED TO HANDLE THE SOURCE BY MAILING IT TO A VOLUNTEER >> ACKNOWLEDGED IN THE iNTERNET VERSION OFTHIS FILE << WHO CAN SIMPLY STICK IT INTO AN INTERNET ARCHIVE SITE. tHIS WILL BE PART00, AND IT WILL RUN TO ABOUT 8 PARTS. tHE z80emacs EDITING SYSTEM NOW CONSISTS OF 3 ".com" FILES, A SLEW OF OVERLAY FILES, A TEXT DATA FILE, A ".sym" FILE, SOURCE OF ONE MODULE, AND MINIMAL DOCUMENTATION. iT SUPPORTS ascii AND ansi TERMINALS, BUT THE USER HAS TO PATCH IT BY HAND; THIS USES THE SOURCE FILE AND THE ".sym" FILE. bINDING OF KEYSTROKES TO EDITOR COMMANDS IS A TWO-STEP PROCEDURE, USING TWO OF THE ".com" FILES, THE TEXT FILE, AND THE ".sym" FILE. MAPKEYS.COM MAKES A MAPPING, WRITING IT TO AN INTERMEDIATE FILE; MECONFIG.COM USES THE INTERMEDIATE FILE TO PATCH me.com. z80emacs CAN FIND ITS OVERLAYS IF THEY ARE ON THE CURRENT DRIVE, ON DRIVE A:, OR ON DRIVE B:, OR ON DRIVE C:, BUT ONLY ( i THINK ) IN THE CURRENT USER AREA -- CHECKING OTHER USER AREAS IS A JOB FOR A MORE ADVANCED bdos THAN THE ONE i USED, NOT A JOB FOR AN APPLICATION PROGRAM. tHERE ARE ONLY TWO KNOWN BUGS: 1. rANDOM CRASHES, ABOUT ONCE EVERY THREE OR FOUR HOURS. nO CLUES, AND IT DOESN'T HAPPEN OFTEN ENOUGH TO MAKE IT EASY TO TRACK DOWN. 2. tHE FILE YOU NAME ON THE COMMAND LINE DOESN'T GET READ IN. tHE BUFFER GETS NAMED OKAY, BUT THE FILE IS NEVER READ. nOTE: BOTH THE BUGS WERE FIXED SINCE THE ABOVE WAS WRITTEN. sEVERAL OTHER THINGS WERE ALSO CORRECTED.