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

#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 neteler):

Replying to [comment:159 wenzeslaus]:
> However, in case of `d.shade`, I'm actually suggesting:
>
> {{{
> d.shade color=elevation shade=slope
> }}}
>
> which more describes the meaning of the input rasters for me.

Sounds good to me.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:161&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

For record: in r63704 has been renamed 'volume' options in `r.color`,
`r3.colors` and `v.colors` to `raster_3d`.

I would suggest do the same with `m.nviz.image`, any objections?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:162&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:158 hellik]:

{{{
> stream_rast Name for output raster map with unique stream ids
}}}

changed to `stream_raster` in r63706

{{{
> stream_vect Name for output vector map with unique stream ids
}}}

changed to `stream_vector` in r63706

{{{
> transmissivity_singleway Name of single-way transmissivity raster
map [0.0-1.0]
> transmissivitysingleway Name of the single-way atmospheric
transmissivitymap [-]
}}}

`transmissivitysingleway` changed to `transmissivity_singleway` in r63709

{{{
> walk_coeff Coefficients for walking energy formula parameters a,b,c,d
>
> transport_coeff Name of transport capacity coefficient raster map
[s]
>
> topidxclass Topographic index class
> topidxstats Name of topographic index statistics file
>
> tiledimension The dimensions of the tiles used in the output raster3d
map (XxYxZ or default: 16x16x8)
> tilesize The maximum tile size in kilo bytes. Default is 32KB.
>
> swatershed Name for output sink-watershed raster map
}}}

no opinion here

{{{
> start_rast Name of starting raster points map
}}}

changed to `start_raster` in r63711

{{{
> stab Set the flow stabilizing scheme (full or exponential upwinding).
> staend The user defined values that indicate start, intermediate
and end status in the indicator output space time raster dataset
>
> sourceproj Source projection
> sourcescale Conversion factor from units to meters in source
projection
>
> soilheatflux Name of instantaneous soil heat flux raster map [W/m2]
> Name of soil heat flux raster map [W/m2]
> soilmoisture Name for output root zone soil moisture raster map
}}}

no opinion here

{{{
> slope_tol Slope tolerance that defines a 'flat' surface (degrees)
}}}

changed to `slope_tolerance` in r63713

{{{
> segmax Maximum length of segment on network
> Maximum number of points in a segment
>
> savehistory Text file in which to save history
> savesettings Name for output file where to save current settings
>
> rgbmaps Three (R,G,B) 3D raster maps to create RGB values
[redmap,greenmap,bluemap]
> Three (r,g,b) raster maps to create RGB values
[redmap,greenmap,bluemap]
>
>
> productname Name of MODIS product type
>
> pclay Name of soil clay fraction raster map [0.0-1.0]
>
> pcurvature Name for output profile curvature map (or fxx)
> Name for output profile curvature raster map
>
> outtopidxstats Name for output topographic index statistics file
}}}

no opinion here

{{{
> nwalkers Number of walkers
> Number of walkers, default is twice the number of
cells
>
> num_partitions Read the input files in this number of chunks
>
> npartitions Number of partitions
}}}

`num_partitions` changed to `npartitions` (to follow other similar options
like `nwalkers`, `npoints` and others - number of ...)

{{{
> ncolumn Node cost column
> Node cost column (number)
}}}

This is more significant issue, all of v.net modules uses various
shortened options

{{{
> min_area Minimum size of area to be imported (square units)
> min_size Minimum number of pixels in a class
> min_slope Minimum slope value (in percent) for which aspect is
computed
>
> mcurvature Name for output mean curvature 3D raster map
> Name for output mean curvature map (or fxy)
> Name for output mean curvature raster map
>
> loadhistory Text file from which to load history
> loadsettings Name of input file to read settings from
> localutctime Name of time of satellite overpass raster map [local time
in UTC]
>
> insol_time Output insolation time raster map [h] (mode 2 only)
>
> infil Name of runoff infiltration rate raster map [mm/hr]
> infil_value Runoff infiltration rate unique value [mm/hr]
> infile Input file with one input raster map name and data point
position per line, field separator between name and sample point is |
> init_time Initial time for current simulation (0) (min)
>
> gcurvature Name for output Gaussian curvature 3D raster map
>
> beam_rad Output beam irradiance [W.m-2] (mode 1) or irradiation
raster map [Wh.m-2.day-1] (mode 2)
}}}

