[Toybox] [PATCH] vi: mem_block/piece_table part 2

[Rob Landley]

On 1/19/20 3:21 AM, Jarno Mäkipää wrote:
> If this proof to be too complicated, I can redesign with buffer_gap on
> top of this.

I haven't opened the vi review can of worms yet. (I haven't gotten back to the
bc review in months. I'm trying to finish toysh.)

If this is the direction you want to take, I'll apply the patches. (You seemed
unsure so I asked for confirmation, and you didn't confirm.) My only concern is
that Elliott has been patching your stuff, implying he's using your stuff out of
pending. (I'm not yet.)

> But goals should be set up first, if aiming for mostly
> full POSIX vi compliance I have feeling that with buffer gap some
> features like marks are hard to implement, since lines before mark
> changing should not effect mark position.

Rule of thumb here: busybox has had a vi for coming up on 20 years, if it's
still missing a feature it is at least possible to do with out it. (That doesn't
mean you shouldn't do it if you want to, just that a critical mass userbase
hasn't bothered to submit a patch implementing it yet.)

> Also ability to mmap big
> junk of data will be lost, and buffer_gap requires malloc continuous
> region of filesize+few bytes for gap, this system I wrote could
> fallback to loading file in page size  inmemory chunks, without
> modifying any logic.

I remind you that 32 bit mmap maxes out somewhere around 2 gigabytes, depending
on the memory layout of the architecture in question. (Virtual address space
within a process becomes a limiting factor.)

Define "scalability"...

Rob