🚀 go-pugleaf

In article <14669@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes:
   Just a couple:  Most gap editors I'm familiar with have
   two places where the user experiences speed hits

   1)  when the editor is spooling text off to disk

The shouldn't be a problem. In fact, a buffer gap should be faster
than the linked list of lines that mg currently use, as you replace
one write per line with two per buffer. That's one of the reasons for
wanting to make the change. Now, if you're talking about paging unused
pages to disk, and new pages back - that's a different problem, and
one I haven't looked into.

   2) when the gap is being shifted in a large file

That's the critical problem. That's why I like the idea of one gap per
buffer, with middlin-sized buffers (4 to 16K, say). That way, the
worst thing to have to move is a chunk of text of that size.

   editing files no larger than 32K, for instance,
   because otherwise the pauses as they scrolled and
   edited drove them crazy.

Stock buffer gap shouldn't have a problem scrolling (you don't move
the gap unless edit text, so scrolling doesn't involve any buffer
movement). If it's paging, then there might be a problem.

   And, the logical place to use as a temporary directory is :t
   if one doesn't exist, create it.  Edit, which can edit files
   larger than memory available uses a temp file is :t for this
   purpose. 

Is that on the device the file is on, or on the device the text editor
was started from? And it's sort of silly if you that device winds up
being ram:. Likewise, you have to deal with being able to write on
that file. Since mg isn't part of a commercial product, I'm tempted to
make this feature something you have to enable at compile time, and if
it's on, allow the user to give a file name for the disk buffer file.

	Thanx,
	<mike


--
And then up spoke his own dear wife,			Mike Meyer
Never heard to speak so free.				mwm@relay.pa.dec.com
"I'd rather a kiss from dead Matty's lips,		decwrl!mwm
Than you or your finery."