Add an ed-based line editor about taliforth2 HOT 7 CLOSED

How is Tali going to handle the vocabularies (to use a FIG-Forth term) for the editor and the assembler? I'm assuming we don't want all of the editor and assembler words in the dictionary at startup - it would be a mess! Speaking of messes, I looked at the ANS solution to vocabularies with word lists and it didn't make me excited at all. It would be nice to be able to bring the editor and assembler vocabularies in and out of the dictionary and to be able to use both at the same time.

I'm assuming the editor will be editing a string in RAM? eg. you might put a starting address and length (max length) on the stack and then use the ed words to modify the multiline contents in that string? Blocks are much easier to deal with because the lines are at fixes offsets and the rest is just filled with spaces, but I could envision some words that would seek out newlines in the text to determine where lines start and end.

from taliforth2.

I have a starting version of L ( list ) written. My current version of L takes the string address and count, then the line numbers for a range you want to list. If you don't provide the starting or ending line number, it fills them in with the current line (kept in a variable.) I'm thinking I want to store the address and count in variables (perhaps filled in when you invoke the editor on your string) because the entire stack is lost when you make a mistake (eg. use an unknown word.)

For editing, I'm thinking I need to keep track of the length of the contents separately from the length of the memory reserved for the string. I also need to check to see if EVALUATE properly handles newlines (I'm currently using linefeed (ASCII character 10) for newlines). I'm assuming one use of the editor is to edit strings for evaluation.

Do you think it makes sense to use a null character to mark the end of the current contents? or perhaps a variable should be used? When the editor is "closed", everything from the end of the data to the end of the reserved memory would be overwritten with blanks.

I also was giving some thought to loading and unloading the editor. I was thinking that there would be a word like load-ed to get it into memory, and it would evaluate a string with the editor words in it, which would set a marker first. This would mean that you would need to make your strings BEFORE loading the editor, but then you could edit your string and use something like Q (the "quit" command would be the marker) to remove it when you didn't need it anymore. You'd just have to be careful not to add anything to the dictionary that you don't mind being blown away when you quit (and unload) the editor.

I think that's reasonable for the editor, but I don't think it works for the assembler, where you are likely to compile into the dictionary. Having separate word lists that can be turned on/off isn't sounding so bad. I don't know if it make sense to do full ANS word lists, or just have a couple of variables like ed-loaded and asm-loaded that find-name would consult.

from taliforth2.

I had actually once written an ed-like editor in Forth -- https://github.com/scotws/Fed -- which was absolutely horrible, because it recreated the ed commands as Forth words. This should be as close to ed as possible, which would require some primitive form of parsing -- nothing fancy that ends up with an AST, of course, but a small subset of ed that does pretty much what it is supposed to.

Internally, I was thinking of simple single-linked lists, since I doubt anybody is going to rewrite War and Peace on this sort of machine. Each line would be three cells, one with a pointer to the next line (with a 0000 to terminate), one cell for the address of the string and the next for the length of the string.

As for calling the editor, how about a generic

: edit ( addr u -- ) ... 

so the user can quickly choose which editor to use? I don't like block-based editors, but other people do, so Tali should probably offer that option (see http://kestrelcomputer.github.io/kestrel/2016/03/29/vibe-2.2 for a Forth example, and https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Blocks.html for some background on Gforth and blocks) the way we potentially allow an easy switch to a different disassembler. That way, we can include one be default, and with some simple editing the block people can do their thing as well.

I hadn't really thought about the vocabulary, because I share your lack of excitement for the ANSI solution. Honestly I hadn't considered anything beyond some MARKER that the editor would call at the beginning and use when done to dump the editor commands afterwards to save space.

from taliforth2.

I didn't make it super far into writing I (for insert) when I realized that I'm going about it wrong - my word was getting to be way too many lines long and there was way too much stack wrangling. A block editor might be more my speed, and I have incentive as I want to add I2C storage to my SBC.

I'm going to abandon my attempt at the ed-based editor and investigate the block based editor. While I did learn quite a bit, I don't think I ended up with anything useful.

from taliforth2.

See if we need to wait for #126 for this.

from taliforth2.

Life is going to be a lot easier if we create the word BUFFER: before the editor works. Will open an issue for this.

from taliforth2.

First version added, though very primitive.

from taliforth2.