Terminal Text Editor on the Propeller in C/C++
DavidZemon
Posts: 2,973
I believe a few languages on the Propeller have text editors available, but C/C++ is not one of them. It's something I've wanted to do for quite some time but never bothered researching enough to figure it out for myself.
The time has come; I'm going to give it a shot.
I don't really know where to start, but I think the two largest problems will be memory usage and character insertion delays.
I've found a potentially helpful article here: http://electronics.stackexchange.com/questions/53823/text-editing-memory-management. It mentions an external memory module, but I'd love to see an implementation that can be run on the Quickstart - without SD card or SRAM - so I'll be creating this with the goal of a configurable editor, capable of running on a Quickstart as well as utilizing larger amounts of memory when possible.
Any suggestions are more than welcome! Pointers to existing text editors on a microcontroller would be much appreciated as well.
Progress will be track in this thread and this GitHub issue for PropWare.
Commits will go to the feature/26 branch.
The time has come; I'm going to give it a shot.
I don't really know where to start, but I think the two largest problems will be memory usage and character insertion delays.
I've found a potentially helpful article here: http://electronics.stackexchange.com/questions/53823/text-editing-memory-management. It mentions an external memory module, but I'd love to see an implementation that can be run on the Quickstart - without SD card or SRAM - so I'll be creating this with the goal of a configurable editor, capable of running on a Quickstart as well as utilizing larger amounts of memory when possible.
Any suggestions are more than welcome! Pointers to existing text editors on a microcontroller would be much appreciated as well.
Progress will be track in this thread and this GitHub issue for PropWare.
Commits will go to the feature/26 branch.
Comments
Open a terminal and run "cat". Then push arrow keys and escape and function keys and such and see what you get. Note that there will be a ~1 second delay after pushing the escape key, because the terminal is unsure if the escape it just got was a real escape or just part of an escape sequence.
Then, hit ^D or ^C to quit cat, and then type escape, [, A. You'll see that it has the same effect as pressing the up arrow key. Try typing other things you got while in cat (except type escape instead of ^[ ), and it'll have the same effect. You need to do the whole sequence within a second or so for it to work.
Text editors usually store the file being edited as an array or linked list of lines. That way, if you insert a character in the middle of the file, only the rest of that line needs to be shifted over.
Have you tried seeing if there's an ANSI escape sequence for form feed, and trying that instead?
https://en.m.wikipedia.org/wiki/ANSI_escape_code
(A full screen editor would be fantastic, of course, but we're also dealing with a very tiny memory space,)
I wrote the full screen text editor using ANSI/VT-100 escape sequences a very long time ago for my Fidonet BBS project and more recently attempted to rewrite it in C++ but never finished it, I'm attaching the source code in the hope it is useful to you. I wasn't touching it for quite a while but should work decently well, I remember an insidious bug that loses the correct text insertion pointer and never fixed it. The editor was tested on linux only and should work on the linux terminal or any ANSI/VT-100 terminal emulator, supports colors and arrow keys, the text is built in a string variable with '\r' as line separator. There are classes that helps to deal with the input/output interface, terminal is what abstracts the i/o and provides a standard interface, it converts commands to ANSI sequences.
Hope this helps, and feel free to ask, it was quite a long time since I worked with terminal emulations but should remember how they works.
For the curious, the AVATAR emulation handled by the terminal is this http://ftsc.org/docs/fsc-0025.001
My first microcomputer (8080, 16K ram, 2 88KB fdd) ran CPM and a full screen text editor (Magic Wand iirc) so it is doable in a small memory space. SD cards are also much faster than those early 5.25" floppy drives, so that can be used to deal with some of the problems a small memory space creates.
After that, I like the idea of storing data as lines in memory, and I have a dynamically allocated StringBuilder class which I can use as an easy-access buffer. Avoiding dynamic memory allocation would be great, but it's already included in the FatFS class, so I had to give up that dream real quick.
So, once I have a basic, scrollable file viewer ("less" style), I'll move into the editor space.
GitHub link coming soon - need to work out a small kink in the calibration first.
Good to know. I'll stick with propeller-load until I get to the editing a file. For the viewing aspect, asdw and hjkl are working fine.
https://github.com/parallaxinc/PropWare/tree/feature/26
Next up is fixing a usability quirk when moving the cursor up and down at the end of lines that have different lengths. Once that is fixed, I'll start working on edit features I think.
The demo is hardcoded to search for a file named "small.txt" in the root directory of partition 0 of a FAT16/FAT32 SD card mounted on MOSI=24,MISO=22,SCLK=23,CS=25 (ActivityBoard pinout).
I wonder if there's a Propeller standard for a filesystem in EEPROM? A lot of boards do have 64K EEPROMs so there's a small amount of room for storing things, and it would be handy to have a standard for accessing that.
Once I can write files to SD, I plan to create FileReader and FileWriter classes with an EEPROM backing. It'd be great to find an existing standard for an EEPROM filesystem, but I haven't seen one yet (nor have I looked).
I never thought of it until you mentioned it with relation to your new interpreters. It'll be great there!
Right now, code + data size is around 18k, and that's with CMM even. If you're writing a reallllyyyy small file, then sure, lots of room
I'm afraid this is likely reserved for XMM models
I've just added the FileWriter code in, which means that the total code size won't grow much more between now and when it has at least a basic but complete set of features. It is sitting at 21,800 bytes. (Note: it is 23,212 as shown in GitHub - to get 21,800, I removed the HD44780 debugger.)
There is one rather... uh.... glaring bug that I haven't dealt with yet. An empty line will cause undefined behavior. I realized my test file doesn't have any empty lines so this isn't something I bothered coding for yet :P.
The framework for a basic vim-style command prompt has been dropped in place. Right now, all that is supported is ":w", ":wq", ":q" and ":q!". The following keys are also available in "normal" mode:
a/h = Move cursor left
s/j = Move cursor down
d/l = Move cursor right
w/k = Move cursor up
0 = To line start
$ = To line end
g = To file start
G = To file end
All that's left for this very basic editor is fixing the empty line bug, and implementing the "insert mode" which shouldn't be hard since I took Electrodude's suggestion and used a doubly linked list (std::list actually) for the in-memory file buffer.
I am hopeful that the finished product will be around 22-22.5 kB.
No
But again, implementing a super simple eeprom filesystem should get another ~15k back I think
Haven't started looking yet. I'll do a short look, but not hopeful that I'll find anything. For the sake of space, it will probably be extremely simple. I'm thinking no filesystem to start with - just a file with the 32k address hardcoded as the first address, and maybe a 4-byte header for the size and that's it. No name, just a start address of 32k and a 4-byte header. Should make for very small code size.