Martin Landa wrote: > >> it would be nice to solve it before RC1. Any objections? > > > > Not an objection as such, but FWIW I'd still prefer a solution which > > allows background_color=, as well as bg_color=. > > what does it mean exactly? back_ground_color or ?
That would work but it's undesirable, as "background" itself is a single word. I'm just considering whether there is a viable solution which allows either form without artificially breaking up compound words. One alternative is to extend the option matcher to support an alternative marker character (e.g. "back'ground_color"). An alternative marker could be omitted in some contexts yet shown in others. E.g. the "Usage" section in the --help output might omit it but the longer "Parameters" section could show it (or the description could include a note, e.g. "background may be abbreviated as bg"). Another alternative is capitalisation (e.g. "backGround_color"). Captalisation could be retained in most contexts, as it is less intrusive than an underscore (it used to be common to indicate "accelerator" characters on terminal-based interfaces). Another alternative would be to allow parenthesised abbreviations, e.g. background(bg)_color. The abbreviated form could be shown by --help while the full form could be used in scripts. In each case, the GUI could follow different rules to the command line as to how such option names are presented. A simpler alternative (in terms of implementation) is to just add both options, with the description for one stating that it is an alias for the other. None of this is critical. If people are particularly keen to duck the issue, I'll just forget about it. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
