Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!m2c!wpi.WPI.EDU!rcarter From: rcarter@wpi.WPI.EDU (Randolph Carter (nee. Joseph H. Allen)) Newsgroups: comp.editors Subject: Re: REPOST: editor.101 Message-ID: <1991Jun12.202509.14825@wpi.WPI.EDU> Date: 12 Jun 91 20:25:09 GMT References: <1991Jun4.155657.4357@mks.com> <1991Jun11.195732.25500@wpi.WPI.EDU> <1991Jun12.143930.14186@mks.com> Organization: Kadath Tours, Inc. Lines: 72 The ghost of ant@mks.com (Anthony Howe) writes: >rcarter@wpi.WPI.EDU (Randolph Carter (nee. Joseph H. Allen)) writes: >>Another buffer technique I recently found is the "pieces" method from the >>pointing editor (I can't remember the author's name). As you edit, you break > ^^^^^^^^^^^^^^^ >What and where? Could you find a reference. This might make for another >article -- Editor.202 maybe. pt20pc.zip on simtel20 and its mirrors. It's from Charlie Crowly. I don't think there's a unix version. (Asside from the buffer technique, I don't like it since it requires that you use the mouse for everything). >>a contiguous buffer up into pieces and add or delete characters from the edges >>of the pieces. Each piece is stored in a malloc-like structure in a virtual >>memory file. You have to maintain a list of all the pieces and search through >>this list when you move out of a piece. You also glue pieces together when >>possible. This is a neat technique, but it's complicated. >This sounds like a variation of the scratch file method described in >"Software Tools" chapter 6. (I'm hoping to write an Editor.201 article >based on this chapter later this summer.) One problem with this is that you have to seek to the correct piece. If, as was done in the pointing editor, you keep a linked list of headers for the pieces, then editing will slow down as more pieces are made. Another is that the virtual memory system needs an malloc. With the scratch file technique, do you combine the files together when you reach some maximum? Or am I misunderstanding it... These buffering techniques remind me of "transaction files" for sorted databases. You add new records to the transaction file and update the entire database only periodically. But when reading the database, you always have to search (usually sequentially) through the transaction file before doing a binary search on the main database. >>An important technique for this and other buffer methods is to have routines >>which adjust pointer/size pairs as you move between pieces (or blocks or over >>the gap). This way, high level routines (like screen update) only have to >>keep track of the pointer and size and can simply call a function to update >>these when the beginning or end of a block is reached. >Why sizes? (I'm a bit slow this morning) Oh sorry, I mean the number of characters left at the pointer. If its a linked-list editor, then the pointer will be in a small block and the size has the amount remaining in it. >>Another usefull technique is to try to keep buffer pointers in the form of a >>byte offset from the beginning of the file in the buffer. There then needs to >>be logical to physical translation functions but keeping the pointer this >>simple will make implementing higher level functions much easier. >This technique is fine for the Buffer Gap Scheme, but I don't see how this >would apply in a Link List Scheme. Link List and Pieces would require that >pointers become structures suitable for the scheme n'est pas? You have to have some other structure that lets you quickly seek to the proper entry. For example, have blocks with pointer/size pairs in them in the virtual memory system which refer to blocks containing text (you can have multiple levels of these). Then you can standard tree techniques (btree techniques?) to adjust and balance the trees as you insert/delete. To make it practicle (you don't want to have to seek through all this for every byte you access (except in the gap editor)), have a tiny cache containing the last few seeks. -- /* rcarter@wpi.wpi.edu */ /* Amazing */ /* Joseph H. Allen */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}