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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net