🚀 go-pugleaf

While the need for an editor that can deal with a file larger than memory
may be rare, for a developer it is often crucial.  Since I learned my debug
habits three decades ago, I tend to do a lot of debug printing.  Capturing a
detailed debug trace to a file, and then using an editor for the convenient
search and reformat capabilities, is an effective technique when the problem
is hidden somewhere totally unknown in a long execution.

Working in the MS/DOS universe, I was delighted with a privately developed,
incredibly capable editor that let me edit a 3.5 megabyte debug trace without
a hiccup in the available 340K RAM data space, and find a problem that had
eluded me for days in about an hour and a half.

Anyone designing an Amiga editor should look into 1) limiting its real
memory use in any case to avoid adverse impact on other multitasking
programs, 2) giving the user explicit command line control of maximum memory
use, so that when nothing else is going on, RAM can be sacrificed for speed,
and 3) developing a paradigm of execution modeling virtual memory in
software with even secondary memory management for overflowing cut and paste
buffers, so that file editing is limited by disk, rather than RAM, size.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>