parameterised dark theme

[fommil]

Thank you for this theme!

I am creating a theme inspired by IntelliJ's Darcula and I'm finding that there is a lot of duplication involved in creating a theme: every major mode seems to require a plethora of face definitions.

It seems that in solarized you've done a good job of aggregating all the most popular faces and providing a full set of faces.

It would be incredibly useful for me if I could simply call a function in solarized with my list of colour permutations and to receive a theme that has all the faces set according to the rules that solarized prescribes.

Is that possible, is it something you'd be interested in exposing?

[sellout]

Yes, I have been hoping to expose various things like that, from a full-on “enter 16 colors, get a theme” to smaller chunks that handle various aspects.

Also, you might want to check the unified branch, as it does better handling of various things – supports mixing GUI and terminal frames, and mixing dark and light frames based on background-mode.

The only reason it hasn’t replaced master is because of some problems with the pre-24 color-theme support. But I’ll probably forget about that soon enough.

[sellout]

The unified branch has been merged into master – you should be able to just replace the values in the sRGB column of solarized-colors to experiment with new themes (at least in the GUI).

[fommil]

Cool! I'll have a look at this soon. I finished up my standalone theme but I think this would ultimately be the best way to do it.

[sebastiansturm]

I'd like to revive this issue by asking if there has been any progress on your "enter 16 colors, get a theme" toolkit? For me the main drawback with 3rd party themes is that they often lack customizations for dozens of faces that I would have to add manually to achieve some sort of visual consistency, so what I would like to see is a theming framework that can at least help me with the generation of the necessary elisp code. I have drafted a proof of concept (see https://github.com/sebastiansturm/autothemer) that allows me to define a color palette at the time of theme creation, and then provides the user with an interactive function autothemer-generate-templates that iterates through all defined, but un-customized faces, replaces their color values by the best approximations found in the theme palette and displays these customizations as elisp code that can be further refined and pasted into the theme definition. However, my approach currently completely ignores terminal capabilities (it pretends that a full-color GUI is always available), whereas some themes like solarized go to great lengths to degrade gracefully on less capable terminals. Would you be willing to help me incorporate a solarized-like face definition scheme into autothemer, or do you already have something different brewing (in which case I'd like to use that, if it supports autogeneration of elisp templates)?

[sellout]

I have been doing some stuff, but all of my Emacs stuff is pretty slow going. The approach I’ve spent the most time on recently is https://github.com/sellout/emacs-extended-faces, which is an attempt to reduce the complexity of all themes by creating an inheritance hierarchy across all faces.

My local copy of solarized uses it, but I should push that to a branch. It also seems orthogonal to what you’ve been doing, and I haven’t been doing anything along the lines of autothemer, which looks cool.

I think Solarized’s face definition approach is something worth pulling out into its own package, and it could then be shared by solarized and autothemer. It’s on my todo list, and I’m willing to help you sort that out if you want to try it.

[sebastiansturm]

that is a good idea (extended-faces); face inheritance currently seems like a much underused feature.

Concerning solarized's face definitions, I'd love to have your help incorporating that into autothemer. In my opinion, it would be nice if the user could define his color palette as a matrix, where the first row specifies the respective categories, and later rows define the color values. Ideally it should also be possible to use function-valued entries (in a let*-like manner that allows the user to refer to previously defined colors), and have missing/nil entries automatically replaced by their left neighbors, as in the following example.

( ;; first row: specifies categories
 (((class color) (min-colors 89)) ((class color) (min-colors 16)) t)
 (reddish "#FF8877" "#FF0000") ; last entry missing: automatically uses left
                                        ; neighbor #FF0000
 (pinkish "#DD66EE" nil "FF00FF") ; second entry missing: uses left neighbor
                                        ; #DD66EE
 (white "#FFFFFF")
 (halfpink (blend pinkish white 0.5)) ; can use arbitrary elisp and previously
                                        ; defined colors
 )

The user should then be able to refer simply to reddish, pinkish, etc., and have autothemer insert the appropriate color values automatically. Do you think this is a viable approach?