🚀 go-pugleaf

Well, after talking it over with my wife, I have decided not to remove
the 64K limit on the size of the files editable by Freemacs.  It just
isn't important enough to me.  Since I don't make a lot of money off
of Freemacs copying fees, I don't have *that* incentive.

I have looked at enhancing the .ASM code to edit files larger then
64K.  This is pretty tough to do.  When I started writing Freemacs
back in '83, I targetted it for a 192K machine.  When you write for a
limited-resource environment, you make certain decisions that are
more-or-less irrevokable.  So it is with Freemacs.

I could re-write it in C, and in fact, I have been trying to do so.  I can see
that it's a bigger job than I want to tackle.  I'm not really interested in
reinventing the "programmable editor-on-a-PC" wheel.  At the time I wrote it,
it was the only programmable editor on a MS-DOS machine.  It was challenging.
Now I'm faced with the prospect of implementing a Brief, or an Epsilon, or
any one of the other thousands of programmable PC editors.

I would rather apply my talents to something more original.

Freemacs will not die so long as I am using it.  I will continue to
improve the MINT code and the .ASM code within the 64K file limit.
There is still lots of memory space for MINT code, and I plan on using
it.  I am not happy with the state of the latest release, which was
pushed out the door because I wanted to work on the >64K version.
There are more GNU Emacs incompatibilities that I plan to eliminate.
The next thing that I am going to do is add Boyer-Moore searching to
the search algorithms.

And, as always, I am always looking for user-written MINT code.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)|
       (Russ.Nelson@f360.n260.z1.fidonet.org)|(BH01@GEnie.com :-)