Technical Notes on EdHak (& Diary)
Updated for v 2.3, 08 Feb 1992


Text Display Speed and Clipping
-------------------------------
EdHak v 2.2 now uses the built-in GEM VDI graphics text output routine
rather than writing directly to screen ram as it did in versions 1.8 -
2.1.  As long as the character output is forced to be at byte boundaries
(i.e., some multiple of 8 pixels from the left edge of the screen), this
VDI method is plenty fast, and when combined with a software accelerator
such as QuickST or TurboST, the speed is about as fast as can be done. 
(My hat is still off to Tempus which is still faster, but it doesn't run
as an ACC.)  By using the VDI text output, compatibility should
generally be better.  Also screen redraws when moving windows around are
more complete, since GEM draws partial characters when necessary (i.e.,
when the clipping rectangle didn't happen to be on a character
boundary), whereas the old EdHak text output routine could only draw
complete characters.


Tech Notes on Memory Management & Buffer Size
---------------------------------------------
The buffer size must be saved to the main prg or acc file as part of the
BSS length in the file header (rather than reading it in from a separate
config file) to be able to safely allocate the proper amount of memory. 
Other desk accessories that use a more typical method of allocating memory
(dynamic allocation using a Malloc call) are not handled properly by TOS
and will steal gobs of extra ram if you ever try switching between low and
medium resolutions, because TOS does not deallocate that ram before
allocating it again.  STeno, which I also consider to be a fine editor,
gets around this by letting the user deallocate the ram when desired.

EdHak handles the text buffer as simply one continuous block of RAM, and so
to insert or delete near the beginning of that can require moving around
a large chunk of ram.  Despite the fast machine code routine that handles
this, it obviously isn't fast enough when you get above about 25K.  The
way other word processors get around this is to dynamically allocate small
chunks of ram as needed and link them together with pointers thus requiring
much fewer actual bytes to be moved.  If that approach is used in an ACC
things can get screwed up in a low<->med resolution switch. 
Incidentally, the slowdown is exactly the same thing you run into with
Flash's buffer, if you ever use that.  This slowdown is one main reason
why I have begun work from the ground up on an all-assembly language
version which will use pointers and blocks of RAM (but will still be
crash proof for resolution changes).  The beginnings of this are in the
program EdWin in the Freeware folder of your disk.


Technical Notes  (paste buffer, line pointers, and word wrap)
---------------
The paste buffer, which is used to hold cut blocks and deleted lines and
characters, is not very large.  It is equal to 1/4 the size of the edit
buffer (2560 bytes in the case of the normal 10K buffer).  This buffer is
also used for word wrap operations, so anything in the paste buffer is
lost as soon as any word wrap is done.  This buffer is the same size as the
block of memory that is used to store pointers to the start of each line. 
Since each pointer is four bytes long, the default 10K edit buffer can
handle up to 2560/4 = 640 lines.  If you load a file with LOTS of blank or
short lines, you could exceed that, in which case the file will load, but
the last line will just be one long line containing all the rest of the
file, but the text will not have been corrupted at all.  I hope to rewrite
all this code for version 3.0 to get rid of the need for the line pointer
buffer.


Note on Extended Lines  (longer than one window width)
----------------------
Be sure to turn off Wrap before trying to edit a line that extends beyond
the first window, unless you want it to wrap as soon as you hit a key
(or as soon as the line end hits the wrap column if you've set it to
wrap at column 90 or something).  Simply moving the cursor with the arrow
keys beyond the furthest left or right columns of the window will move you
to the next or previous section of the line.  Shift-left or right arrow
takes you to the start/end of the line, no matter how far over it is. 
Another command, Shift-Control-arrow, takes you just to the left or right
edge of the current window.  Clicking with the mouse by the edge of the
window will also take you to the next/previous section of the line.

[ End ]
