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 to delete line number 2 in ed to 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 we could use (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. 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.

Line editing is just a mindset. You can certainly write significant code that way. And, if you want to print 10 or even 20 lines of context, you won't have to wait for a dot-matrix to print it out for you. Or a teletype.

So: go for it!

When it comes to line-based editors, I've always been a fan of TECO (Digital Equipment) but ed or edlin would do the trick. Have you considered adapting the "Starting Forth" line-based screen editor to files? Everybody knows it, and it's very "forthy"

The "Screen editor design" thread has morphed into a catch-all thread about several design aspects of PETTIL, because I didn't want thread proliferation and I didn't know how to change the subject line.

(A thread's subject, or title, is just the same as the first post's - so edit your head post to retitle your thread.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

You might find some useful ideas from GPascal for Commodore 64 which included a line based editor.
http://www.lyonlabs.org/commodore/onreq ... Manual.pdf

Wow, that is impressive. The HP-71 was the successor to the HP-41, right? By the time I could afford any of those, the were history ... but boy did I drool over them. Still have my HP-15C, but it can't do anything like that.

About the hot keys -- that's a definite yes for the FFFE (life-long vim user here), but I was thinking of something more primitive for the ed-like editor so it can more easily scripted like ed inside other programs. That doesn't mean you can't have hot keys as well, but I'm going to start simple and then see.

@theGSman, thanks for the link!

The HP-42 was the successor to the HP-41. The HP-71 was an unrelated product, a handheld computer running BASIC.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

So it took a bit longer than expected, but today I am happy to present "Fed", an ed-inspired line editor in Forth (https://github.com/scotws/Fed). It only has a few commands so far - basically, what is a, c, d, i, n, p, r, w in ed - but on the positive side, it's stripped version without comments is 3.2 Kb in size. I don't want to go over 4 Kb, so there is a bit more room for something like j.

Obviously this is still somewhat untested, so be careful and don't use it for your tax returns.

Nice coding there. The comments and stack diagrams are first class.

One question: Were you planning to have all the editor commands be part of a EDIT or EDITOR dictionary or do you have to avoid creating words that conflict with the editor words?

Why thank you! My idea was to leave all that up to whoever uses this in their Forth instead of forcing it on the user one way or another -- Tali Forth for instance is so primitive that it doesn't even have vocabularies. For a larger Forth, personally I'd make EDITOR point to Fed somehow.

EDIT: "vocabularies", not "dictionaries". Thanks to Garth, see below.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Argh, yes, of course, vocabularies. Need more sleep. I'd be very interested in that article, BTW, since this is one of the things that I'm going to try to include in Liara Forth this time.

The problem with screen editors in Forth is not the screen per se, it's the environment.

Text editors rely on a stream of text (nominally), but the original screens is based on the underlying block model of disk I/O. Simply, the early Forth model doesn't have a filesystem to rely upon, with which it can use to easily managed arbitrary, named, Blobs-o-bytes (that just so happen to be text files).

The original Fig implementations had a "line oriented" Forth screen editor. Back in the day, with Val-Forth on the Atari, that was a Full Screen editor (but Val-Forth screens were 512 byte screens, rather than 1K screens, since that worked better with a 40x25 display). It was able to leverage the E: device (which is the screen editor that can be manipulated with the arrow keys that comes in the Atari ROM), so they pretty much get an editor almost for free.

So, the problem with a non-screen Forth editor isn't the editor, it's the underlying storage. The Fig line editor plus the few disk blocks being buffered gives you a mostly functional editor in < 1K of code, with an overhead of only a 1-2K for buffers that the system uses already. So that editor is almost free.

The other fundamental issue with editors, outside of how to represent the files in memory, is paging large files from memory to disk. Nowadays, this is rarely an issue. But it most certainly was back in the day. I remember fighting TECO and having to manually page our code in and out as we swapped from one part of the file to another. Buffer management was a science unto itself that distinguished good editors from bad ones.

Of course, the Fig screen editor doesn't suffer this problem, rather it embraces it. It certainly can be clunky to use, especially today where we don't think twice about cutting and pasting megabytes of text from document to document. But old school Forth guys will call out how the screen model enforces the "keep them small" and "endless refactoring" idioms of Forth coding.

With a little more memory, a cross reference to word definitions is not difficult. Then you add shadow screens for documentation. It's pretty powerful in a very small editor.

The fiddly-ness kicks in when you want to insert screens, but the --> word does a lot to fix that. You can also make a crude "table of contents" with a couple of screens to show how sequences of blocks are allocated. Just manage those by hand.

Pygmy Forth does the cross referencing and shadow screens -- it's a pretty nice screen based Forth, but it works in the expanded memory of a PC vs the small world of something like a 6502. But on a 65816, it could be really nice.

But going back, the original, minimal screen model with the Fig line editor -- it's a decent amount of capability in almost no code.