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

[Jarno Mäkipää]

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 <enh at google.com> wrote:
>
> 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