ed text editor

Dave Hein

The ed text editor has been around for 40 years, and it's a standard utility in all Unix and Linux systems. So I decided to write a version of ed for the Prop. I wrote it in C and then ported it to Spin using cspin. spinix contains an early version of ed, but this latest version is more complete and it implements most of the ed commands.

Personally, I find it hard to work with ed because I have to constantly reprint a portion of the eidt buffer to find the correct line to work on. I decided to add a 'V' command to turn on a visualization mode. The visualization mode prints several lines before and after the current line after each command is executed. This makes it much easier to use ed. My ultimate goal is to implement vi on the Prop, and ed provides a basis for some of the commands used in vi.

The attached ZIP file contains the C source code, and the Spin file that was generated from it. There is an ed.exe program that runs in a DOS window under windows. There's also an ed.binary that runs under SpinSim. The ed.spin file can be built to run directly on the Spinneret card, or the SD pin configuration can be changed in clibstub.spin for other Prop boards with an SD card.

Look at the readme.txt and ed.txt files for more information. I would be interested in any comments and feedback on bugs found in the software.

Dave

David Betz

It's great that you ported ed to the Propeller but I find I'm more interested in the cspin tool you used to convert your C code to Spin. Can you tell me more about it? How much of the C language can it handle?

Thanks,
David

Dave Hein

I just posted cspin version 0.66 at http://forums.parallax.com/showthread.php?119342-CSPIN-A-C-to-Spin-Converter/page2 . cspin has quite a few limitation, but it is useful for converting C code that is written within its limits. The known bugs and limitations are listed at the end of the readme.txt file.

jazzed

Cool. Just a curses away from VI

Dave Hein

I looked at curses about a year ago, and did a basic implementation of it. I even tried to write a VI using it, but it became a bit messy. I'm hoping to have a cleaner solution by using ed as the basis. Much of the line editing stuff is just a matter of translating between the VI and ED commands.

The challenge is to ensure that the display stays in sync with the edit buffer, and supporting various terminal types.

Dave Hein

I'm still working on the text editor, but I thought I would post an update. I've implemented the ex version of the line editor, and most of vi. vi currently runs in a dumb terminal mode, where it refreshes the screen after every keypress that causes a change. I'll add support for smarter terminal modes in the future so it doesn't have to update the entire screen.

The attached zip file contains the C and Spin source for ed and vi. The ex editor can be enabled by typing "Q" to exit out of the visual mode in vi. Of course, you can also use ":" to run a single ex command in vi. I use the command "V" instead of "vi" to return back to the visual mode.

The files readme.txt, ed.txt and vi.txt provide information on how to run the programs. There are ed.exe and vi.exe files that run in a DOS window under Windows. The ed.binary and vi.binary are SpinSim executables, and the Spin source is provided to build executables for the Prop hardware.

Cluso99

Congratulations Dave. Prop standalone is becoming a reality

Baggers

Cool ed, well done! great addition to the prop standalone scene.
Just don't do another 190 updates, it could get deadly then! lol

MagIO2

Is it true? You read the whole file into RAM? So, how many RAM is left for the buffer?

Caslan wrote PREDITOR a while back. It's using a GAP-BUFFER which simply stays on SD-card. Depending on the size of the "virtual"-memory available, you can edit huge files this way. Maybe you want to have a look at that editor?

Dave Hein

Yes, the whole file is read into RAM. I think there are about 16,000 bytes in the edit buffer with the SpinSim version, and less in the FDS/FSRW version. It also uses about 10 bytes per line of overhead for the string allocation and linkage, so that reduces the useable space as well. I hope to reduce the overhead down to 6 byter per line in the future.

I'll have to look at PREDITOR to see how the virtual memory is handled. I'm not too concerned about editing big files at this point, but it's certainly something I would like to add.

MagIO2

At least the gap buffer is worth to look at. Using that your memory management will be easy:
All characters in front of the cursor are in front part of the buffer, all characters behind the cursor are at the end of the buffer. The middle is free for editing. Of course you still need some pointers to the beginning of each line, but that's only 2 bytes (for HUB RAM version or 4 bytes for virtual mem version).

I don't remember good enough, but the gap buffer was also discussed in a thread - either in the preditor thread or in it's own.