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

[Jarno Mäkipää]

If this proof to be too complicated, I can redesign with buffer_gap on
top of this. 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. 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.

Then again if aiming for just very minimal editor in (1000-2000loc)
buffer gap might be the way to go.

But I think next focus should be to write ability to do automated
tests. I think using ex commands dont help since they are mostly line
based, so difficult utf8 cases cant be tested.

I think simple solution is just to supply moves as parameter line/file and exit.
vi inputfile -test 5G\nw\nd2w\n:wq\n

-Jarno

On Sun, Jan 19, 2020 at 10:39 AM Jarno Mäkipää <jmakip87 at gmail.com> wrote:
>
> After this patch functionality should be around the same as with
> linelist
>
> Implement more proper file write:
> file is saved to .swp, blocks are unloaded, file permissions are copied,
> and atomic rename is called, block is reloaded
> chmod some defaults(rw-r--r--) if original file could not be fstat (does
> not exist)
>
> Reimplement simple search /string
>
> fix w, b, e moves
> fix 1G
> fix moving cur_right on zalgo text
>
> Count line numbers for drawing purposes (placeholder needs rewrite)
> (If file is too big, gives up) this needs rework.
>
> cleanup Make function for searching offset slice
> cleanup Make local functions static
> ---
>  toys/pending/vi.c | 361 ++++++++++++++++++++++++++++------------------
>  1 file changed, 218 insertions(+), 143 deletions(-)