no opinion here

{{{
> afcolumn Arc forward/both direction(s) cost column (number)
>
> acolumn Arcs' cost column (for both directions)
>
>
> abcolumn Arc backward direction cost column (number)
> EXPERIMENTAL: Arc backward direction cost column
(number)
}}}

see my note about `v.net` modules above

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:163&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:163 martinl]:
{{{
> > ncolumn Node cost column
> > Node cost column (number)
}}}
>
> This is more significant issue, all of v.net modules uses various
shortened options

{{{
> > afcolumn Arc forward/both direction(s) cost column (number)
> >
> > acolumn Arcs' cost column (for both directions)
> >
> >
> > abcolumn Arc backward direction cost column (number)
> > EXPERIMENTAL: Arc backward direction cost column
(number)
}}}
>
> see my note about `v.net` modules above

I went though v.net modules and renamed

{{{
alayer -> arc_layer
nlayer -> node_layer
type -> arc_type
ccats -> center_cats
ncolumn -> node_column
afcolumn -> arc_column
abcolumn -> arc_backward_column
tcats -> terminal_cats
nsp -> npoints
coordinate -> coordinates
vis -> visibility
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:164&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:164 martinl]:

> I went though v.net modules and renamed

see r63730

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:165&gt;
GRASS GIS <http://grass.osgeo.org>

#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 cmbarton):

Replying to [comment:164 martinl]:
> Replying to [comment:163 martinl]:
> {{{
> > > ncolumn Node cost column
> > > Node cost column (number)
> }}}
> >
> > This is more significant issue, all of v.net modules uses various
shortened options
>
> {{{
> > > afcolumn Arc forward/both direction(s) cost column (number)
> > >
> > > acolumn Arcs' cost column (for both directions)
> > >
> > >
> > > abcolumn Arc backward direction cost column (number)
> > > EXPERIMENTAL: Arc backward direction cost column
(number)
> }}}
> >
> > see my note about `v.net` modules above
>
> I went though v.net modules and renamed
>
> {{{
> alayer -> arc_layer
> nlayer -> node_layer
> type -> arc_type
> ccats -> center_cats
> ncolumn -> node_column
> afcolumn -> arc_column
> abcolumn -> arc_backward_column
> tcats -> terminal_cats
> nsp -> npoints
> coordinate -> coordinates
> vis -> visibility
> }}}

Thanks much. These are a great improvement. IIRC, the vector overlay/query
modules could use something similar. Perhaps already done as I've had no
time to investigate at the end of semester here. This is a lot of work I
realize but greatly appreciated.

Michael

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:166&gt;
GRASS GIS <http://grass.osgeo.org>

#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 wenzeslaus):

Replying to [comment:161 neteler]:
> Replying to [comment:159 wenzeslaus]:
> > However, in case of `d.shade`, I'm actually suggesting:
> >
> > {{{
> > d.shade color=elevation shade=slope
> > }}}
> >
> > which more describes the meaning of the input rasters for me.
>
> Sounds good to me.

Done in r63741. Should be backported soon I guess.

I also extended [source:grass/trunk/lib/gis/renamed_options
renamed_options] with G7:r.his and G7:d.his in r63740 but with d.shade
because also the module was renamed.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:167&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:167 wenzeslaus]:
> Done in r63741. Should be backported soon I guess.
>
> I also extended [source:grass/trunk/lib/gis/renamed_options
renamed_options] with G7:r.his and G7:d.his in r63740 but with d.shade
because also the module was renamed.

it seems to be OK to me, please backport.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:168&gt;
GRASS GIS <http://grass.osgeo.org>

#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 [comment:146 neteler]:

> It would be very helpful to advertise the candidates here, like:
{{{
g.region rast=rastermap -p
ERROR: g.region: Sorry, <rast=> is ambiguous. Choices: <raster>,
<raster_3d>
}}}
>
> Could that be implemented?

Yes (although as part of a change which would also remove the ambiguity in
that case).

My intention is to modify the code which calls match_option()
(set_option() and check_string()) to record which options are matched. If
one option is a prefix of all of the others, the string will be considered
to unambiguously match that option. If the match is ambiguous, we now have
a list of which options matched, which can be used for the error message.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:169&gt;
GRASS GIS <http://grass.osgeo.org>

#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 [comment:169 glynn]:

> My intention is to modify the code which calls match_option()
(set_option() and check_string()) to record which options are matched. If
one option is a prefix of all of the others, the string will be considered
to unambiguously match that option. If the match is ambiguous, we now have
a list of which options matched, which can be used for the error message.

This change is implemented in r63744.

Currently, an ambiguous match for an option key lists the matches, but an
ambiguous match for a value (opt->options) doesn't (as the error message
is generated by the caller).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:170&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:170 glynn]:

