[GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk:

Glynn Clements glynn at gclements.plus.com
Tue Dec 30 13:35:03 PST 2014


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 <glynn at gclements.plus.com>


More information about the grass-dev mailing list