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

[Jarno Mäkipää]

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 :)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vi.c
Type: text/x-csrc
Size: 36418 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200115/7a771c7e/attachment-0002.c>