Re: More bugs in Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   They ARE a new feature.  This feature is already in Emacs,

There is currently no support for Custom Themes in Emacs that comes
remotely close to working.  The three unfixed bugs I mentioned are
just examples.  As another example, a fourth bug is that when an
option's value is set by a theme, the Customization buffer incorrectly
says "Set and Saved".  It should say that it was set by the theme.  It
does not stop there.  95% of what I try leads to a bug.  In the
remaining 5% of the cases the code gets things right by coincidence,
not by design.  It has no design (except for the "Big Picture", see
below).  It makes no sense to fix the 1001+ bugs in this code.  You
just will have produced 1001+ new ones in the process.  The code in
custom.el needs a really thorough rewrite.  It needs a *design*.  All
of this will take time.

The Custom themes code does not seem to worry too much about little
details like working correctly or how it is supposed to be used by the
user and such.  All it seems to care about is the big picture.  It is
actually possible to understand the big picture but it has some really
bizarre aspects.  Here it is.

First the code obviously gives the impression of trying to implement
Themes support by files of the type cus-theme.el produces.  To really
do that in a bug free and predictable way, the very first thing you
need is a good conflict resolution algorithm.  The code contains none.
The near infinity of bugs is the unavoidable consequence of that.  It
makes a half-hearted and completely incoherent attack at removal of
themes.  Can not be anything else but incoherent: this needs a
conflict resolution algorithm.  Then it tries to implement "hidden
themes", as well as themes requiring, unsetting and hiding other
themes and so on, all while making no attempt whatsoever at getting
the basics right.

>From here on things get completely bizarre.  The Themes code, which is
absolutely saturated with bugs, wants to reimplement Custom to make it
dependent on its own code and "design".  Fortunately, this has not
been completely implemented yet, but the ordinary Custom code appears
to have been at places permeated by the Themes code.  Things get worse
from here.  The envisioned reimplementation of Custom requires a
rewrite of `defvar' and various other basic Emacs primitives.  (No
kidding!  Fortunately this is not implemented yet.  I very much hope
it never will be.)

>From the `custom-declare-variable' docstring:

  DEFAULT is stored as SYMBOL's value in the standard theme.  See
  `custom-known-themes' for a list of known themes.  For backwards
  compatibility, DEFAULT is also stored in SYMBOL's property
  `standard-value'.  At the same time, SYMBOL's property `force-value' is
  set to nil, as the value is no longer rogue."
    ;; Remember the standard setting.  The value should be in the standard
    ;; theme, not in this property.  However, this would require changing
    ;; the C source of defvar and others as well...

First of all, the docstring appears to contain a falsehood.  From the
comment, DEFAULT is not _currently_ stored in the standard theme.  But
the docstring clearly seems to indicate that for full theme support,
this needs to change in the future, requiring a rewrite of defvar and
various other primitives.

This is completely crazy.  Custom themes can be implemented without
redesigning Custom and certainly do not require changing defvar and
tons of other primitives.  What is this madness in the above docstring
and comment?  What Custom themes need is a sensible conflict
resolution algorithm, not a rewrite of defvar!

Sincerely,

Luc.