[Toybox] [PATCH] vi: don't exit on ^C or ^D.

[David Seikel]

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.