On Sat, Feb 4, 2023 at 8:23 AM Rob Landley <r...@landley.net> wrote: > > 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...
Sounds smart way to do it. Perhaps something like file containing lists of regexp followed by escape codes user wants for each regex if I understood you correctly. If highlighting would be kept line based, it could be simple enough to just write modified version of crunch_str that would accept array of regex + escapes instead of char * + escape. Then vi.c would not need to know much/anything about highlighting. Ofc this would not support code block highlight such as showing if whole function is commented with c comment blocks /* */ This would reduce need of processing full file/buffer to only selected lines that have been drawn into screen. > > 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 -Jarno _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
