[Toybox] vi 'b' command broken

[Rob Landley]

On 10/5/23 15:03, enh wrote:
>> Ah. command0 is the number before the command, command1 is the number after the
>> command. If you ":5d" it deletes the 5th line. If you ":d5" it deletes 5 lines
>> starting from the current one. Presumably if you ":5d5"... yup, it deletes 5
>> lines starting from line 5.
> 
> ah, that's why i was confused by two counts --- i didn't know there
> was a postfix count too. (i'd wondered whether they were just bad
> names for the two numbers in something like :1,5s/// instead!)

Except here it's multiplying them together and I'm going "we're talking about
typing b in vi mode but the count0 and count1 are for colon commands and this
implies that if you do :2b3" it will move back 6 words and is that what vim
and/or busybox vi do" and I have NOT tested it because NOT GOING DOWN RATHOLE
RIGHT NOW.

(I just tried it. :2b3 said "invalid range". NOT ASKING FURTHER.)

>> Before I wrote my own "sed" I didn't really know how to use sed. Before I wrote
>> my own "find" I know like 1/3 of the things find could do.
> 
> judging by some of the sed in the toybox build, you know more sed than
> macOS' sed does :-)

I tend to write stuff that exercises things I've implemented so "toybox can
build toybox" is a reasonable test of its capability. And then you go through
and remove the stuff mksh can't run. :)

>> And if you run it and :help it says not implemented. So yay. It does, for some
>> reason, have :features which says:
>>
>> These features are available:
>>         Pattern searches with / and ?
>>         Last command repeat with .
>>         Line marking with 'x
>>         Named buffers with "x
>>         Some colon mode commands with :
>>         Settable options with ":set"
>>         Signal catching- ^C
>>         Job suspend and resume with ^Z
>>         Adapt to window re-sizes
>>
>> For whatever help that is.
> 
> "some colon mode commands" is especially good. i mean, why even bother
> saying anything if you're going to be that vague?

Because busybox's config has 18 sub-features for vi, and the :features lists the
ones you've switched on. Except it doesn't give the config symbols, it gives a
very brief description of what the symbol enables, which is not the same as the
help text for the symbol.

My previous email was ranting about how getting help text right is hard, but I'm
trying to use every part of the buffalo here. Busybox has:

https://git.busybox.net/busybox/tree/editors/vi.c?h=1_36_stable#n29

Which you can ONLY get through menuconfig's help. It is not available at
runtime. (And not phrased to be useful at runtime either.) And thus they reproduce:

https://git.busybox.net/busybox/tree/editors/vi.c?h=1_36_stable#n560

Which is the feature list above, as an #ifdef staircase. No it's not all 18
features. And (this is the SAD) bit, when I left busybox the policy for
defconfig was "the maximum sane configuration" and the defconfig build I just
did has CONFIG_FEATURE_VI_8BIT and CONFIG_FEATURE_VI_REGEX_SEARCH switched off.
Neither of which requires anything that isn't in libc. I.E. this is a policy at
least partially based on opinion and aesthetic preferences. (There's a certain
unavoidable amount of that in what to include, but having a second layer of
what's enabled by default? If it's not enabled by default it gets less testing...)

My reaction to all this (I.E. busybox->toybox design decisions, some of which
occurred over time after I left) was:

1) If I'm writing help text, I'm going to have it be available at runtime too,
and going to try to write one good version that explains what the command does.

2) Having a zillion sub-features in a command is NUTS because "how does toybox
vi behave" should have ONE ANSWER, and their current vi has 2^18=262144 possible
answers. I'm aware they're trying to write a tiny one you can fit into a tiny
space but what subset of their userbase is actually doing that kind of
micromanagement, and how much of an improvement is this config system over
making it easy to just delete or if (0) out of chunks of the code?

Reading busybox code is still a dozen times easier than reading gnu code, but
over the years I've moved on quite a bit from their design philosophy...

>> I've already checked in the basic lib/passwd.c rewrite but still need to migrate
>> the md5/sha1/sha256/sha3 plumbing into lib where it's internally reusable
> 
> speaking of which, https://www.phoronix.com/news/Mold-2.2-Linker
> mentioned blake-3. and funnily enough, if i'm understanding
> https://reviews.llvm.org/D121531 correctly, i think llvm's lld
> silently uses blake-3 if you ask for md5 (which i think is the
> default; certainly it's what Android is using). nothing actionable
> here, i only bring it up because of the recent "is anyone using this?"
> conversation. ("yes, quite heavily, but not in a way that would
> warrant adding a toy".)

The algorithm's perkolating around, but I'm still kinda waiting for a user who
needs it to show up. (Or for it to get an SHA number.)

Rob