propeller text editor

LucidGuppy

I don't know if this should go into the object exchange but I've come up with a prototype text editor along the lines of vi - I call it pvi. Try it and let me know what you think.

hjkl for navigation
i to enter insert mode
caps_lock to escape insert mode - back into command mode

so far thats all I have - but I would like the editor to output to a buffer onchip somehow, a command to output to a serial port, and some other stuff - I'm still working on that. Right now it only sort of acts like a vga typewriter.

You have to edit vga-text object so it doesn't pop a newline if you are at the last column.

...from VGA_Text.spin

PRI print(c)

  screen[noparse][[/noparse]row * cols + col] := (color << 1 + c & 1) << 10 + $200 + c & $FE
  'got rid of this because I need that last row...

  if ++col > cols
    col--
  'if ++col == cols
  '  newline

Post Edited (LucidGuppy) : 2/25/2007 11:09:37 PM GMT

rokicki

This is great---but I don't understand caps-lock to exit insert mode; why not the bog-standard
escape key?

LucidGuppy

The reason is that when you do a lot of typing going to the esc key can be a little straining. If you look at the key board for which vi was made...

en.wikipedia.org/wiki/Vi

then you see escape was alot closer to the home row. Its the setting I use when I run VIM, and honestly - does anyone use caps lock all that often?

rokicki

Your arguments are valid---but that escape key is hardwired into my brain. I suppose it's not that easy for me to
change, right? Anyway, thanks a lot for this; I have been wondering whether I should try to write it, and it's
nice that someone else got there before me!

LucidGuppy

So I've come up against my first hurdle. Does anyone know how to make a linked list in spin? It would be a great data structure for a text file.

Mike Green

Addresses on the current Propeller are 15 bits and handily fit into a word. Since programs are loaded into RAM from location zero on upwards and the stack is located at the end of the program and works upwards as well, you might allocate space from the top of memory downwards towards zero. You would need to check the stack height and make sure there's some space always left (so your program "accidentally" doesn't scribble over your lists). A routine to return the current stack height looks like:

PRI stackHeight | anyVar
   return @anyVar

If you want to use LISP-like cells, you could use a long for each like

pri car(p)
   return word[noparse][[/noparse]p+2]
pri cdr(p)
   return word[noparse][[/noparse]p]

rokicki

The simplest datastructure I know of for an editor is the "split buffer". You simply have a big buffer (somewhat larger than the text,
sometimes 2x, sometimes 1.5x, whatever works). All text before the cursor position is at the front of the buffer; all text after
the cursor position is at the end of the buffer. When you type, you just insert where the cursor position is in the buffer. When
you move the cursor, you move a chunk of text (however big the move is) from the bottom to the top or vice versa.

It's very simple, wastes no memory, and you only end up doing big memory moves when the user does huge scrolls (to the top or
to the bottom of the file). Its very simplicity makes it very effective for small systems such as the Propeller, where every byte
of code you save is another byte of text file that can be edited.

Of course this can be adapted for files that are paged to disk and so on.

I find it much easier to deal with than linked lists of lines.

Bill Henning

I would actually suggest the following simple format:

var
byte textfile[noparse][[/noparse]MAX_SIZE]
long bytesused

at the start, you initialize bytes used to 0, and fill textfile with 0's

do NOT allow 0's (nulls) as a valid character in any line

every time you add a line, add the length+1 to bytesused

when you delete a line, move everything up, and subtract the deleted length+1 from used bytes

why keep track of used bytes? so you can add to the end quickly; its not really needed, as you can chain along the various lengths to find the end - or any line - quickly

then you just have entries, one after the other, in the following format:

[noparse][[/noparse]line1#bytes] ... text1 ... [noparse][[/noparse]line2#bytes] ... text2 ... .... .... [noparse][[/noparse]lineN#bytes] ... textN ... [noparse][[/noparse]0]

char(8) is already tab, but you can save a LOT of space in the buffer by using the following convention:

char(1..7) = one to seven spaces
char(8) tab = normally 8 spaces
char(9..31) = 9 to 31 spaces

The beauty of the above is that any ammount of indentation will only take one line, and spaces separating arguments or comments will also likely only take one byte. This scheme does limit you to a minimum of one and a maximum of 255 characters per line.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers