Re: More bugs in Custom themes

[David Kastrup <dak@gnu.org>]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Custom themes would be a completely new complex feature, not a bug
>     fix:
>
> They ARE a new feature.  This feature is already in Emacs, it is
> important, and I will not stand for giving up on it.  That is the
> wrong attitude.
>
> Would you please work on fixing this?  Otherwise we will have to wait
> till I have time to do it.  You have been doing great so far, whenever
> you decide to fix something rather than say it can't be done.
>
>     The implementation, once ready, will need thorough testing
>     (people writing and using themes).  It is impossible to
>     guarantee a time table.
>
> I'm not asking for a guarantee, or a time table.  I'm just asking
> someone to fix this feature to work.

It is a new feature, and I think we currently don't use it ourselves
in the sources.  Getting a larger tester and developer base for it
won't happen without it being in the open in a released version (which
it already is in XEmacs, with negligible impact as far as I can see)
_and_ being documented as a feature.

Yes, we might not get it to work under heavy duty in Emacs-22.  But if
we don't start the process of making it somewhat usable now, we won't
get it finished by Emacs-23 either.  Nobody claimed that 22.1 would be
the last release of the 22.x series.  For new _optional_ features, the
goal is to get them in, to get their documentation to a consistent
state, and to make a good stab of getting them working as advertised.

I should be the last to blame Luc if he decides that his personal
tastes, priorities and professional conscience don't lend themselves
to this task: it is not nice to feel responsible for code which one
considers unclean.  And it is always a cheap way out of work to say
"you are better suited for it than I am".  I don't want to go that
route, and I am being much less often helpful than I should because
other projects are also demanding of my time and I don't manage them
and professional deadlines well.

But while I don't want to use this as an excuse for myself, I still
want to express my admiration and gratitude about how often Luc comes
out with a good analysis and working suggestions and patches for
faulty code or documentation that was not written by himself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum