Re: Custom themes

[David Kastrup]

Luc Teirlinck <address@hidden> writes:

> The situation with Custom themes is a lot worse that I thought
> yesterday.  I discovered two new bugs, one so serious that it makes
> the Custom themes feature unusable.  It is nearly guaranteed that
> even if those two bugs could be solved plenty of others remain.  The
> Custom Themes code seems to have been incorrectly ported from
> XEmacs, to a degree that it is presently completely dysfunctional.
>
> It is nearly impossible to understand incorrectly ported code,
> unless you know the package that was ported.  It _is_ possible for
> me to debug cus-theme.el, even though it has many bugs, because it
> is originally designed code.  You can guess the original design and
> make the code behave like it.  However, the themes code in custom.el
> is ported code.  In this incorrectly ported code, the original
> design seems to be destroyed by the incorrect porting.  You can only
> know it by studying the package that was ported.
>
> Repairing and debugging the themes code means correcting the porting
> errors and finishing off the porting task.  I never used XEmacs, I
> do not have it installed.  I do not know anything about the
> differences between the Emacs and XEmacs versions of Elisp.  I know
> nothing about the actual XEmacs version of Custom themes.  I do not
> know how it works, whether it works (without excessive bugs),
> whether it is actually used by people and, if so, how it is used.
>
> I am absolutely not the right person to work on this.  Somebody who
> is interested in Emacs development, but who is familiar with XEmacs
> Custom Themes should finish this off.  "Finishing it off" seems to
> be a substantial task.

I seem to remember from discussions on XEmacs-beta that this feature
is not widely used or recognized by XEmacs developers, so it is
possible that the overall quality of the original code on XEmacs (if
it indeed originates there) is not much better than what you have at
hand at the moment.

I do think that having custom themes would be quite desirable: users
could select a default site theme, for example, and override parts of
it with other themes.

If the design of the API is sound, it might be the sanest choice to
eventually come up with an implementation from scratch if the
situation is as bad as you describe, and just document the current
implementation of being a draft, and documenting where it is still
defective.  If there are doubts about the API to be implementable at
all, we should probably remove theme support altogether from Emacs 22:
there is no sense in getting people used to interfaces that can and
will not be fixed or implemented.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum