Invalid `face' property in Customize buffer [was: read-face-name bugs]

[Drew Adams]

I'd like to revisit this bug report. I believe now that I reported the wrong
bug.

The real bug is, I believe, that the text mentioned in the Customize buffer
has an invalid `face' property value. The value is ((foreground-color .
"Firebrick")), whereas it should be (foreground-color . "Firebrick") - there
is an extra level of list.

Before, I was misreading the Elisp manual, and thinking that the value of
the `face' property here was correct - I was thinking that the `face' value
could be, for instance, ((foreground-color . "Firebrick") (background-color
. "LightBlue")) - a list of one or two conses. The doc says, on the
contrary, that it can only be a simple cons: (foreground-color .
"Firebrick") *or* (background-color . "LightBlue").

Now, I believe that both the Elisp doc and the coding of `read-face-name'
are correct, and the bug is that the Customize text in question has an
invalid `face' property value.

One or the other is wrong. If the doc and `read-face-name' are correct, then
the customize code is wrong, and vice versa.

The particular Customize buffer text in question is that of the second
"sample" text (next to the foreground field) - see the original bug
description, below:

---

    2. I think the code is wrong for the case where there is a face
       property like this on the character: ((foreground-color
       "Firebrick")). The code tests whether the car is foreground-color
       or background-color, but it should test whether the caar is that.

       To test this, do M-x debug-on-entry read-face-name, and then M-x
       customize-face font-lock-comment-face. Then, put point on the
       second "sample" text (next to the foreground field), and do M-:
       (read-face-name "foo"). Step through the debugger, and you'll see
       that the ((foreground-color . "Firebrick")) case falls through the
       crack.