Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!psuvax1!rutgers!mephisto!mcnc!thorin!homer!leech
From: leech@homer.cs.unc.edu (Jonathan Leech)
Newsgroups: comp.editors
Subject: Re: Editor 101
Keywords: Data Structure
Message-ID: <11860@thorin.cs.unc.edu>
Date: 5 Feb 90 16:52:31 GMT
References: <13952@s.ms.uky.edu> <7634@wpi.wpi.edu> <20518@watdragon.waterloo.edu> <7676@wpi.wpi.edu>
Sender: news@thorin.cs.unc.edu
Reply-To: leech@homer.cs.unc.edu (Jonathan Leech)
Organization: University Of North Carolina, Chapel Hill
Lines: 32
Summary:
Expires:
Sender:
Followup-To:
Distribution:

In article <7676@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes:
>struct line
> {
> struct line *next;	/* Link to other lines */
> struct line *prev;
> unsigned char size;	/* Size of 'text' */
> unsigned char bksize; /* Size of malloc block this is in */
> char text[];
> };
>...
>
>This buffer scheme eliminates the large delays of the gap method and also
>eliminates some of the delays at higher levels in the editor (you don't have
>to search for ends of lines any more), but it also has some problems.	Most
>significantly, the line length is limited and the file must be processed when
>it's loaded and stored.

    If you insist on using an unsigned char as your line length,
that would be a problem. Use a long.

    There are some other nice things you can do with the linked-list
model.	It makes selecting a subset of lines to edit (aka the XEDIT
ALL command) very easy, for example.  I come from the quarter-plane,
rectangle-oriented school of editing, and this model fits much better
than buffer gap, which in turn seems natural for stream-oriented
editors like EMACS.

--
    Jon Leech (leech@cs.unc.edu)    __@/
    ``The experiment must be wrong'' - Richard Feynman (as quoted by
    Eugen Merzbacher), upon hearing that experimental data did not
    agree with theoretical predictions. Feynman was correct :-)