Re: More bugs in Custom themes

[Luc Teirlinck <teirllm@dms.auburn.edu>]

   but I think we already discussed the proper conflict resolution
   method.  What I suggested was that the themes are listed in an order,
   and later themes override earlier themes.

It is a little bit more complex than that.  The user can enable or
disable themes, save options through Custom, set them through Custom,
reset them to standard through Custom and change them using setq.  In
each possible situation, you need to decide how to determine the
actual value, saved-value, theme-value (or theme-face), backup-value
and customized-value.  Maybe the answers are obvious in each case, but
each combination of cases has to be thought about.

I believe that mainly the actual value (the case we have been worrying
about) is not completely trivial.  However, I also have my doubts
about the way the current code handles `saved-value'.  Related to the
latter problem is yet another design decision to be made.  When the
option has been set by a theme, the current code says that it has been
"Saved and set".  I believe that this is unhelpful and confusing and
that it should say instead that it has been set by a theme, preferably
saying which theme.  This probably requires handling saved-value
differently.

   Disabling any of the themes works by getting rid of all of them,
   then reloading the ones that remain enabled.

To me, that seems to be a contorted way to do it.  Also, do not forget
that when the user asks to disable a theme, the value you want to
restore will sometimes be a setq-ed value, thus not associated with any
theme, and that you also have to make sure that your method gets all
stored info right, not just the actual value.

   You've already got the function which turns them all off.

You mean `custom-do-theme-reset'?  That is the very last function I
would want to use, rely on or emulate if I were you.  It indeed turns
them _all_ off, but then _pretends_ that it only turned one off by
just removing one from theme-value (or theme-face).  Looks like a
badly messed up function to me, but since I have no idea what that
code is trying to _accomplish_ (although I know perfectly what it
_does_), I may be wrong.

   If you think it would be hard to write this, could you tell me which
   functions deal with this part of things?  Then I will try.

`custom-do-theme-reset' I am afraid.  Again, I would not take a lot of
my inspiration from that one if I were you.

I believe that a function to properly disable a theme has to be
written from scratch.  But you will probably have to rewrite plenty of
other stuff before you can begin to rewrite that one.

Of course, the function to enable themes will also have to be
rewritten to use unconditional loading instead of requiring, but that
is probably easier.

It is actually my impression that most of the code needs to be
rewritten.  Maybe some stuff can be recycled in one form or another
into the new design.

Sincerely,

Luc.