[GRASS-dev] short versions of parameter names [was: Re: [GRASS-user] Python GUI]

[Glynn Clements]

Moritz Lennert wrote:

> [moving this over to grass-dev]

> >> But it should be possible to parse the answer taking into account 
> >> shorter versions. See, for example, how type_opt is parsed on lines 
> >> 478ff in display/d.vect/main.c.
> > 
> > 
> > sure there's code in d.vect to handle it, but the parser won't actually
> > let you give anything but the full words listed in the ->options line.
> > 
> > 
> > G64> d.vect fields type=bound --q
> > 
> > ERROR: value <bound> out of range for parameter <type>
> >        Legal range: point,line,boundary,centroid,area,face
> > 
> 
> Ok, I get it. Any reason this is so ? Would it be possible / desirable 
> to change the parser to allow short versions of parameter names ?

Done in r33643, subject to some caveats.

[That change also allows numeric ranges to be open at either end.]

> Maybe have this as an option in the definition, i.e. 
> parameter->short=YES ?

That would have been simpler, but then you lose consistency. I.e. some
modules allow abbreviations, while others don't. I feel that this
really needs to work everywhere.

The main problem is that most modules expect opt->answer or
opt->answers[i] to match exactly, so G_parser() not only needs to
check for validity, but to replace the abbreviation with the full
name.

This is done, but for ->multiple options, only ->answers[i] is
modified; ->answer isn't reconstructed. Consequently, this doesn't
currently work for g.parser or for scripts which use it.

There's also the issue of uniqueness. Currently, it won't accept an
abbreviation if it could match multiple choices. This means that it
can't be used to abbreviate a choice is a prefix of another choice
(e.g. rast and rast3d). This is consistent with how abbreviated option
names work. Ultimately this restriction could be removed, but
initially it's better to err on the side of caution.

This also relates to the more general issue of when to abbreviate
option (and now choice) names. E.g. some modules use rast= or vect=
rather than the full name. IMHO, it would be preferable for modules to
always use full names, but this is problematic where terms are
"derived" by appending a suffix (e.g. raster -> raster3d).

If we want to eliminate abbreviations, we may also need to modify
standard terminology to use prefixes instead of suffixes, e.g. 
raster3d -> 3draster, image1/image2 -> 1st_image/2nd_image, etc.

BTW, I eventually want to allow abbreviating individual words within
names, e.g. allowing an option to be named input_raster= but entered
as inrast=. That would remove some of the pressure regarding the need
to abbreviate; e.g. if you had raster= and raster_3d=, you could
abbreviate the latter with r3=, rather than needing to type raster3=
to distinguish it from raster=.

-- 
Glynn Clements <glynn at gclements.plus.com>