Re: light, dark, and theme adjustment & generation [was: solarized]

[Tim Cross]

Drew Adams <drew.adams@oracle.com> writes:

> I'm not advertising this as an Icicles feature.  My
> point is to suggest having tools to globally tweak
> an appearance and create a theme from that.  That
> includes starting with some theme and tweaking it.
>
> Besides adjusting hue, saturation, and value, it would
> be good to be able to adjust _contrast_.
>

I agree this would be a useful component. I have often found themes
which I find to be 80% there, but just need a little tweaking to adjust
hue, saturation or contrast, but the effort to do that by updating each
face is a pain. I would suggest that any 'theme generator' would need
such functionality. 

> Others have brought up theme generation.  I'm not sure
> what was meant by that, but what I describe here could
> be considered a kind of theme generation, as well as a
> kind of theme editing.
>
> IOW, besides customizing individual face settings in
> a theme, it can be quite useful to be able to adjust
> a set of faces used by a them _together_.
>

While everyone will have a different interpretation of what a theme
generator is, my position is that it would provide a way to work with
theme definition which reduces the need to work at the individual face
level. You will still need this ability, but it would be great to have a
way to work at a group or layer level. This would possibly require some
more specific way of defining relationships between faces. 

> The Icicles commands that do this act on all faces.
> But it could be helpful to be able to (easily, somehow)
> limit such global tweaking to a particular subset of
> faces.

Agreed.

Consistency will be important as well. A very common failure I've seen
with attempts to provide an interface to manage themes is when the
generated result is inconsistent. I recall the old way of customizing
your theme under windows. The system work OK provided you wanted a theme
with a light background. However, as soon as you wanted a theme with a
dark background, you would suddenly have situations where you ended up
with black/dark foreground faces on black/dark backgrounds. I've seen
the same problems under various GNU Linux window managers and other
applications.

The challenge for Emacs will be how to ensure faces are categorised
correctly. We can have algorithms to ensure certain levels of contrast
etc, but if you don't have some way of classifying how/where the face is
used, you cannot easily determine this. As any package can define new
faces, this will be a challenge. It becomes an even greater challenge
because packages and face definitions can be loaded at different times -
how does any theme generator or customisation framework handle the
situation where a face is not yet defined/known at the point when the
tool runs? Do we just accept the tools work on a core set of faces and
suggest that any package which defines a new face defaults to inherit
from one of the core faces or do we implement some higher level
abstraction which is used whenever a new face is loaded to define
initial settings?


-- 
Tim Cross