[Toybox] vi 'b' command broken

[Rob Landley]

On 10/6/23 03:49, Jarno Mäkipää wrote:
>> > My problem isn't figuring out what the code is doing, my problem is figuring out
>> > what the proper behavior of "vi" is to the various inputs. Alas, "man vim" only
>> > describes command line options and then references "vimtutor" (which doesn't
>> > exist) and says to run the :help command which pulls up a "this is not
>> > installed!" page on debian because an ascii text file the size of the bash man
>> > page (man bash | gzip -9 | wc is 98k) would be a crazy thing to actually install
>> > with your 1.2 megabyte binary.
> 
> On vim there is :help word-motions which opens up motions.txt file.
> Which has some rather cryptic documentation about words, WORDS
> and inclusive and exclusive moves....
> 
> What it does not explain is why and how motions behave differently
> when it is combined with yank, delete, change or no operation....
> 
> Also just by trying motions inside this read protected file on vim.
> why does "b" still execute the movement when giving it file modifying
> command in read protected file but "w" does not....
> 
> some versions of motion.txt and man page for vi can be found online
> https://vimhelp.org/motion.txt.html
> https://man7.org/linux/man-pages/man1/vi.1p.html

As terrible as gnu manuals are, you can generally get the "one big HTML file"
version of them, without external css nonsense so wget the file and view it
locally works even. Linux From Scratch has the same, wget
https://linuxfromscratch.org/lfs/downloads/stable/LFS-BOOK-12.0-NOCHUNKS.html
and there's the whole thing.

No such option here, it's a wiki. And the thing about a wiki is you never know
if you've read it all, or when you're done. The mad hatter's advice "start at
the beginning, and when you get to the end, stop" is not an option with most wikis.

> In my experience busybox vi movements are bit wonky too
> compared to nvi and vim.
> 
> Then after fixing vi_movb() I would test it with:
> ./vi tests/files/utf8/test2.txt

Ironically, that one hasn't got any wide characters. :)

Apparently the widest unicode characters are:

1. ﷽

2. 𒐫

3. 𒈙

4. ⸻

5. ꧅

The first 4 of which xfce's terminal does NOT like. And thunderbird fits the
first one in 3 columns while vim's giving it... 9 I think.

> To ensure utf8 support didn't break.

I just did a utf8 aware version of fold, and blogged a lot about it but haven't
edited and posted those parts yet. tl;dr moving backwards through well-formed
utf8 isn't that hard, but if it's NOT well formed and you're treating illegal
sequences as "literal high byte with width 1", you essentially have to traverse
forward from the start of the line each time because you can't reliably detect
ILLEGAL utf-8 sequences in reverse. (That's part of what makes them illegal.)

(And then printing \b on the terminal turns out to be totally nerfed for
historical reasons, so all the work I did making it actually back up properly to
the start of the previous character even when it was a wide character with
combining characters and getting TABS right... nope, ripped it out again and had
it back up exactly one column each time. Sigh. I had a bitmap of character
starting positions that let me find out where a tab had started, and tabs are
context-dependent variable width! And it worked great! Just... not what the
terminal does, and fold is trying to measure what the terminal would do, so...)

Rob