> This change is implemented in r63744.
>
> Currently, an ambiguous match for an option key lists the matches, but
an ambiguous match for a value (opt->options) doesn't (as the error
message is generated by the caller).

cool! It open doors to rename options line `n,s,e,w` to
`north,south,east,west` in `g.region`. The shorted options will continue
to work...

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:171&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:171 martinl]:

> cool! It open doors to rename options line `n,s,e,w` to
`north,south,east,west` in `g.region`. The shorted options will continue
to work...

sorry, I was wrong, attempt

{{{
           north Value for the northern edge
           south Value for the southern edge
            east Value for the eastern edge
            west Value for the western edge
             top Value for the top edge
          bottom Value for the bottom edge
            rows Number of rows in the new region
            cols Number of columns in the new region
      resolution 2D grid resolution (north-south and east-west)
   resolution_3d 3D grid resolution (north-south, east-west and top-
bottom)
   ns_resolution North-south 2D grid resolution
   ew_resolution East-west 2D grid resolution
   tb_resolution Top-bottom 3D grid resolution
}}}

Command

{{{
g.region n=1 s=0 e=1 w=0 t=1 b=0 res=1 res3=1 nsres=1 ewres=1 tbres=1
}}}

fails with

{{{
ERROR: g.region: Sorry, <n=> is ambiguous
ERROR: Option <north=> matches
ERROR: Option <ns_resolution=> matches
ERROR: g.region: Sorry, <s=> is ambiguous
ERROR: Option <south=> matches
ERROR: Option <save=> matches
ERROR: g.region: Sorry, <e=> is ambiguous
ERROR: Option <east=> matches
ERROR: Option <ew_resolution=> matches
ERROR: g.region: Sorry, <t=> is ambiguous
ERROR: Option <top=> matches
ERROR: Option <tb_resolution=> matches
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:172&gt;
GRASS GIS <http://grass.osgeo.org>

#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 martinl):

Replying to [comment:171 martinl]:
> Replying to [comment:170 glynn]:
>
> > This change is implemented in r63744.
> >
> > Currently, an ambiguous match for an option key lists the matches, but
an ambiguous match for a value (opt->options) doesn't (as the error
message is generated by the caller).
>
> cool!

I meant that

{{{
g.region rast=elevation
}}}

will work, which is very good news.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:173&gt;
GRASS GIS <http://grass.osgeo.org>

#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 wenzeslaus):

Replying to [comment:168 martinl]:
> Replying to [comment:167 wenzeslaus]:
> > Done in r63741. Should be backported soon I guess.
> >
> > I also extended [source:grass/trunk/lib/gis/renamed_options
renamed_options] with G7:r.his and G7:d.his in r63740 but with d.shade
because also the module was renamed.
>
> it seems to be OK to me, please backport.

Backported in r63755.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:174&gt;
GRASS GIS <http://grass.osgeo.org>

#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 wenzeslaus):

If I understand correctly, we still want to use full option names for
GRASS code (and perhaps documentation) and to advise it for user scripts.
In this case it would be good to have a way to proof that the full option
names are used, something like an environmental variable
`GRASS_FULL_OPTION_NAMES` which would switch off the advanced
word/character matching and `renamed_options` so that only full names
would be considered as valid.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:175&gt;
GRASS GIS <http://grass.osgeo.org>

#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 [comment:175 wenzeslaus]:
> If I understand correctly, we still want to use full option names for
GRASS code (and perhaps documentation) and to advise it for user scripts.
Indeed.

The main issues I see with abbreviations are:

  1. Searching for use of an option name (grep, Ctrl+F, etc) will miss
abbreviations.

  2. Abbreviations make code harder to understand for people who aren't
fluent in English.

> In this case it would be good to have a way to proof that the full
option names are used, something like an environmental variable
`GRASS_FULL_OPTION_NAMES` which would switch off the advanced
word/character matching and `renamed_options` so that only full names
would be considered as valid.

r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to anything)
and the found string isn't an exact match for the given string.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:176&gt;
GRASS GIS <http://grass.osgeo.org>

#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 neteler):

I have taken liberty to backport the current parser state in r63772 +
r63774.

This including an attempt to document GRASS_FULL_OPTION_NAMES in r63773,
please improve.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:177&gt;
GRASS GIS <http://grass.osgeo.org>

#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 wenzeslaus):

Replying to [comment:176 glynn]:
> Replying to [comment:175 wenzeslaus]:
> > If I understand correctly, we still want to use full option names for
GRASS code (and perhaps documentation) and to advise it for user scripts.
> Indeed.
>
> The main issues I see with abbreviations are:
>
> 1. Searching for use of an option name (grep, Ctrl+F, etc) will miss
abbreviations.
>
> 2. Abbreviations make code harder to understand for people who aren't
fluent in English.
>
> > In this case it would be good to have a way to proof that the full
option names are used, something like an environmental variable
`GRASS_FULL_OPTION_NAMES` which would switch off the advanced
word/character matching and `renamed_options` so that only full names
would be considered as valid.
>
> r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
anything) and the found string isn't an exact match for the given string.

