Xref: utzoo alt.religion.computers:2275 comp.editors:2286 Path: utzoo!utgpu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!daver!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: alt.religion.computers,comp.editors Subject: Re: vi's or any full-screen editors Message-ID: <1990Dec27.224407.22905@zorch.SF-Bay.ORG> Date: 27 Dec 90 22:44:07 GMT References: <6gHJu1w163w@pain> Organization: SF-Bay Public-Access Unix Lines: 93 In article <6gHJu1w163w@pain> root@pain (System Adminstrator) writes: >I'm attempting to start writing a wanna-be full-screen editor. >Can anybody suggest the data structure to use? I figured a record of >a doubly-linked-list, front, and rear. The doubly-linked list's nodes will >each represent a line in and be implemented as an array. >something like: > text = record > data :- DoublyLinkedListnode > front:- DoublyLinkedListPtr > rear :- DoublyLinkedListPtr > > doublylinkedlistptr = pointer to doublylinkedlistnode > doublylinkedlistnode = record > pred :- doublylinkedlistptr > data :- array of char > next :- doublylinkedlistptr >I know that this might not be the most effecient and all, but am I gonna run >into trouble if I use this structure? Thanks! Even if you have to implement your own garbage collection to support it, you want to avoid fixed length lines like the plague. Saw a post yesterday from one guy whose fav editor supported editing in long lines, and he was talking hand editing 0.75 megabyte _lines_ (the HPGL output of the HP plotter driver software). Fixed length _anything_ is a no-no; you should make as goals for your editor the ability to edit any file that will fit on a storage device, in either ascii or hex-binary representation, with any line length or no such thing as a "line" at all, just a stream of bytes. Among other things, this will naturally lead you to a situation in which the file is in two major chunks, with the cursor in the middle, for speed of inserts. Another poster has mentioned a common practice of using two stacks, the first forward from BOF, the second reversed to EOF, with the cursor position the top of both, as one way to implement this. The second goal after variable length everything should be ease of reference; vi is a cruddy editor to modify multiple areas of a file or several files in concert, and its screen update algorithm is braindead and slug slow, but it knows how to name so many objects important in normal editing tasks quickly and easily (beginning of file, window, paragraph, sentence, line, word, end of ditto, next/previous line, next/previous particular character) in so many operations, that lots of folks won't use anything else because this lets them do tasks quickly. Third is ease of reformatting; it should be _easy_ to reformat, e.g., a series of hanging indent paragraphs after lots of inserts and changes have messed them up, or to go to _and_ _from_ multiple column layout, or to reflow paragraphs with a common prefix and suffix at a common location, like the "/* ...text here... */" comment style of some C programmers. Fourth is ease of tailoring; it should be possible to preload macros, create macros on the fly, save them away, review them, modify them without having to rewrite them, etc. You want the ease of capture of emacs' keystroke record macros, the nesting and multiple easily accessed macros of vi, vi's capability to dump macros out where they can be edited, many editor's ability to load from a .init file, etc. Fifth is safety; there should be frequent backups, even if the user doesn't think of them, based on both time and keystroke count; there should be an undo list that can be accessed in fairly random order, (like vi's '"3P' command), but it should extend back through the whole editing session if storage permits. Sixth is ease of browsing and cross checking and file swapping and window swapping and global changing; I've seen an editor that not only does emacs' multiple horizontal windows into multiple files, but also does the same with vertical windows, swapping from horizontal windows to vertical windows to separate screens at a keystroke, allows editing operations that flow through literally _hundreds_ of files, either interactively or blindly, just as fast as the disk drive could pour data by the cpu, and pulled files into the candidate editing list with a wild card on the file names, the files thereafter accessble by pointing at their names on an instantly accessible separate window or paging series of windows, rather than emacs' tedious buffer name typing or vi's :next walking. Which I guess makes seventh blinding speed. Eighth is localization of effect and focus of display; provide the ability to easily display only the lines with a string in them, or over eighty characters long, like IBM's ISPF's ability to hide all the lines not meeting some search criterion, or emacs' ability to restrict, e.g., changes to columns 20 to 50. Well, that's enough to turn your mind to a different project, ;-), and I've run out of steam. The lesson of all this is that you don't decide on your data structure until you've seen what your requirements ask it to do. Kent, the man from xanth.