Since the thread about screen editors in Forth resurfaced (
viewtopic.php?f=9&t=2941), this might be a good time to ask if there is a general ASCII
non--screen based editor in the language. Because I can't seem to find one (see
viewtopic.php?f=9&t=2576 for more screen stuff, for example), and at some point I'm going to need one for the Übersquirrel.
My research and ideas so far, in case other people have the same problem at some point:
The
standard text on the structure of editors seems to be "Data Structures for Text Sequences" by Charles Crowley (
https://www.cs.unm.edu/~crowley/papers/sds.pdf). There is also "The Craft of Text Editing" by Craig A. Finseth (
http://www.finseth.com/craft/) which uses (sigh) EMACS as an example. James Brown has a fantastic introduction to piece chains (
http://www.catch22.net/tuts/piece-chains), one of the most highly recommended storage formats. There is a nice list of literature at
http://texteditors.org/cgi-bin/wiki.pl? ... vision=197 I'm (very) slowly working my way through, as I am through
http://www.guckes.net/vi/mirror/ediger_ ... ditor.html .
What
I would like to have is something that is not screen based (this is the 21. century, and if I can't drive a flying car, at least I don't want to have to work in small units of text any more), will let me write texts in any reasonable length (say, up to the low mega-byte range, since I hope to have enough storage via SPI), and has auto-indent and undo as features (sad but true: Undo is really important in my life).
Based on what I have read so far,
I'm currently thinking it might make more sense to create two editors: One "far future" editor that does all that and includes the kitchen sink, with the data saved in a more efficient but complex struture (piece chains or buffer gap) structures. The other one, the first one, is really small, so small that it fits into the Forth implementation, and really simple, and always there. The "Far Future Forth Editor" (FFFE -- 6502 pun intended) is something I'll be kicking around for a few years before anything happens; I don't have the background yet. The small editor should be a lot easier; I'm thinking of basing it on ed.
Wait! Come back! I can explain!
If you are a Windows person and are wondering about the howls of laughter: ed (
https://en.wikipedia.org/wiki/Ed_(text_editor) ) is a line-based editor that has been included with Unix since 1971. It is really, really primitive, to the point where you have to retype the whole line you are editing, and is terse even for Unix (the error message for everything is "?"). It's main usefulness today is for shell scripting and being a smart-ass: Firing up ed is showing off.
But something ed-like fits the bill here wonderfully. Since it is line-orientated, we don't have to deal with text rendering and the complications of a full screen. We don't
care at all about the screen, because ed was designed for paper teletypes. Also, we now have something we can put on the Forth stack: The line number. So we go from
Code:
2d
to delete line number 2 in ed to
Code:
2 d
in Forth. Spans don't work that way, of course, because we don't know how many elements on the stack are for the editor. So instead of
Code:
1,10d
we could use
Code:
1 10 dd
(note double d). This way, "1,2p" becomes "1 2 pp". Some things need to be changed, of course: ";" for the whole text will have to use the synonym "%", search is going to be difficult, and there is no way in hell I am implementing regular expressions, because this seems to be akin to summoning Cthulhu.
Internally, we structure the text as a doubly linked list of lines (horribly inefficient for longer texts, but it will work and is trivial to implement) and convert those to the actual address in memory with a word such as, well, LINE.
Code:
: line ( u -- addr ) ( ... does stuff ... ) ;
This gives us, say, a cell worth of line numbers. If our cell is 16 bits, we have 64k of lines max, and if each line is 256 byte max, this gives us -- surprise! -- 16 Mb as the theoretical maximal size of the text space, perfect for the 65816 (actual max size will be smaller of course because we have to fit the program etc in somewhere). Once we have the address where the line starts, we can do all sorts of things and can have the file located anywhere in memory, not only at the page or block boundries.
Oh, and since we're using Forth, we can easily beat ed in one feature: Instead of having to retype the whole line for changes (which my experiments with ed now allow me to confidently say sucks beyond belief), we should be able to just load it into the normal input line buffer and manipulate with backspace and delete and whatnot. Luxury!
So, that's the idea unless somebody pulls an editor out of their hats. Feedback and comments most welcome, of course.