RE: defined-colors doc string doesn't describe nil FRAME

[Drew Adams]

    > What about my question about recomputing (defined-colors)?
    > Can you help me understand this? Is there ever any reason
    > to recompute it?

    This is based on my failing memory of color-related aspects on X
    window system; X gurus will excuse me if the below is a lie.

    At least on X, there's a limited amount of color cells available to
    all programs at any given time (unless programs use a private palette,
    which most of them don't).  So, if some program uses up many colors,
    Emacs might be unable to display all of the colors you expect.  But I
    don't know whether defined-colors is affected by this.

That would be good to know - and should perhaps be documented for
`defined-colors' - i.e., "on some platforms, ...". IOW state that
`defined-colors' always gives you the set of available colors, and that this
can (on some platforms) change during an Emacs session.

    In addition, on a tty, the number of supported colors can be changed
    during the session.

OK. So, IIUC, a library that is not going to be used on a tty might have an
interest in caching (defined-colors) in its own defconst variable. Correct?
Would that be inappropriate?

That's really what motivated my question: should I cache the value, or is
there some reason not to? And if caching might help my library, I was
wondering if it shouldn't be cached generally (I think the answer is "no",
from what you've said).

I suspect that this caching is what was originally behind variable
`facemenu-color-alist', but that variable is now an impotent vestige - see
my bug report "facemenu-color-alist never gets set?".