[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                           |  
--------------------------------------------------+-------------------------

Comment(by hcho):

 Replying to [comment:14 wenzeslaus]:
 > 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`.

 I agree with you that this solution is better than the other because the
 main reason of replacing g.list/remove was to reduce redundancy. These two
 additional options would act as a wrapper around the pattern options.
 {{{names=}}} and {{{exclude_names=}}} should solve this issue in GUI. In
 command line, it's up to the user which one to use for a list of map names
 because the pattern options can handle a list of map names as well.


 >
 > > 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:15>
GRASS GIS <http://grass.osgeo.org>