On 2020-01-23 11:40:19, Rob Landley wrote: > My own todo list item for a text editor was to make a generic engine I could > implement vi, emacs, nano/edit, and joe (wordstar) keybindings on top of (and > MAYBE share plumbing with less and watch).
Which I did write for you, including sharing plumbing with less. But your inability to read code resulted in you telling me it was too big for you to read. That's a lot of functionality to try to cut down to something small enough for you to read, and it couldn't be done without turning it into a trivial blob of code that didn't actually do anything, which I tried and was also rejected. Possibly coz it didn't actually do anything. The rest of the stuff you mention below would have just made it bigger on that first attempt, so I was doing the simple thing to keep the initial code drop smaller. > I was mostly worried about the > lifetime rules for large text blocks on memory-constrained and nommu systems > where large contiguous allocations become rapidly problematic; I was thinking > copying data into .swp files so I wasn't depending on the original mmapped > file > not to change out from under me but I also wasn't needing to keep a 2 gigabyte > linux-kernel mbox file in memory because I was searching around for that one > email (yeah I should use "less" instead, but it's terrible for this sort of > thing and see above about wanting shared plumbing), and hence the "array of > pointer+length to block-of-text" representation, but not one BIG > array-of-pointer because just the line index tracking on my inbox mbox that > goes > back to 2013 probably takes more memory than my Turtle board has (it's 1.3 > gigs, > wc says just under 20 million lines, so *8 and the box has 256 megs _before_ > you > boot the kernel...). > > It's one of those things where "what counts as pilot error" is a judgement > call > and you need an analysis of usage patterns, and more to the point I needed to > check what the kernel did for MAP_PRIVATE mappings where another process > changes > a part of the file that this process hasn't faulted in yet BUT it's still > covered by the mapping, and maybe madvise comes in here...? Yes only a 64 bit > system could reliably map full files and 32 bit would need its own codepath, > and > nommu would also need its own codepath, and maybe only 64 bit with mmu would > get > properly reliable behavior and the others would just get best effort... > > But I didn't get around to it in time and the decision was taken out of my > hands, so it goes on the "dead idea" pile along with implementing screen. It was your decision to not accept my editor code, then later someone else wrote a vi, which you did accept. It could have shared code with screen as well, which I recall you dropped coz of me "bikeshedding", where I was suggesting features that you could have just said "no" to. > *shrug* Happens. Yeah, shit happens, now I have to make other plans. sigh Though I'd happily give it another chance, spruce it up to work with todays toybox code, merge it with the existing vi code, etc. Just not if you are gonna reject it again. On the other hand, "other plans" means converting it to use Lua as the glue layer between the C editing functions and the various editor key bindings. Something I'd much rather do anyway, though I recall you dropped your initial idea to include Lua in toybox. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
