RE: Bug, probably related to Custom Themes.

["Drew Adams" <drew.adams@oracle.com>]

        Also everybody writing future code for Custom should
        realize that when they want to access the standard value,
        they should not just look at the 'standard-value property
        but that they should use the non-user
        theme value instead if there is one.

    Maybe we should add a subroutine which does this, to help people
    get it right every time.

1. Is there an acceptable alternative way to deal with this? I thought Luc
was saying that there was, but I could be mistaken (I haven't followed
everything in this thread).

One consequence of fixing the problem by providing such a subroutine will be
that code that tries to work with multiple versions of Emacs will become
more complex that it would otherwise be (some versions will have the
subroutine; others won't). I know that is not a priority concern of Emacs
development, but you might want to consider it at some (secondary) level.
"Users" of Emacs include not only its end users but also external-library
developers, and the latter sometimes try to provide code that works across
different Emacs versions, FBOFW.

2. Luc also seemed to be saying that there is unnecessary coupling now
between the themes code and the custom code, making writing code that uses
either of them trickier or more complex. If the two are as incestuously
intertwined as Luc suggests, wouldn't it make sense to cut some of the bonds
and have them shake hands at a more respectable distance? I don't know if
that would be possible before the release, but the impression I get from
Luc's description is that  maintenance and bug storms are looming in this
area.

I'm all for letting other libraries change custom values and states, as I've
stated previously. Custom is so important and potentially useful, that we
shouldn't confine its functionality to the Customize UI. But if other
libraries break Customize functionality, then that's not good. And if people
must be aware of multiple libraries and their effects in order to interact
with Customize (interactively or through code), then that's not good either.
My idea was to let other libraries use Customize functionality, but that
must be done cleanly and transparently - as if it were done by/in Customize
itself.