"color name existing-name" no longer shows definition of built-in colors

[Elaine Meng]

One used to be able to show the definition of a color with

color name <existing-name>
OR
colordef <existing-name>

This used to work regardless of whether a color was built-in or user-defined. Now it only works for user-defined. It is extremely useful to show the definition of a built-in color, mainly when you want to create a color that is similar to that color, but adjusted to your liking.

[Greg Couch]

'color name blue' works, the confusion comes from 'color name steel blue' since we allow color names with spaces in them. That, however, creates a new color named 'steel' that is a copy of 'blue'. That is, the <existing-name> argument is a string and needs to be quoted if it has spaces in it.

The "simple" fix of allow the name to be a color name or a string makes 'color name steel blue' show the color of steel blue, but makes 'color name steel red' change the steel blue color to red. So to truly fix this, we would need to add another command, ie., 'color show name' that would show the color in the log.

[Greg Couch]

Separated 'color name' into 'color show <rest of line>' and 'color name <name> <color>' where <name> and <color> are required. Also show the color in the log after defining it.

[Elaine Meng]

It is better, but “color name” logging is still confusing.  Currently log shows:

color name steel blue
Color 'steel' is opaque, 0% red, 0% green, and 100% blue 
color show steel blue
Color 'steel blue' is opaque, 27.45% red, 50.98% green, and 70.59% blue 

I suggest changing “color name” logging to something like:

color name steel blue
Defining color 'steel' as opaque, 0% red, 0% green, and 100% blue