🚀 go-pugleaf

In article <MWM.90Sep25180852@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes:
>I've just started poking at this, because one of the changes to mg3
>before the release is going to be ditching the linked list of lines in
>favor of a buffer gap editor.

Ahhh, finally!  That "line too long" stuff is bogus.  TECO used a buffer
gap, and I *think* GNU Emacs does too.  It's a great idea, the
performance is quite good.

>Making the editor page to disk after this is done would be simple, but
>it's not clear even that's worth the trouble.

But it would be nice to be able to edit large files, even when memory is
low.  After all, this is a multitasking machine.  I'd hate to have to
shut down everything just to edit a large file.

>With memory mapping of some kind, doing everything in memory requires
>a contiguous chunk of memory as big as the file. This is clearly
>unacceptable on the Amiga, especially for an editor like mg. The
>solution is a "paged" buffer, where the file buffer is a linked list
>of pages, each of a fixed size (or each with a gap...hmmmm).

I was thinking about this once, and I decided that I'd have one gap,
which would be copied between "pages".  When the gap gets too small, you
just insert a new "page" in the linked list, and when the gap is as big
as a page, you delete/remove it from the list.  I thought that having a
gap in each page would get messy rather quickly.  But, maybe not.

The one-buffer, one-gap you scheme can move the gap anywhere in the
editing buffer in a single move (copy) operation.  However, the multiple
page buffer scheme requires multiple copy operations to move the gap to
any point in the buffer.  I think you could probably optimize this after
thinking about it a bit, and reasonably large pages, say 1K to 4K
(dynamic?), would help.

Perhaps if you came up with a huristic as to when to compress multiple
gaps into one, then it would be resonable.  I just have this vision of
many pages each with only a few bytes and a hugh gap.  I'll stew on it.

>The obvious "tmp" place is ram, which doesn't buy anything. Likewise,
>paging to floppy doesn't buy much. I tend to agree with Dave - with a
>1 meg nominal minimum machine, and those with hard disks probably
>having more, there's not much reason to want to page to disk, and the
>space/time spent on that code can probably be put to better use.

I understand Dave's point, but I still think that even with a 1 meg
machine, you'll still be multitasking other things.  I sure like being
able to keep my file(s) in the editor while I run the compiler and
linker!  Sure, paging to a floppy won't be as nice as a hard disk, but
then that would be just another reason for a person to buy a hard disk.

>Anyone have any comments?

Nope, none.  :-)  Actually, sounds like a great idea!

>	<mike

-hans
------------------------------------------------------------------------
  Hans-Gabriel Ridder			Digital Equipment Corporation
  ridder@elvira.enet.dec.com		Customer Support Center
  ...decwrl!elvira.enet!ridder		Colorado Springs, CO