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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
