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

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

[Drew Adams]

1. Following on what I said about existing code that
complements colors -

I should be clear that not taking into consideration
human perception, which means also ambient lighting etc.,
a mechanical complementing/inverting function often
results in colors that, while technically complementary
(including saturation and value, not just hue), are
not ideal.

I use color complementing often when I define default
face values for a library.  Since I personally use a
light background (but not too light), with a fair
amount of ambient lighting (e.g. for working also with
paper), I define a face's default color for a light
background, and then I take the complement to get a
default color for a dark background.

I might also quickly check what that looks like, but
I don't really establish a dark setting (ambient
lighting) with a dark background mode to see what the
effect might be.  The result can well be something
that people who do use a dark background might find
less than ideal.  (I leave to them to customize the
face, or submit a suggestion of a better dark default ;-).)

___

2. One thing that I think can help, is being able to
adjust hue, saturation, and value across all faces
at once, to find what one prefers and see which faces
might be outliers.  For example, desaturate all faces,
or increase all their values.

Icicles gives you ways to do that: cycle, incrementing
or decrementing any of hue, value, and saturation.

And you can save any particular appearance you like,
as a color theme or custom theme.

And then you can further tweak individual faces in
your theme, which are unfortunate outliers from the
global change you got to by changing hue, saturation,
and value across all faces together.

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_.

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_.

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.

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

Add some built-in faces for inheritance

[Yuan Fu]

I think it would be helpful to define some common UI concepts as faces, so package authors can inherit from them instead of hard-coding their face. We already have faces like shadow, bold, error, warning, info, button, link. We can add a few more:

- foreground-highlight: highlight text using a different foreground color, used for matched results, etc.
- background-highlight: highlighted text using a different background color, used for selected candidate in company/ivy/helm, etc.
- block: text with a different background to separate from main text, used for code blocks, input fields, pop ups, etc
…

It would be helpful if someone with UI-design background could provide some ideas.

Yuan

Re: Add some built-in faces for inheritance

[Stefan Monnier]

> - foreground-highlight: highlight text using a different foreground color,
> used for matched results, etc.

Please don't rely too much on things like "color" in your descriptions.
Think more of what is the intended use rather than the visual effect you
expect for it.
[ I for one likely wouldn't change the foreground color of "matched
  results".  ]

What kind of "matched results" are you thinking of?
The text matched during isearch?

> - background-highlight: highlighted text using a different background color,
> used for selected candidate in company/ivy/helm, etc.

I think this one could be an alias for the current `highlight`, right?


        Stefan

Re: Add some built-in faces for inheritance

[Yuan Fu]

> On Sep 19, 2020, at 3:50 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> - foreground-highlight: highlight text using a different foreground color,
>> used for matched results, etc.
> 
> Please don't rely too much on things like "color" in your descriptions.
> Think more of what is the intended use rather than the visual effect you
> expect for it.

Indeed.

> [ I for one likely wouldn't change the foreground color of "matched
>  results".  ]
> 
> What kind of "matched results" are you thinking of?
> The text matched during isearch?
> 
>> - background-highlight: highlighted text using a different background color,
>> used for selected candidate in company/ivy/helm, etc.
> 
> I think this one could be an alias for the current `highlight`, right?
> 
> 
>        Stefan
> 

Maybe I should use “match-highlight”, and “selected-candidate”, respectively. The problem is that “highlight” is a bit too board, there are many different types of highlight: highlight of matched text during isearch, lazy-highlight for isearch, highlight for current selection in company/ivy/helm, etc, etc. We probably should make the definition more specific, so people know which one to inherit from.

Yuan

Re: Add some built-in faces for inheritance

[chad]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

IIUC, you're looking for candidates for semantic faces. In that case, I
imagine that it would be helpful to gather a dozen or so popular themes,
strip them down to the face-setting code, condense the specific settings
down into categories, and then synthesize the lists into solid candidates.

This seems like the sort of effort that could be distributed. I would be
willing to help out, but I don't personally use any of the more complex
completion frameworks, so I might have a big blind spot for the search.

Let me know,
~Chad

[-- Attachment #2: Type: text/html, Size: 630 bytes --]

Re: Add some built-in faces for inheritance

[Howard Melman]

+1 on this idea.  

I always cringe a little when I see a package define faces
with hardcoded color values.  I think the majority (perhaps
~80%) should be inherited so that themes can work without
having to declare every face in every package.

A few ideas off the top of my head from setting faces long ago.

- a label and value face that could be used for message
  headers (and their values), key/values in code, org
  properties, etc. 
- title, author, date
- filename, directoryname, executable, symlink, url, 
- level-1 - level-10 to be used in message/gnus citations,
  outlines, html headings, org/markdown headings, regexp group highlights,
  symbol-overlay.el, etc. 
- enabled, disabled, emphasized for UI elements

Perhaps there are a set of faces to be merged with others to
support emphasis.  In gnus headers, I want the header
name in one color (label face above), the header value in
another (value above), and I want to highlight the values of
Subject and From.  Perhaps those use title or author face,
or perhaps they merge with emphasized face which does bold
by default but could allow someone to change it to underline
or a different background, etc.


-- 

Howard

Re: Add some built-in faces for inheritance

[Juri Linkov]

> - block: text with a different background to separate from main text,
>          used for code blocks, input fields, pop ups, etc

block is welcome to inherit by mm-uu-extract, org-block, org-code...

Re: Add some built-in faces for inheritance

[Protesilaos Stavrou]

Juri Linkov <juri@linkov.net> [2020-09-20, 22:18 +0300]:

>> - block: text with a different background to separate from main text,
>>          used for code blocks, input fields, pop ups, etc
>
> block is welcome to inherit by mm-uu-extract, org-block, org-code...

As far as I can tell, the issue with face inheritance is that you must
be sure that the library where the defface occurs is loaded in advance:
'faces.el' looks like a good place.

-- 
Protesilaos Stavrou
protesilaos.com

Re: Add some built-in faces for inheritance

[Juri Linkov]

>>> - block: text with a different background to separate from main text,
>>>          used for code blocks, input fields, pop ups, etc
>>
>> block is welcome to inherit by mm-uu-extract, org-block, org-code...
>
> As far as I can tell, the issue with face inheritance is that you must
> be sure that the library where the defface occurs is loaded in advance:
> 'faces.el' looks like a good place.

Good point.  So all such general-purpose faces should be placed in the
pre-loaded file faces.el.