> I have, yes. And yes, it's a very small patch. The issue isn't so much
> about the extra code or code maintenance; it's more about extra
> documentation, and avoiding too much clutter of documentation and lists
> of options/rc-commands. I'm not very picky about adding little
> improvements to Wget; I'm a little pickier about adding new options.
> It's not really about this option, it's about a class of options. I'm in
> the unenviable position of having to determine whether small patches
> that add options are sufficiently useful to justify the addition of the
> option. Adding one new option/rc command is not a problem. But when,
> over time, fifty people suggest little patches that offer options with
> small benefits, we've suddenly got fifty new options cluttering up the
> documentation and --help output.

Would it be better, then, if I made it --limit-rate nn% instead of
limit-percent nn?
And made the descrip briefer?

>  If the benefits are such that only a
> handful of people will ever use any of them, then they may not have been
> worth the addition, and I'm probably not doing my job properly. ...

I guess I'd like to see compile-time options so people could make a
tiny version for their embedded system, with most options and all
documentation stripped out, and a huge kitchen-sink all-the-bells
version and complete documentation for the power user version.  I
don't think you have to go to a totally new (plug in) architecture or
make the hard choices.

I know when I put an app into an embedded app, I'd rather not even
have the overhead of the plug-in mechanism, I want it smaller than
that.  And when I'm running the gnu version of something I expect it
to have verbose man pages and lots of double-dash options, that's what
tools like less and grep are for.


Reply via email to