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ää <jmaki...@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(-) _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net