[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by glynn):

 Replying to [ticket:2409 martinl]:
 > Before releasing G7 we should check all the modules and use the
 standardized options as much as possible. Changing key of an option or a
 flag will be not possible after releasing GRASS 7.0.0.

 It should be safe to change a key provided that the old value is an
 accepted abbreviation for the new value.

 And on that note, if anyone is planning on changing any keys, please

  1. Avoid abbreviating keys; the user can always abbreviate, but they
 can't "unabbreviate".

  2. Place an underscore between distinct words, to increase the set of
 accepted abbreviations (e.g. "line_color" can be abbreviated to "lcol"
 bult "linecolor" can't).

 To recap: if an option key consists of multiple words (sequences of
 characters separated by underscores), the key can be abbreviated to any
 combination of prefixes of the individual words. The first letter of the
 first word must be provided; subsequent words may be omitted entirely.
 Underscores are optional.

 The main limitation is that each word can only be abbreviated to a
 (possibly empty) prefix, so

  1. Compound words cannot have their components abbreviated individually,
 so "background" cannot be abbreviated to "bg". "back_ground" can be
 abbreviated to "background" or "bg", but looks ugly.

  2. Plurals cannot be abbreviated to a plural, so "columns" can be
 abbreviated to "col" but not to "cols". Again, "column_s" could be
 abbreviated to "column_s" or "col" or "cols", but also looks ugly.

 It would be reasonably straightforward to extend the code to support an
 "invisible" word separator, which would behave like underscore but would
 be omitted from the --help output. So if "background" was changed to e.g.
 "back'ground" it would show as "background" in the --help output but could
 be abbreviated to "bg".

 One possible drawback is that if an abbreviation was rejected due to being
 a valid abbreviation for more than option, the conflicting option wouldn't
 necessarily be apparent to the user (due to the separator being hidden).

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:23>
GRASS GIS <http://grass.osgeo.org>