Info about color-values need be revised

Info about color-values need be revised

[CHENG Gao]

In ELISP manual, info about color-values is not true any more with NS
port merged.

,----[ (info "(elisp)Color Names") ]
|  -- Function: color-values color &optional frame
|      This function returns a value that describes what COLOR should
|      ideally look like on FRAME.  If COLOR is defined, the value is a
|      list of three integers, which give the amount of red, the amount
|      of green, and the amount of blue.  Each integer ranges in
|      principle from 0 to 65535, but some displays may not use the full
|      range.  This three-element list is called the "rgb values" of the
|      color.
| 
|      If COLOR is not defined, the value is `nil'.
| 
|           (color-values "black")
|                => (0 0 0)
|           (color-values "white")
|                => (65280 65280 65280)
|           (color-values "red")
|                => (65280 0 0)
|           (color-values "pink")
|                => (65280 49152 51968)
|           (color-values "hungry")
|                => nil
`----
It says return value is (R G B).


In NS port, color-values uses function xw-color-values:

,----[ C-h f xw-color-values RET ]
| xw-color-values is a built-in function in `nsfns.m'.
| 
| (xw-color-values color &optional frame)
| 
| Return a description of the color named color.
| The value is a list of integer RGBA values--(RED GREEN BLUE ALPHA).
| These values appear to range from 0 to 65280; white is (65280 65280 65280 0).
| The optional argument frame is currently ignored.
| 
| [back]
`----

The return value is (R G B Alpha).

So the info manual need be revised.

RE: Info about color-values need be revised

[Drew Adams]

> In ELISP manual, info about color-values is not true any more with NS
> port merged. It says return value is (R G B).
> 
> In NS port, color-values uses function xw-color-values:
> The return value is (R G B Alpha).

Ouch! Why is that? Why does a platform-specific function change the meaning of a
generic function that way? And why should the generic function's signature be
changed accordingly (breaking existing code)?

Code that uses `color-values' depends on its return value being a 3-element
list. That includes any NS code that uses `color-values' (as opposed to
`xw-color-values'). Seems like any NS code that needs the Alpha info should call
`xw-color-values' directly (or some other NS-specific function) - and
`color-values' should be left alone.

Re: Info about color-values need be revised

[CHENG Gao]

*On Sun, 16 Aug 2009 08:30:53 -0700
* Also sprach "Drew Adams" <drew.adams@oracle.com>:

>> In ELISP manual, info about color-values is not true any more with NS
>> port merged. It says return value is (R G B).
>> 
>> In NS port, color-values uses function xw-color-values:
>> The return value is (R G B Alpha).
>
> Ouch! Why is that? Why does a platform-specific function change the meaning of a
> generic function that way? And why should the generic function's signature be
> changed accordingly (breaking existing code)?
>
> Code that uses `color-values' depends on its return value being a 3-element
> list. That includes any NS code that uses `color-values' (as opposed to
> `xw-color-values'). Seems like any NS code that needs the Alpha info should call
> `xw-color-values' directly (or some other NS-specific function) - and
> `color-values' should be left alone.

I dont have strong opinion or even weak opinion about what's right or
wrong. I just report my findings. As for what to do, it's up to Emacs
developers.


-- 
Ubi bene, ibi patria

Re: Info about color-values need be revised

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 16 Aug 2009 08:30:53 -0700, "Drew Adams" <drew.adams@oracle.com> said:

>> In ELISP manual, info about color-values is not true any more with
>> NS port merged. It says return value is (R G B).
>> 
>> In NS port, color-values uses function xw-color-values: The return
>> value is (R G B Alpha).

> Ouch! Why is that? Why does a platform-specific function change the
> meaning of a generic function that way? And why should the generic
> function's signature be changed accordingly (breaking existing
> code)?

As I've been saying, the alpha component support in the NS port should
have been removed in the first place.

Does anyone oppose doing that (again) in the trunk?

Also, we can observe that users tend to spread (*) such an eye candy
feature without caring about various compatibility issues or the GNU
policy.  That's why it was important to get rid of such a feature from
the release version.

*: http://www.emacswiki.org/cgi-bin/emacs-en?Compare=Compare&action=browse&diff=1&id=TransparentEmacs&revision=40&diffrevision=39

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Info about color-values need be revised

[David Reitter]

On Aug 18, 2009, at 11:47 PM, YAMAMOTO Mitsuharu wrote:

> As I've been saying, the alpha component support in the NS port should
> have been removed in the first place.
>
> Does anyone oppose doing that (again) in the trunk?
>
> Also, we can observe that users tend to spread (*) such an eye candy
> feature without caring about various compatibility issues or the GNU
> policy.  That's why it was important to get rid of such a feature from
> the release version.

You were right about these things for the release, but as for the  
trunk, could people please consider the alternative:

Adding transparency to the other platforms where the APIs support it  
easily, and creating Lisp-level compatibility for transparency in the  
color specification.   -?

It is no surprise that folks roll their own if the mothership is so  
far behind the times with such features.  And people do it on those  
platforms first where it is easy because the right OS layer provides  
APIs for it; especially if the platform is so popular.    And once  
people like me add their own features, they get used, and the Lisp  
APIs diverge.  What has the purposeful GNU policy achieved then?


ps:  Nota bene: You personally are not the tree up which I am barking  
when it comes to lack of implementation activity...

Re: Info about color-values need be revised

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 19 Aug 2009 00:22:09 -0400, David Reitter <david.reitter@gmail.com> said:

>> As I've been saying, the alpha component support in the NS port
>> should have been removed in the first place.
>> 
>> Does anyone oppose doing that (again) in the trunk?
>> 
>> Also, we can observe that users tend to spread (*) such an eye
>> candy feature without caring about various compatibility issues or
>> the GNU policy.  That's why it was important to get rid of such a
>> feature from the release version.

> You were right about these things for the release, but as for the
> trunk, could people please consider the alternative:

> Adding transparency to the other platforms where the APIs support it
> easily, and creating Lisp-level compatibility for transparency in
> the color specification.  -?

It is important to discuss how the color specification with alpha
component should look like.  Most of the current NS color
specifications are defined arbitrarily without following any existing
standards or discussing with other developers.  I think they should be
revamped (i.e., remove the current code now, and add a new code when
the specification is determined and implementation is added for
GNU/Linux).

It may take time and sometimes cumbersome, but I think it is the right
way to avoid diverging.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Info about color-values need be revised

[Stefan Monnier]

> As I've been saying, the alpha component support in the NS port should
> have been removed in the first place.

> Does anyone oppose doing that (again) in the trunk?

No, please do so: now is the right time,


        Stefan

Re: Info about color-values need be revised

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> As I've been saying, the alpha component support in the NS port should
> have been removed in the first place.
>
> Does anyone oppose doing that (again) in the trunk?

The changes which you proposed at the time did not include a fix to
xw_color_values.  I agree that this function should not return an alpha
component, so please go ahead and fix it to avoid returning alpha.