On Monday 18 August 2014 14:11:48 you wrote: > On Mon, Aug 18, 2014 at 1:07 PM, tito <farmat...@tiscali.it> wrote: > > > On Monday 18 August 2014 10:50:18 Laszlo Papp wrote: > > > On Mon, Aug 18, 2014 at 9:45 AM, walter harms <wha...@bfs.de> wrote: > > > > > > > > > > > > > > > Am 17.08.2014 11:22, schrieb Denys Vlasenko: > > > > > On Fri, Aug 15, 2014 at 3:11 PM, <lp...@archlinux.us> wrote: > > > > > > > > > >> Applets are defining the help display text on their own, and it is > > > > >> different for different applets. > > > > >> > > > > > > > > > > I don't see any obvious way to make it easier without significant > > bloat. > > > > > > > > > > Pass a list of options, parameters and their explanations to a > > function > > > > > which builds help text? This will likely be bigger than the help text > > > > > (many pointers to small strings results in pointers taking > > > > > almost the same amount of space than strings!) > > > > > > > > > > Even if you manage to avoid _that_ bloat somehow, > > > > > you can't bzip2-compress tiny bits of text. > > > > > We currently bzip2-compress our help text as one big blob, > > > > > with BIG savings in size - more than 50% > > > > > > > > > > And then you discover that some applets really want a bit > > > > > of customization to the way how options are explained. > > > > > > > > > > > > > > > > > > Would that something for busybox.net/TODO section ? > > > > "Verify that help text and option are in sync" > > > > > > > > > > Would what for TODO? It should not never really be validated by a human > > in > > > the first place. An applet author should just fill in the metadata. All > > the > > > rest should be automatically handled IMHO. Otherwise, it is error-prone, > > > will likely only cause the chaos that the applets have now with regards > > to > > > this. > > > > > > > HI, > > if you would like to take a look at busybox/docs/BusyBox.html > > there are displayed all help texts, most of them look ok to me, > > a few could need some fixes, so lets list them. It would be > > also useful to write down exactly to what standards we want > > to enforce. KISS. > > > > I am not sure what you are looking at. They are completely inconsistent. > They use at least three different schema for just the options, let alone > others:
Which one do you prefer? This could be ok for indipendent options. > * [-fb] This could be ok for options that depend on each other or eventually [-f[b]] > * [-f] [b] THis could be ok for the short usage form FEATURE_VERBOSE_USAGE [=n] as there are applets that have 20 or more options and [qwertyuiopasdfghjklzxcvbnm] is not better than simple [options]. > * [OPTIONS] > If that looks OK to you, then I guess you do not like unified and > simplified outputs. I just would like to point out that you rarely look at more than a help text at a time and this is maybe the because nobody complained so far. > That is definitely not any KISS you are referring to. I > would advise you to have a closer look than what you have apparently done. > > But let us imagine that for a second that what you are saying is true: it > is still extremely cumbersome, error-prone, and nonsensical IMHO to write > the help output yourself, either a rewrite for an existing or creating it > for a new one. Most of the help texts out there are written exactly that way (by hand) and surprisingly the people out are able to get this job done in a coherent way.. > The applet author ought to be responsible only for the > metadata, and no any more boilerplate. > > I think you just simply do not see the forest from the trees here, or the > communication has just severely failed to bring the attention to the actual > issue. > I feel you would like to add even more trees by adding a machinery for a relatively simple task that has to deal with a lot of exceptions and later on needs to be maintained by somebody, This is about fixing a simple help text, just write down how you want it and add it to CodingStyle.txt. Ciao, Tito _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
