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.
I suggest that it will be easy to figure out what to do in each of these
cases if we keep in mind the order of priority that these various
actions ought to obey:
Individual user custom settings.
Settings from themes (in reverse order of precedence)
Default values.
As for settings with setq, those should make the variable a rogue, as
now. When the variable is a rogue, theme operations should not touch
it.
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.
I agree. I don't think that should be TOO hard.
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.
It is more work for the computer than necessary, but that's what
computers are for. I proposed this because it should be easy to
implement with simple code. Thus, we can get it working easily.
However, looking at the code for custom-do-theme-reset, it seems
that I don't have to do much work to make it work right
without reloading loaded themes. All the data is available
in the theme-value properties. I just have to rewrite the code
to DTRT in each case. I've done some of that already.
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,
In the scheme as I've proposed it, that cannot happen.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
