2022-05-06 08:27:21 You know, I'd been thinking I'd write this block editor (which I want to support variable length lines this time, with newline chars) so that it edited the block data in place. Now that I have this ability to call the READ piece of expect on fixed length strings, though, I think the best strategy is to unpack the block into an array of fixed length lines, use that, and pack it back up when I'm done. 2022-05-06 08:27:57 Almost all of the "hard" work is canned in READ now - no point in re-doing all of that. 2022-05-06 08:29:45 All I really need now is that unpack, something to display some range of lines at a chosen location on the screen, and a wrapper for READ that moves the cursor up and down. And any other functions I want to add (insert line, split and merge lines, etc.) 2022-05-06 08:31:13 READ is already set up to return on keystrokes it doesn't understand. It leaves its state on the stack; it should be easy enough to adjust that state to a different line in the array, move the cursor, and recall READ on that new line. 2022-05-06 08:34:27 I'll want to be able to start editing the new line on a column other than the first one, and that will require a scan to properly sync the insert point with the cursor position. 2022-05-06 08:34:56 Scan and count off that many columns, accounting for multi-byte chars. 2022-05-06 08:35:44 But I'll only need to do that once - READ already knows now how to keep that sync. 2022-05-06 08:36:30 Easiest way may be to just loop over the cursor right word I already have "column" times. 2022-05-06 08:37:51 If I want to handle moving from the far right of a long line to the end of a short line, I'll have to address that anew. A simple loop would just leave the cursor in the middle of all the spaces to the right of the short line's content. 2022-05-06 08:42:07 At what point is it easier to just not have a block editor :P 2022-05-06 08:42:29 The block editor advantage is you can write a decent block editor in like 20-30 lines of forth 2022-05-06 08:42:55 The disadvantage is it's a block editor 2022-05-06 08:43:42 You can write a very simple word to load a variable-length line file into blocks in memory (and another to go back), and then you can use your block editor to edit normal files 2022-05-06 08:43:58 I've actually enjoyed using block editing, but in this case that was a bit of a misnomer. I'll probably start that way, but ultimately I want an editor that can edit across block boundaries. 2022-05-06 08:44:20 I do intend to have a file system. But I don't have it YET, and I want to start actually using the system itself for further development. 2022-05-06 08:44:38 Oh... just have a 'file' be an array of bytes somewhere 2022-05-06 08:44:47 I've thought a fair bit about that - when I set up this array of lines, I will probably have a block field associated with each line. 2022-05-06 08:44:48 You don't need a proper filesystem yet 2022-05-06 08:45:07 Good old tape filesystems were just a glorified linked list, one directory 2022-05-06 08:45:25 Yeah - I know what you're saying. 2022-05-06 08:45:36 Or just keep an array in memory (and maybe write it to disk in a bespoke word for now) 2022-05-06 08:45:37 There are ways I can plan in that direction without actually having it all yet. 2022-05-06 08:45:51 Plan to make the transition to actually using a file system smooth. 2022-05-06 08:46:06 That's not the part of it I'm really focused on this morning, though. 2022-05-06 08:46:30 I was thinking about adding file stuff to my ZX Spectrum Forth, it would have just used arrays somewhere and allowed writing to tape with special words 2022-05-06 08:46:56 And you can best believe the 'filesystem' would have been a linked list with names 2022-05-06 08:47:16 Like the tape format actually 2022-05-06 08:47:37 There's not really anything that says I couldn't unpack more than one block into this array, and pack it back into more than one when done. 2022-05-06 08:48:21 I'm mostly thinking at the moment about the best way to leverage READ. 2022-05-06 08:49:10 I probably actually don't want to use it in the new "fixed line length" mode - I probably just want to unpack into long line buffers, so that I can make lines longer, but still treat them as having a non-full size. 2022-05-06 08:49:22 Then when I do that loop over cursor right, it will stop at the end of that line. 2022-05-06 08:49:38 But the "max" field will be the long value, so I can grow it all the way to the length of that buffer. 2022-05-06 08:50:43 I really need a block # or #'s for the unpack. 2022-05-06 08:53:51 One thing I haven't considered yet - I want to be able to embed ansi color and attribute stuff in these files, and I'm going to have to figure out how to adjust that properly when I move a whole line. Moving down a line is easier - I could just scan the bytes in between and emit the discovered ansi sequences. 2022-05-06 08:53:58 Moving back up a line - that's harder. 2022-05-06 08:54:21 those things make incremental changes. 2022-05-06 08:54:38 I don't have an easy solution in mind yet. 2022-05-06 08:54:56 IMO a good editor just prints a special visual representation 2022-05-06 08:55:04 Like ed's l function 2022-05-06 08:55:27 I see why you could like that; I may wind up there, but it isn't what I've envisioned. 2022-05-06 08:55:52 I don't see the point of having that support in a source editor if I don't see the results on the screen. 2022-05-06 08:56:15 Because that's really the primary place I'll look at the code - it's not like I'm preparing a document for display somewhere else. 2022-05-06 08:56:45 Because there's a difference between representing the *content* of a file, and showing a terminal after it's been affected by the incoming data 2022-05-06 08:57:14 I know, but in a source editor the whole point of having that support is to see its results in the source. 2022-05-06 08:57:34 I get what you're saying though - like when you edit a LaTeX file. 2022-05-06 08:58:33 I'm thinking more along the lines of the way Chuck uses colors in colorForth. I'm not planning for the compiler to make any use of this - in fact it already ignores ANSI stuff. 2022-05-06 08:59:12 But think about when you have syntax highlighting. I know there's nothing in the content itself driving that - "smarts" drive it - but the purpose is to have the source convey information to you as a result. 2022-05-06 08:59:38 I'm kind of straddling that fence - I want to actually explicitly control the colors, but I want to see them the way you do with syntax highlighting. 2022-05-06 09:00:03 vimwiki compromises. 2022-05-06 09:00:17 It displays the lines you're not editing, but renders the line you are editing. 2022-05-06 09:00:33 Wrong word. It shows explicit characters for the line you're on. 2022-05-06 09:00:40 Do you actually want colour in your syntax? 2022-05-06 09:00:42 It "renders" them if you're not on the line. 2022-05-06 09:00:49 I don't know - I may. 2022-05-06 09:00:57 Haven't decided for sure. 2022-05-06 09:01:15 Being able to control it would let me experiment with things and see how I feel about them. 2022-05-06 09:01:32 That vimwiki compromise may be a reasonable way to go. 2022-05-06 09:02:44 I definitely would only add colour codes (whether ANSI escapes or otherwise) if I wanted colour as a feature of the interpreter 2022-05-06 09:02:55 And I don't think colour is actually a very good feature, all due respect 2022-05-06 09:03:10 But anyway, you see my point about moving up a line. I'd have to "undo" the attribute changes that occur in between the do points. 2022-05-06 09:03:15 And I wouldn't use ANSI escapes, they're not compact at all 2022-05-06 09:03:24 I know, right? 2022-05-06 09:03:26 I'd probably use some usually unused ASCII control characters 2022-05-06 09:03:32 I find the whole scheme slightly obscene. 2022-05-06 09:03:45 It was appropriate for transmission, not storage 2022-05-06 09:04:00 That's a good point. 2022-05-06 09:04:39 The advantage of having them is that it's easy to list a block. Just type it - they work. 2022-05-06 09:04:48 I'd probably use start-of-file, etc, for colours 2022-05-06 09:05:44 Not quite sure what you mean - do you mean like have a little "style table" at the beginning? 2022-05-06 09:05:46 It's easy to modify EMIT to recognise single-byte colour codes 2022-05-06 09:05:58 Sure, but my EMIT isn't fundamental. 2022-05-06 09:06:16 My TYPE is fundamental, so I can punch a string out with a single syscall. 2022-05-06 09:06:24 EMIT is a "1 TYPE" 2022-05-06 09:06:46 One char - it can be a UTF8 char. 2022-05-06 09:06:52 I mean like "Start of Heading", "End of Heading" etc, those are ASCII control characters 2022-05-06 09:07:18 You don't need a lot of colours, just 'neutral', 'green', 'red', 'blue' etc or whatever chuck uses 2022-05-06 09:08:00 Just use a single byte to switch colour, then EMIT can trivially handle it differently when you want interactive (i.e. not binary transmission) output 2022-05-06 09:08:07 Yes, that's very true. Can't tell the difference in subtle color changes anyway. 2022-05-06 09:08:42 But I do think colours are no good. Colour blind people are quite common, I get why Chuck doesn't care but I still think it's a valid complaint 2022-05-06 09:09:07 I'm actually using colors in the system output now. I have error messages red, "all is well" prompts green. My typing is white, and executed output is blue. 2022-05-06 09:09:15 It's sort of pleasant to work with. 2022-05-06 09:10:09 Nothing I do in the editor will really "conflict" with that, because the running editor would be inside any of those changes. 2022-05-06 09:10:45 I already think those four are all the colors I want. 2022-05-06 09:10:52 Just have words that change colours 2022-05-06 09:10:57 Like you have CR to go to next line 2022-05-06 09:10:58 I do. 2022-05-06 09:11:13 You don't need a special encoding then 2022-05-06 09:11:25 Sounds super unnecessary to try and add this into editor 2022-05-06 09:11:34 But I still need the block content to tell me what color it is. 2022-05-06 09:11:54 What do you mean? You want colour-coded block listing? 2022-05-06 09:11:55 I see what you're saying - I don't need to be bound by the ansi sequences themselves. 2022-05-06 09:12:14 Yes - if I list a block I want to see the colors I put in it. 2022-05-06 09:12:34 What are the colours used for? Is it systematic? 2022-05-06 09:13:03 Well, it will be, but I don't know how yet. I want to tinker with ideas. Like, I may decide I like italicizing comments or something like that. 2022-05-06 09:13:27 Look, we're arguing over what my goal should be - I'm trying to think about how to impement my goal. 2022-05-06 09:15:31 I've been trying to just let those sequences handle doing what they do, but there are some difficulties with that in an editor environment. Moving backward is just one of them. 2022-05-06 09:16:04 As you pointed out, those sequences were designed for tranmission - they weren't designed to let you "re-wind" them. 2022-05-06 09:16:28 I may indeed want to do it differently for that reason. 2022-05-06 09:17:03 The only brute force option I could see would be to move the cursor to its new place and then reset all the attributes and emit every ansi sequence in the content up to there. 2022-05-06 09:17:13 That would work, but it's not a solution I find very pretty. 2022-05-06 09:17:45 But you know, as fast as this stuff is it might work just ine. 2022-05-06 09:17:47 fine 2022-05-06 09:17:57 I just think it's ugly. 2022-05-06 09:18:43 Another solution - a better one - is just to have a convention that colors and attributes reset at the beginning of each line. 2022-05-06 09:19:02 Then this will just take care of itself, because I print the whole line after every keystroke in READ anyway. 2022-05-06 09:21:36 That at least scales well, because lines are always going to be manageable length, no matter how large a file gets. 2022-05-06 09:28:51 There a Forth library for 256 color? All the libraries I've seen just do 8.. 2022-05-06 09:31:46 You could always add escape sequences yourself. 2022-05-06 09:32:12 That's what I was going to do, but I don't like reinventing the wheel :) 2022-05-06 09:32:16 Yeah, you can do full 24-bit RGB control if you want to. 2022-05-06 09:32:38 I actually do, sometimes. Depends on what I think of the existing wheels. 2022-05-06 09:57:46 where can i find forth code and idioms? my goal is to write a simple scanner - numbers, operators, and optionally identifiers 2022-05-06 10:00:46 my forth is gforth, if that matters. and i'm currently reading http://home.iae.nl/users/mhx/crenshaw/chapter1/tutor1.html 2022-05-06 10:04:48 lagash: Reinventing the wheel is standard in Forth, nothing wrong with that 2022-05-06 10:05:18 I actually hate it when I'm told not to 'reinvent the wheel' when I write something simple because I don't want someone else's IP in my code, like a simple JSON parser 2022-05-06 10:05:28 Yeah, it's highly advised by the Great One himself. :-) 2022-05-06 10:05:43 i wish we didnt use bloody json 2022-05-06 10:06:38 Encapsulate it in XML so it's better. 2022-05-06 10:09:54 eris: Not to try to defend json, but I am curious about your reasons for disliking it. 2022-05-06 10:12:13 too verbose 2022-05-06 10:13:11 no comment 2022-05-06 10:13:40 JSON is less verbose than XML, but more verbose than bespoke formats 2022-05-06 10:13:41 *no comments 2022-05-06 10:13:53 I know, let's use S-exps! :) 2022-05-06 10:14:14 I don't mind JSON at all, it's easy to parse, XML is a shitshow 2022-05-06 10:14:15 well specified numbers 2022-05-06 10:17:16 was playing around more with 64FORTH last night on C64 VICE emulator. Learned how to draw sprites and save/load them from disk 2022-05-06 10:19:47 interesting how C64 sprites work: https://www.c64-wiki.com/wiki/Sprite 2022-05-06 10:27:01 also XML is SEXP with funny braces 2022-05-06 10:39:10 ....is it? 2022-05-06 10:39:27 how do you express def 2022-05-06 10:39:43 (f (:a "bc") "def") 2022-05-06 10:40:08 odd 2022-05-06 10:41:03 and def ? 2022-05-06 10:41:52 same thing, minus the keywords 2022-05-06 10:43:00 I haven't actually looked into this, but I've got a feeling it's not possible to recognize an ansi sequence coming backwards through it, is it? 2022-05-06 10:43:12 I mean, until you get all the way to the escape. 2022-05-06 10:43:26 You can recognize unicode either direction. 2022-05-06 10:43:53 As veltas pointed out, the ansi stuff was for transmission - forward only. 2022-05-06 10:44:43 I'm fine printing things - like I said earlier I print the whole string every time anyway - always forward. But for cursor motion I've got to be able to jump either way across those things. 2022-05-06 10:46:11 Right now "cursor left" moves the cursor left with a print sequence and then moves the insert point, and it recognizes utf8, so it will move more than one byte if necessary. 2022-05-06 10:46:34 I may have to replace that with "go home and cursor right one less than where I was." 2022-05-06 10:50:05 What you're doing just smells like something nobody should bother with 2022-05-06 10:51:05 Sometimes we lose sight of the fact Forth is meant to make things easy and simple 2022-05-06 11:18:34 Could be. 2022-05-06 11:18:37 We'll see. 2022-05-06 11:19:10 And if so, then I'll know and won't be wondering if I should have tried it. This is more of a hobby for me than anything. 2022-05-06 11:19:17 So I do whatever I feel like. 2022-05-06 11:19:59 It may turn out non-useful. But I need to KNOW that, for myself. 2022-05-06 11:24:36 To some extent I already swallowed some non-simplicity when I supported the utf8 chars. That broke the ASCII one byte, one character simplicity. But that was a very deliberate and conscious decision, based on wanting to explore APL-like ideas in my Forth. I know there are languages that do APL-like things without all those symbols, but I *like* the terse nature that arises from using them, so I went there. 2022-05-06 11:24:38 Now that took that step, another source of deviation from one byte one char isn't as painful as it would be as a first step. 2022-05-06 11:25:23 It is a little bit - because of this inability to recognize the sequences from the right. But otherwise it folds in fairly well. 2022-05-06 11:27:15 I can easily see that in the end I might decide that all I want is a syntax highlighting protocol, which would be imposed without any "triggering content" in the source. If that happens I may pull some of this back out, or just not use it. 2022-05-06 11:27:58 I don't understand why you need to change how input works to use UTF-8 in words 2022-05-06 11:28:41 Oh for the cursor, okay that makes sense 2022-05-06 11:28:42 I haven't really changed "how input works." For just "compiling code" I don't need to change anything - the compiler just takes those bytes like all others. 2022-05-06 11:28:52 Yes that's what I was thinking 2022-05-06 11:29:11 But I'm managing my keyboard input completely myself, and when you cursor move across a UTF8 char you have to adjust the insert point by more than one. 2022-05-06 11:29:24 Yes 2022-05-06 11:29:35 When I'm in a string read from the keyboard, I have an array of bytes, with an insert point, and the cursor has a location on the screen. 2022-05-06 11:29:39 Those have to be kept in sync. 2022-05-06 11:29:53 With ascii that's easy - they're the same thing. 2022-05-06 11:30:01 But they're not with utf8. 2022-05-06 11:30:03 Unicode cursor stuff is quite complicated unfortunately 2022-05-06 11:30:27 But it's necessary, not even for maths but just for other locales 2022-05-06 11:30:44 When I print the string what shows up on the screen is fine - the OS just handles it. But I have to keep up with where I am in my own data structures. 2022-05-06 11:30:55 Personally I would not bother with APL symbols, I'd use an ASCIIfied version 2022-05-06 11:31:11 I want something easy to type 2022-05-06 11:31:19 As I said, I explicitly don't want to do that. I like the terse characters - I regard them as a strength of APL. 2022-05-06 11:31:23 And characters I'm used to looking at 2022-05-06 11:32:25 Well give us some screenshots of demos 2022-05-06 11:32:33 When you do some APL-style stuff in forth 2022-05-06 11:32:38 I'm interested to see what you can do with that 2022-05-06 11:34:24 When I have some I will. :-) 2022-05-06 11:34:46 But anyway, there's no reason to necessarily expect the two of us to have all the same tastes in things. 2022-05-06 11:35:37 Anyway, the utf8 stuff is done and in. That all works. So I'm looking at the ansi stuff as an evolution from there - not an evolution from ure ASCII. 2022-05-06 11:35:41 pure 2022-05-06 11:35:52 I recall a Windows service that was utf-8, but it switched mid-stream to utf-16 for errors 2022-05-06 11:35:54 The one byte/one char is already gone. 2022-05-06 11:36:51 That was definitely the tedious part of the work - I was using a single variable for cursor position and insert point, and I had to split that. 2022-05-06 11:37:30 But I still took advantage of being able to recognize a utf8 item coming from the right. 2022-05-06 11:41:54 KipIngram: K uses terse characters too! 2022-05-06 11:45:05 :-) I haven't looked at any of the others yet. I do have the impression that some of the derviatives added some nice ideas. 2022-05-06 11:45:15 Some of which APL later absorbed itself. 2022-05-06 11:45:43 Or maybe Dyalog did - I know nothing about to what extent APL has been "standardized." 2022-05-06 11:46:53 also, do you need to do utf8? cant you do 21bit utf? 2022-05-06 11:47:31 uhh, unicode 2022-05-06 12:05:50 Well, I could have. Then every character would be three bytes, right? 2022-05-06 12:06:19 The way I've done it I only pay the overhead where I actually use the extended characters - ASCII continues to be ASCII. 2022-05-06 12:06:42 And that part is done - it really wasn't that bad getting it in. Overall just a few hours work. 2022-05-06 12:06:55 Spread out over a couple of days. 2022-05-06 12:16:02 maybe you can find some use for RIGHT ANGLE WITH DOWNWARDS ZIGZAG ARROW 2022-05-06 12:18:57 we tried to find one for that in APL 2022-05-06 12:19:08 > I know nothing about to what extent APL has been "standardized." 2022-05-06 12:19:24 one standard exists for a variant of APL that everyone but GNU has abandoned 2022-05-06 12:19:35 Dyalog is weighed down by immense amounts of legacy 2022-05-06 12:48:21 i wonder how hard it is to implement APL 2022-05-06 12:48:33 it seems more on the forth side of easy to parse 2022-05-06 12:50:53 APL itself? 2022-05-06 12:50:53 not really 2022-05-06 12:51:23 an APL? easier to parse 2022-05-06 12:51:23 APL itself has pitfalls in parsing 2022-05-06 12:51:24 and APL itself cannot be parsed without executing the program 2022-05-06 13:53:37 MrMobius - that was my impression to, based just on how arithmetically rigorous it is. But that's a far cry from "having tried it," so I tend to trust eris. 2022-05-06 13:53:55 s/to/too/ 2022-05-06 13:55:07 And it makes sense to me that parsing might require execution.