Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!intercon!amanda@intercon.com From: amanda@intercon.com (Amanda Walker) Newsgroups: comp.sys.mac.programmer Subject: Re: Serious programming question Message-ID: <1507@intercon.com> Date: 24 Oct 89 16:36:03 GMT References: <89295.142753CXT105@PSUVM.BITNET> <4002@helios.ee.lbl.gov> <8785@hoptoad.uucp> <299@fsu.scri.fsu.edu> Sender: news@intercon.com Reply-To: amanda@intercon.com (Amanda Walker) Organization: InterCon Systems Corporation Lines: 24 In article <299@fsu.scri.fsu.edu>, pepke@loligo (Eric Pepke) writes: > It just so happens that I am curently working on a text editor for programming > right now. I am using a single buffer with a single gap using long integers > to remember the offsets to the gap, which I think is similar to the way Capps > used to do it. (If Capps were still a supported product, I would probably be > using it.) Yup, sounds like Capps. For a lot of applications, a simple buffer-gap scheme is definitely a good way to go. It is quite fast in normal kinds of editing, and it is simple enough that it's easy to implement and maintain. It's biggest bad point is that it still needs to have the whole document in memory. This isn't so bad for something like GNU Emacs, where stuff just gets swapped out, but on a Mac it can be annoying. You could build some kind of simple paging system underneath the editor buffer, though. Another problem is that it lends itself to "big hunk o' ASCII" kinds of text editing. Adding style run & script manager support gets... interesting. If you're doing things that are more word processing than text editing, I'd suggest using the linked list of paragraphs approach. This also gives you a natural unit of swapability for editing in cramped memory. -- Amanda Walker