Richard Stallman wrote:
"A proper design" doesn't identify a specific problem I could address,
The very first design decision to be made is: what do we want Custom
Themes to be and how do we want them to be used.
I do not even know what _kind_ of Custom Themes the current code is
trying to implement or how it wants them to be used. There are no
interactive declarations in the code, so _maybe_ they are only meant
for use in initialization files, to be executed _before_ any
custom-set-{variables,faces} forms. (_Both_ enabling and unsetting of
themes seems to have to occur before these forms. No enabling or
unsetting after them, in particular, no _interactive_ enabling or
unsetting.) The code _seems_ to assume that no two themes (including
the `user' theme, but, of course, excluding the standard theme)
contain customizations for the same variable.
If all these assumptions are strictly adhered to, many of the worst
bugs no longer occur. There would still be bugs left, but they might
be fixable.
But I seem to have understood that we want something more powerful.
Then I believe that we need a complete rewrite of the current code,
essentially starting from scratch.
I believe I understood that we want to allow multiple Custom Themes,
possibly setting conflicting values for the same option, that can be
_interactively_ (as well as in init files) enabled or disabled in any
order, interspersed with arbitrary saving, setting, and resetting to
standard value, and that we even want to handle interspersed setq's in
a reasonable way. I seem to have understood that this is what users
want. I believe that it is possible (but _not_ trivial) to implement
all of that in a clean and intuitive way. I believe that it has to be
done very carefully.
The current code uses `requiring' to enable Themes. Re-enabling a
Theme has no effect if it has ever been loaded previously, so it does
not reinstate "clobbered" values. I believe we agreed that this was a
problem and that user convenience dictates replacing requiring with
unconditional loading as the fundamental Theme enabling mechanism.
This is a second fundamental design departure from the present code.
Then comes the conflict resolution algorithm (I will address that in a
second message).
Sincerely,
Luc.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
