On 2/3/23 13:29, Jarno Mäkipää wrote: > On Fri, Feb 3, 2023 at 6:09 PM Rob Landley <r...@landley.net> wrote: >> >> On 2/1/23 15:18, enh via Toybox wrote: >> > heh, to be clear: i wasn't "dissing" drive-by patching. it accounts >> > for at least 80% of my entire career :-) >> >> https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/linux-patches/ >> >> > i use the term just to acknowledge that for some things -- like this >> > -- there isn't anyone else who's actually working on the thing full >> > time, which is my personal rationale for wanting "the simplest thing >> > that could possibly work", and why my definition of "simple" is >> > something like "the most easily understood by an average programmer >> > who hasn't seen this particular code before". >> >> I mean to take custody of this thing this year. I'm trying to get to a 1.0 >> release, which means (among other things) emptying the pending directory >> entirely. > > Well it might be complete rewrite when you get to it, but hopefully > its better than starting from nothing :)
Indeed. >> I do admit vi is something I haven't worked out how to regression test yet, >> but >> dogfooding it would presumably cover a multitude of sins. (I do edit both my >> code and my blog in vi...) > > I was trying to code with toybox vi, but I seem to be too blind and I > need syntax hilighting. And I really dont wanna implement it here. Its > not in scope of this. Syntax highlighting that's built _in_, no. But a syntax highlight thingy based on regexes sounds like it might make sense? Although telling it that bash has if/then/fi stages starts to sound sed-ish and I'd want to pace and stare at trees quite a bit to come up with an actual idea there. The point would be vi.c remaining simple and the /etc/vi/c.hi and /etc/vi/bash.hi files it imported would have all the brains... But THAT can of worms belongs AFTER toysh. And after other cleanup/rewrite of the basic vi functionality. And I still need an awk for a bunch of build scripts... >> > (and, yes, in addition to the open() error -- which at least led to a >> > small simplification of the code -- i've shot myself in the foot by >> > forgetting that there even are vi tests, not running them, and >> > breaking them with my recent commit, which i'll have to do something >> > about before i can sync to AOSP. >> >> Huh, I forgot that too. :) >> >> Ok, "vi -s" is a good start... > > "vi -s" is ok for text edit operation testing, and tests with weird > files and such. But visual testing I think using manually with > different terminal emulators is only way. I have a vague idea for automated pty master/slave tests, but it's another can of worms I dowanna open just now, and it's the kind of thing you have to design as you go. Start with a vague idea and let the implementation guide you or you're just gonna wind up ripping it all out and starting over repeatedly. (I mean, that's likely to happen twice _anyway_, but the "I dunno what I'm doing until I've done it" smells strong with this one...) > At some point I forked ST to print out escape codes for me when I was > trying to debug some drawing issues. But fortunately currently drawing > is just one function (monsterous that needs to be rewritten for sure). > > I think that most work is actually going through all movement commands > corner cases, things like cw and dw has different movement. > > And parsing required ex and vi commands better way. But I was hoping > you can use something from bash implementation perhaps. I haven't opened the command history editing can of worms yet (come close a couple times but bug report du jour took precedence), but I've been poking at the getline() buffer collating recently. (Today's blog entry at https://landley.net/notes-2023.html#03-02-2023 was like 1/3 about that. And another 1/3 ranting at glibc being tanted with mandatory obeisance to Stallman or you don't get symbols, and bionic facepalmingly _also_ wanting #ifdef STALLMAN to give me the pipe2 syscall wrapper's prototype even though musl and freebsd don't. But I need a portability.h thingy doing #ifdef/#define O_DIRECT 0 anyway because macos hasn't got it, and I should be able to pipe() and then fcntl(F_GETFL/F_SETFL) so I've got a workaround for the prototype thing...) Anyway, finally figured out what to implement but it's after midnight and I'm (surprisingly!) on a day schedule at the moment. (There was an ice storm.) The usual, Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
