Yeah even tho Rob didint have ex in roadmap, it has started to be more clear that it is needed for testing purposes. Shame that I dont know mostly any of the commands, I only use r, w, s//, absolute jumps with numbers, and few set variables...
ex mode command launcher should be rewritten to parse actual command syntax, as well as most of the vi_main() should be clean up. (this is code that I dont need to touch for now in my text buffer handling rework) -Jarno On Fri, Jan 17, 2020 at 7:47 AM enh <e...@google.com> wrote: > > On Tue, Jan 14, 2020 at 11:05 PM Jarno Mäkipää <jmaki...@gmail.com> wrote: > > > > Hi > > > > On Wed, Jan 15, 2020 at 12:23 AM enh via Toybox > > <toybox@lists.landley.net> wrote: > > > > > > ^D is the opposite of ^U in vi (the ^D/^U pair is the half-screen > > > version of ^F/^B). ^C is unbound in vi. It's pretty surprising for these > > > to cause toybox vi to exit, and it's annoying as long as toybox vi > > > unconditionally exits rather than checks whether there are unsaved > > > modifications! > > > > > > (I'm tempted to implement ^D/^U and ^F/^B, but I don't want to make > > > Jarno's rebase of his in-progress changes any harder.) > > > > Dont worry, if you feel like you need some feature implement it. I can > > always rebase. I send small patch of changes I did few weeks ago, > > rebased on top of this. > > > > I had idea of changing dlist of heap allocated lines into memory > > blocks that can be mmap:ed file and ordered list of offsets that > > describe data in its current state. > > > > // mem_block contains RO data that is either original file as mmap > > // or heap allocated inserted data. mem_blocks are not deleted or modified > > // but instead slice_list is modified on cut operations, and insert > > // allocates new memblock into list and adds slices referencing it. > > // > > struct block_list { > > struct block_list *next, *prev; > > struct mem_block { > > size_t size; > > size_t len; > > enum alloc_flag { > > MMAP, //can be munmap() before exit() > > HEAP, //can be free() before exit() > > STACK, //global or stack perhaps toybuf > > } alloc; > > const char *data; > > } *node; > > } *text; > > > > // slices do not contain actual allocated data but slices of data in > > mem_block > > // when file is first opened it has only one slice. > > // after inserting data into middle new mem_block is allocated for insert > > data > > // and 3 slices are created, where first and last slice are pointing > > to original > > // mem_block with offsets, and middle slice is pointing to newly > > allocated block > > // When deleting, data is not freed but mem_blocks are sliced more > > such way that > > // deleted data left between 2 slices > > struct slice_list { > > struct slice_list *next, *prev; > > struct slice { > > size_t len; > > const char *data; > > } *node; > > } *slices; > > > > So when you open file you have one mem_block and one slice, and when > > you cut line at middle > > you still have one block but 2 slices with hole between them. and > > insert adds new memblock, and adds/modifies 1-3 slices depending on > > position. > > > > This should make opening big files possible, implementing undo history > > will be simpler, few operations will be much simpler, few harder... > > but unfortunately big portion of movements needs to be rewritten. > > > > I had 11hour flight back to europe on Monday with chromebook sitting > > on my lap, and I got about half of the implementation ready. But I > > dont want to send patch before it is usable working state, since this > > thing might already have users :) > > i suspect you and i are the most frequent users :-) > > i am now _building_ vi as part of the Android toybox binary, but i > haven't given it a symlink. so you need to know it's there (simon says > `toybox vi`). i did this because vi is one of the oldest requests we > have, and the computers keep hassling me to do something with the bug. > i was nagged again last week, and finally gave in. i try to use toybox > as much as possible on my own machines at home, but i've mostly been > using Visual Studio Code there lately! > > one thing that did occur to me is that although ex(1) is obsolete, > having an ex mode for toybox vi would make it a lot easier to write > tests. then we wouldn't have to worry so much about regressions... > > > Do you think this is better design than previous one? if you have time > > or interest to take a look I attached my vi.c from my working tree > > > > br > > Jarno > > > > > > > > > > > --- > > > toys/pending/vi.c | 10 +++------- > > > 1 file changed, 3 insertions(+), 7 deletions(-) > > > _______________________________________________ > > > Toybox mailing list > > > Toybox@lists.landley.net > > > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net