[GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--------------------------------------------------+-------------------------
 Reporter:  pvanbosgeo                            |       Owner:  grass-dev@…              
     Type:  enhancement                           |      Status:  new                      
 Priority:  normal                                |   Milestone:  7.1.0                    
Component:  Default                               |     Version:  unspecified              
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |    Platform:  All                      
      Cpu:  Unspecified                           |  
--------------------------------------------------+-------------------------
Changes (by wenzeslaus):

  * keywords:  g.remove => g.list, g.remove, g.mlist, g.mremove


Comment:

 Replying to [comment:13 glynn]:
 > Replying to [comment:10 hcho]:
 >
 > > which can be misleading because it doesn't take multiple pattern
 strings, but it only takes multiple map names and a single pattern string.
 >
 > There seems to be two problems here.
 >
 > One is that the meaning of pattern=/exclude= may change depending upon
 whether -r/-e are used. I thought that we had already learned that making
 the semantics of one option change according to the value given for other
 options is a bad idea.
 >
 > The other is that there seems to be confusion over the meaning of
 pattern=/exclude= in the absence of -r/-e. Is it a list of map names, or a
 glob pattern? It can't be both unless both G_parser() and the GUI
 recognise "list of map names or string" as a distinct type. "list of map
 names" won't allow the use of glob patterns because G_parser() will
 complain about illegal characters and "string" won't work insofar as the
 GUI won't provide a browser interface for it.
 >
 I generally agree, I perhaps mentioned this several times. For the future,
 we need some higher level types. Some types are in "standard options" but
 they are not exposed. Another example of higher level types would be
 binary file and text file (as opposed to any file), GUI is now providing
 direct/interactive input box for binary files. With "color rules file" we
 can provide a GUI editor with preview besides the textual input.

 However, for this case, I think that the following is better option.

 > One solution would be to add a separate option (e.g. names=) which
 accepts multiple valid map names, mark pattern= and names= as mutually
 exclusive. names= would support multiple options and some form of
 browsing, pattern= would be a plain string. Similarly for exclusion.
 >
 This is quite simple and it also solves the problem I was afraid of: users
 seeing the option named pattern and not willing to use it because they
 want to input a map name not some pattern they don't understand. Option
 named `names` fits well with this use case. `maps` would be more
 consistent but it would not be precise and `names` goes well with
 `pattern`.

 > Another solution would be rename g.remove to e.g. g.mremove, remove the
 pretence about pattern=/exclude= being something other than "arbitrary
 string", and add a g.remove script which would be a thin wrapper around
 g.mremove (possibly the only difference would be to re-declare the types
 of the pattern=/exclude= options).

 This might go against the reasons for doing this whole thing, reducing the
 complexity of interface and maintenance cost by reducing the number of
 modules:

  * http://osgeo-org.1560.x6.nabble.com/g-mlist-list-multiple-types-from-
 all-mapsets-td5142385.html

 Or were there some other reasons?

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