GNU Emacs, memory usage, releasing

[Greg A. Woods]

Re: article <1558 at aber-cs.UUCP> by pcg at aber-cs.UUCP (Piercarlo Grandi)

I was about to retrieve a copy of GNU Emacs in order to determine the
buffer management scheme it used.  I am a Jove user, and have been
more than satisfied with Jove.  Recently I've had the occasional need
to use an editor with an extension language.  Given that Jove is a
known beast, I was considering building a version with elk hooked in
(elk is a shceme interpreter).  I wanted to make sure Jove would be a
good base, and that GNU Emacs was indeed a waste of disk space.

Your article has convinced me that GNU Emacs is indeed, in my case, a
waste of disk space.  However, you have also given me a few ideas.
Jove needs a fair amount of clean up before it will be able to edit
binary files.  It has a hard-coded line length limit, and uses str*
functions in places to shuffle data around.  I don't know to what
extent this cleanup will have to go yet.  Jove has several
implementation features which make it desireable in both small
machines and virtual memory machines.  It may just be more valuable to
do this work than to fix GNU Emacs in the ways you have described.  Of
course fixing the line length limit will have to be done with care to
allow the occasional editing of binary files to be reasonably
efficient.

Once Jove has been cleaned up, it will be a complete, functional
subset of GNU Emacs, the missing piece being primarily the lisp
extension language.  If I can successfully hook in elk, I'll then have
an editor which is a functional equivalent of GNU Emacs, with the
added benefit of having several compile time options which will make
it much smaller and more efficient.
-- 
						Greg A. Woods

woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET}
+1 416 443-1734 [h]   +1 416 595-5425 [w]   VE3-TCP   Toronto, Ontario; CANADA