2022-04-03 00:39:21 So, back in the DOS ANSI.SYS days, I want to think there was a code that let you set the left margin. 2022-04-03 00:39:46 I.e., you could cause a line feed to take you to the next line, any selected column - this basically preserved anything to the left of that. 2022-04-03 00:39:51 Does that still exist? 2022-04-03 00:40:24 I want to have two edit buffers, side by side (two different blocks). 2022-04-03 00:41:06 With that code, I could set the starting point depending on what buffer I'm in, and then just blast a whole range of lines out with one shot, instead of having to print by lines with a cursor position adjust in between. 2022-04-03 00:41:40 I can simulate this by embedding cursor position commands at the end of each line in the edit buffer, but it's more work. 2022-04-03 00:44:47 Also, does anyone know what character set I need to use if I want those nice "box drawing characters" that DOS used to sport (in the 128-255 code range). 2022-04-03 00:50:00 Oh, nice... 2022-04-03 00:50:03 for i in 6a 6b 6c 6d 6e 71 74 75 76 77 78; do printf "0x$i \x$i \x1b(0\x$i\x1b(B\n"; done 2022-04-03 00:58:25 Looks like (0x(B prints that │ character. 2022-04-03 00:58:51 So those will be easy enough to code up. 2022-04-03 01:21:58 108 box 113 box 113 box 107 box ┌──┐ ok 2022-04-03 01:22:01 120 box space space 120 box │ │ ok 2022-04-03 01:22:03 109 box 113 box 113 box 106 box └──┘ ok 2022-04-03 02:00:01 The main idea I have here is that the initial step will grab the block and split it by lines into an array of line buffers. These will be space or null padded and long enough that I can always write the first "panel width" bytes of it to the starting location of that line on the screen, and it will look right. 2022-04-03 02:01:30 There might be embedded color and attribute strings - the terminal will handle that. I don't intend to have lines longer than my panel width, but if I did, then the print might start from column not equal to 1 and would only print at most "panel width" bytes. This will get done starting from the top row that's in the panel to the bottom row in the panel. 2022-04-03 02:01:50 While editing I will generally modify characters in place on the screen and in the buffer. 2022-04-03 02:06:03 Only splitting, merging, adding, or deleting lines will necessitate a full redraw in real time. 2022-04-03 02:06:38 Line 1 will be used to indicate block numbers and bytes currently consumed from the blocks. Line two will be a horizontal divider line using those blocks. Line three will be top line of buffers. 2022-04-03 02:07:38 From there down to "last line minus two" will be buffer lines. Next to last liine will be a divider, and last line will be reserved for a command line, like in vim. Or I may copy vim and let the buffers go all the way to the bottom and "appear" a command line when it's needed. 2022-04-03 02:08:18 The command line, of course, will just acquire a string from me and use the interpreter to evaluate it. 2022-04-03 02:08:39 When I exit, all the lines will be glued back together into the block buffer. 2022-04-03 02:09:25 The way I have my console screen laid out now the right hand side has 131 columns all the way from top to bottom - that's my "big window." 2022-04-03 02:10:11 That will allow two 64-wide buffers to sit side-by-side with a column of │ chars down the middle, with spaces on either side of it. 2022-04-03 02:11:11 On the last system I used 64-char fixed width lines, with space padding - I chose a screen font size that let that editor display all 64 lines of those blocks on the screen at once, so there was never any scrolling in either direction. 2022-04-03 02:11:40 There's nothing about this concept that precludes wideer than 64 lines, but I don't plan on using them. 2022-04-03 02:12:42 Line count, though, could go beyond 64 and there's no way in advance to know how far, so vertical scrolling will be a must. Plus in the future I'll likely extend this to handle files, which will mean drawing content from more than one block for each side. 2022-04-03 02:14:33 But, as far as I can tell at the moment, there will never be more than a single block boundary on screen (on one side) at a time, under any circumstances. 2022-04-03 02:15:15 So I if I design to support having two "current blocks" associated with each side, with the boundary on any row, I should be "future covered." 2022-04-03 09:23:43 Ok, I'm hoping for some counsel here. I'm torn between two approaches to this editor. One would be what I described last night - unpacking the whole block into a linked list of lines, all ready to edit, and packing them back up into the block when done. The other would be to have just one line buffer - extract whatever line I'm on from the buffer while I'm editing it, and when I leave that line re-insert 2022-04-03 09:23:46 it and extract the new line. 2022-04-03 09:24:38 The latter is clearly more memory efficient, won't involve any linked list management, etc. - but it would require more "moving around" of the contents of the block, sometimes in between individual keystrokes. 2022-04-03 09:24:54 I like that latter approach, but I worry it might not be fast enough. 2022-04-03 09:25:03 Of course I could just try it and see. 2022-04-03 09:25:21 But I'm still interested in what you guys think, especially if you've wrestled with this yourself. 2022-04-03 09:26:37 Last time I worked directly with the buffer, but I was treating the lines as independent of one another - inserting a character in a line implied removing a space from the end part of the line, so that it always stayed 64 chars. So I didn't have to move the entire buffer "below" that point unless I inserted or deleted a line. 2022-04-03 14:05:55 Ok, the first way's going to be fast enough as far as I can tell. I implemented the first part of it. When I load the block I create an array of pointers into it, designating the start of each lines. Wrote some code to iterate through all the lines (until one starts with a 0 byte) and printing them in suitable locations on the screen. My test block only has 9 lines, but I can do the whole job of printing 2022-04-03 14:05:57 that, border around the box included, a hundred thousand times in right at 40 seconds. So that's 0.4 msec per iteration. Say I have 7x that on the screen in a "full block. That's 3 msec to paint a full buffer - that's too fast to notice. 2022-04-03 14:11:13 By the way, I did that counted repetition a different way from usual - I wrote this: 2022-04-03 14:11:16 : times r> dup 4+ >r h@ base.h @ + swap 2022-04-03 14:11:19 : (times) >r >r r@ exec r> r> 1- .0>me drop drop ; 2022-04-03 14:11:31 and then :test times print ; 2022-04-03 14:11:38 100000 test 2022-04-03 14:12:18 The nice about the way it's written is that the data stack is clear of any "residue" of the repetition process during EXECUTE, so the word being repeated is free to operate on the stack. 2022-04-03 14:13:32 The first parts gets the next cfa pointed to by the return stack item and replaces it with a nudged forward value. Second part is the actual repeat. 2022-04-03 17:16:55 The other day people were discussing the fact that we've optimised single-core and not parallel. Well I think a "CPU" is a single-threaded route in general 2022-04-03 17:17:15 Maybe FPGAs or just electronics/chips can be truly parallel 2022-04-03 17:17:25 I'll believe this until someone corrects me 2022-04-03 17:18:08 But I personally don't mind the single-threadedness of CPUs and how multiprocessing is more difficult, I like the model 2022-04-03 18:16:38 It's certainly an easy model to grok. 2022-04-03 18:24:16 And as long as it meets your needs there's no reason not to use it. But it's evident at this point there there is a limit to how far performance can be pushed with that model - parallelism is the way past that barrier. 2022-04-03 18:24:34 Won't be needed for everything though - may well never be needed for anything you ever need to do. 2022-04-03 18:25:01 I don't think we should throw out sequential thinking and programming - we've gotten really good at it. 2022-04-03 18:25:46 Maybe parallelism only takes root in the "supercomputer domain." 2022-04-03 18:42:18 I mean, methodically solving a problem step by single step is a fundamental life skill - programming older CPUs captures that and drives it home. 2022-04-03 18:43:03 On the other hand, electronic circuits (as you mentioned) and also things like running a large company or a military operation etc. etc. have many threads of activity that have to coordinate, so that model also shows up outside of computing. 2022-04-03 19:11:05 So this is interesting. 2022-04-03 19:12:06 The "official way" of using ANSI sequences to get the screen dimensions is to 1) save cursor position, 2) set cursor somewhere big, like row 1000, column 1000, 3) read cursor position, 4) restore cursor position. 2022-04-03 19:12:48 In step 3, you send a "get cursor position" sequence and then use read the response from stdin. 2022-04-03 19:13:12 In Forth, with KEY; it has the row and column in it as base 10 integers. 2022-04-03 19:13:20 Ok, no problem - I wrote that up and it worked. 2022-04-03 19:13:33 However, it does NOT work from a load screen. 2022-04-03 19:14:29 I don't fully understand why yet - it's like it's not running KEY properly like it's supposed to. 2022-04-03 19:15:51 Oh, wait - never mind. I'm actually sure it would work from a load screen. That's not actually what I'm doing. I'm copy pasting this code from vim. So that does make total sense. 2022-04-03 19:16:20 My whole paste is in the keyboard buffer ahead of those characters, so it's not reading those - it's reading the next chars of input. 2022-04-03 19:16:34 Ok - fine. I'll just hard code them for now and change it when I start LOADING the code. 2022-04-03 20:05:15 This really has the display side of the job pretty much done - all that's left now is keystroke processing and the command line (which should be easy since I'm just going to EXPECT it and pass it to the interpreter). 2022-04-03 21:04:55 So, after someone mentioned it a day or two ago I went and read up a little on Erlang. It's an interesting model. 2022-04-03 21:13:14 I kind of like the "let it crash" mentality. Anything that lowers the effort that needs to be put into error handling is good.