... > 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. Tony
