[GRASS5] Re: [GRASSLIST:8545] Re: d.vect.thematic options with spaces

[Michael Barton]

OK. I guess I'll make this change when I update d.vect.thematic to do
variable width lines.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam at yahoo.com>
> Date: Tue, 11 Oct 2005 17:15:37 +1300
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Re: [GRASSLIST:8545] Re: d.vect.thematic options with
> spaces
> 
>>>>> As a side remark, this might be an argument for avoiding arguments
>>>>> with spaces whenever possible. For example, in d.vect.thematique,
>>>>> it might be better to find other names for arguments such as
>>>>> 'graduated colors', 'custom gradient', 'standard deviation', etc.
>>>> 
>>>> No need. Tcl has perfectly good support for lists; there's no
>>>> reason to treat a command as a string.
>>>> 
>>> 
>>> Well, my remark was meant for the command line, where you have to
>>> know that you have to put some of the options between quotes because
>>> there are spaces between them. I just think it would make life
>>> easier for everyone if we avoid option names with spaces in them...
>> 
>> This makes sense. When I originally wrote the script, I was thinking
>> of making the options understandable, and didn't really anticipate how
>> much more complex and useful it would become. When I was porting it to
>> a GIS Manager panel, I toyed with the idea of changing the options to
>> single words but didn't at that point because it seems to have become
>> very widely used and I didn't want to cause existing users a lot of
>> grief.
>> 
>> I think it would be better to rename some of these options, but I'm
>> not sure of the smoothest way to transition everyone to new single
>> word names. Do any of you have experience with this?
> 
> Just replace the spaces with underscores. As long as the module wasn't
> included in the 6.0.x releases I don't think there is a problem fine-
> tuning the development version. It's not supposed to be stable; the
> possibility of bugs and change is the price you pay for getting access
> to the latest & greatest. I for one agree that fixed module options
> should not contain spaces.
> 
> 
> 
> Hamish