Thanks that's good but wouldn't be better to do just the `strcmp`
comparison (to be faster) and fail (with fatal error) which would show
these things in tests (errors are clearly visible, warning must be
searched for in the output). I think the primary use-case for
`GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
options and then it is just more effective to fail. The secondary use-
case, I can think of, is making parsing faster which is only possible if
this check is alternative, not addition. Do you have different opinion?
(This is not necessary to decide before the release I belief because it is
not real API considering the use-cases.)

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:178&gt;
GRASS GIS <http://grass.osgeo.org>

#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 wenzeslaus):

I improved options for G7:r.ros and G7:r.spread in r63777. The biggest
change is actually not the longer names but the change of `output` which
was just unnecessary use of basename concept. I replaced that by 4 new
explicit options. (I also improved the naming but not everywhere, so feel
free to change it if you have better ideas.)

Although it was already discussed here or in #2136, I submitted some
patches and Martin committed something, there might be more changes like
this needed. The point is that it is better to avoid basename if possible
because explicit options are easier to understand, better for scripting
and necessary for applications like QGIS.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:179&gt;
GRASS GIS <http://grass.osgeo.org>

#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 [comment:178 wenzeslaus]:

> > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
anything) and the found string isn't an exact match for the given string.
>
> Thanks that's good but wouldn't be better to do just the `strcmp`
comparison (to be faster) and fail (with fatal error) which would show
these things in tests (errors are clearly visible, warning must be
searched for in the output). I think the primary use-case for
`GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
options and then it is just more effective to fail. The secondary use-
case, I can think of, is making parsing faster which is only possible if
this check is alternative, not addition. Do you have different opinion?
(This is not necessary to decide before the release I belief because it is
not real API considering the use-cases.)

I just took the simplest route for now. I don't consider performance
issues at this scale to be relevant.

Changing the G_warning() to G_fatal_error() would be trivial, if that's
desired.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:180&gt;
GRASS GIS <http://grass.osgeo.org>