[alt.religion.computers] vi's or any full-screen editors

xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/28/90)

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.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

ch@dce.ie (Charles Bryant) (01/03/91)

In article <1990Dec27.224407.22905@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>...
>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.

While the undo list is very useful, I think it should not take backups. A
useful editor will be used for system administration and it is extremely
annoying if an editor chews up disc space (e.g. by renaming the old
file). Backups should be done primarily by the system (nightly), and the
user can save every hour or so limiting the loss to a hour's work for a
careful user, a day's work for the careless. I find it is extremely annoying
to be continually doing DEL *.BAK when I use nasty MS-DOS editors which
leave this gunge.
-- 
Charles Bryant (ch@dce.ie)
--
/usr/ch/.signature: Block device required

mcdaniel@adi.com (Tim McDaniel) (01/05/91)

In GNU Emacs, there are two types of backups.

One is the kind of backup ch@dce.ie (Charles Bryant) was thinking of,
the *.BAK kind.  The user can choose the method of backup: single
generation, multiple generations (a la VMS and others), or none at
all.  There are other options: how many generations to keep, whether
to ask before purging extra generations, et cetera.  These backups are
made when the user writes the file for the first time in the editor
session.

The other kind is the "auto save file".  From the Info documentation:
"Emacs saves all the visited files from time to time (based on
counting your keystrokes) without being asked."  GNU Emacs also saves
the visited files when GNU Emacs dies abnormally (killed or hung up
on).  This auto save file is removed when the user writes the file,
and there's never more than one per file, so they don't clutter the
directory.  vi usually has a similar mechanism, saving in
/usr/preserve or /var/preserve or the like, with hooks to send mail
after system crashes or other death.  I find this mechanism very
useful.

--
Tim McDaniel                 Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +1 313 973 1300                        Home phone: +1 313 677 4386
Internet: mcdaniel@adi.com                UUCP: {uunet,sharkey}!amara!mcdaniel