🚀 go-pugleaf

In article <483@public.BTR.COM> eeh@public.BTR.COM (Eduardo E. Horvath  eeh@btr.com) writes:
	   The logical place to put the temporary file is in t: (maybe that's
   what Andy meant) so you can assign the temporary directory wherever you want:
   RAM: for speed, or a HD partition for size.

Let me see if I've got this straight: the stuff that the editor pages
out to disk because there's not enough ram, you want to put in RAM:
for speed? Methinks there's a problem here. If nothing else, it'd
probably take less memory and be faster just to leave the information
paged in.

	   1) Allow the user to (optionally) specify the number of buffers
		   to use when launching mg.

Sorry, the number of buffers is unlimited, and will stay that way.
Besides which, a single buffer can grow arbitrarily large.  Allowing
for a fixed amount of memory to be used might (just might) be
possible, but would either require 1) pre-allocating that much memory,
which isn't acceptable for editing small files, or 2) keeping a
running total of how much memory was allocated, which is liable to add
to much overhead. Since the point of paging to disk is to allow
editing of files larger than memory, adding other strange constraints
seems counterintuitive.

	   2) Provide a "flush out all buffers to disk" command in mg to 
		   free up memory just before launching a memory hog
		   application.

Not possible, mostly for portability reasons.

	<mike
--
He was your reason for living				Mike Meyer
So you once said					mwm@relay.pa.dec.com
Now your reason for living				decwrl!mwm
Has left you half dead