[Toybox] [PATCH] vi: don't exit on ^C or ^D.
enh
enh at google.com
Fri Jan 17 09:36:15 PST 2020
funnily enough i was reading the POSIX vi documentation the other day
because i was curious to know (a) how much of my personally-known vim
subset is actually in POSIX vi and (b) what's in POSIX vi that i don't
even know about. and it turns out that the POSIX vi docs
[https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html]
are written in terms of the POSIX ex docs
[https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html].
at least once you're past the cursor movement commands :-)
alternatively we could say "we don't actually care about ex, but do
want to have a 'scriptable vi'" and have a mode where toybox vi takes
commands that are just vi commands, not ex commands. that's better in
terms of smaller code, even if it's then a toybox "exclusive".
either sounds like a good idea to me (with me personally leaning
towards "just take vi commands until/unless there's a proven need to
actually be ex compatible, since our only known use case is testing
vi"), but sounds like a decision for rob.
/me wonders how vim testing works. anyone know?
On Fri, Jan 17, 2020 at 12:13 AM Jarno Mäkipää <jmakip87 at gmail.com> wrote:
>
> 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
More information about the Toybox
mailing list