#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:73 martinl]: > another option could to my mind. To use 'raster3d' and modify the parser in the way that it would support also 'rast' and 'rast3d' with appropriate warning I don't think that "rast" should generate a warning. We want the user to be able to abbreviate option names when running commands interactively. At the same time, it's preferable for scripts to avoid abbreviations, which they can't do if the actual option name is itself an abbreviation. Perhaps we should relax the rule relating to ambiguous abbreviations for the case where one option name is a prefix of another? At present, if a module has options named "raster" and "raster3d", "rast" (or any other abbreviation of "raster") will be rejected as ambiguous. The option-matching function has to explicitly check for the case where an option name is given in full, otherwise even the unabbreviated option name would be rejected as ambiguous. The change wouldn't be trivial; the function can no longer simply count matches, it has to record them. But as a side-effect of that, the error message for ambiguous options could list all of the matches. If we don't make that change, then we should try to avoid the situation where one option name is a prefix of another. In particular, that precludes "raster3d" or "rast3d". -- Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:75> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev