[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bug, probably related to Custom Themes.
From: |
Drew Adams |
Subject: |
RE: Bug, probably related to Custom Themes. |
Date: |
Sun, 25 Dec 2005 11:38:39 -0800 |
Also everybody writing future code for Custom should
realize that when they want to access the standard value,
they should not just look at the 'standard-value property
but that they should use the non-user
theme value instead if there is one.
Maybe we should add a subroutine which does this, to help people
get it right every time.
1. Is there an acceptable alternative way to deal with this? I thought Luc
was saying that there was, but I could be mistaken (I haven't followed
everything in this thread).
One consequence of fixing the problem by providing such a subroutine will be
that code that tries to work with multiple versions of Emacs will become
more complex that it would otherwise be (some versions will have the
subroutine; others won't). I know that is not a priority concern of Emacs
development, but you might want to consider it at some (secondary) level.
"Users" of Emacs include not only its end users but also external-library
developers, and the latter sometimes try to provide code that works across
different Emacs versions, FBOFW.
2. Luc also seemed to be saying that there is unnecessary coupling now
between the themes code and the custom code, making writing code that uses
either of them trickier or more complex. If the two are as incestuously
intertwined as Luc suggests, wouldn't it make sense to cut some of the bonds
and have them shake hands at a more respectable distance? I don't know if
that would be possible before the release, but the impression I get from
Luc's description is that maintenance and bug storms are looming in this
area.
I'm all for letting other libraries change custom values and states, as I've
stated previously. Custom is so important and potentially useful, that we
shouldn't confine its functionality to the Customize UI. But if other
libraries break Customize functionality, then that's not good. And if people
must be aware of multiple libraries and their effects in order to interact
with Customize (interactively or through code), then that's not good either.
My idea was to let other libraries use Customize functionality, but that
must be done cleanly and transparently - as if it were done by/in Customize
itself.
- Re: Bug, probably related to Custom Themes., (continued)
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/23
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/23
- Re: Bug, probably related to Custom Themes., Chong Yidong, 2005/12/23
- Re: Bug, probably related to Custom Themes., Richard M. Stallman, 2005/12/24
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/23
- Re: Bug, probably related to Custom Themes., Chong Yidong, 2005/12/23
- Re: Bug, probably related to Custom Themes., Richard M. Stallman, 2005/12/24
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/24
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/24
- Re: Bug, probably related to Custom Themes., Richard M. Stallman, 2005/12/25
- RE: Bug, probably related to Custom Themes.,
Drew Adams <=
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/26
- Re: Bug, probably related to Custom Themes., Richard M. Stallman, 2005/12/26
- Re: Bug, probably related to Custom Themes., Chong Yidong, 2005/12/25
- Re: Bug, probably related to Custom Themes., Richard M. Stallman, 2005/12/26
- Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/23
Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/21
Re: Bug, probably related to Custom Themes., Luc Teirlinck, 2005/12/21
Re: Bug, probably related to Custom Themes., David Kastrup, 2005/12/21
Re: Bug, probably related to Custom Themes., Chong Yidong, 2005/12/21