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

[enh]

On Tue, Jan 14, 2020 at 11:05 PM Jarno Mäkipää <jmakip87 at gmail.com> wrote:
>
> Hi
>
> On Wed, Jan 15, 2020 at 12:23 AM enh via Toybox
> <toybox at 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 at lists.landley.net
> > http://lists.landley.net/listinfo.cgi/toybox-landley.net