Support for solaire-mode

[jezcope]

solaire-mode looks pretty cool, but requires a specific set of faces to be defined:

solaire-default-face
solaire-minibuffer-face
solaire-linum-face
solaire-linum-highlight-face
solaire-hl-line-face
solaire-org-hide-face
solaire-mode-line-face
solaire-mode-line-inactive-face

[belak]

I've been looking at this as well. It's pretty interesting. However, I'm not sure what the best faces would be. I've tried brightening up the minibuffer and I've tried the main window, but I'm not sure I like anything I've come up with yet.

PRs would be welcome!

[jezcope]

Oh, I'm glad it's not just me! I tried briefly yesterday but couldn't make it satisfactory. I'll submit a PR if make something I'm happy with.

[bbenne10]

I've been working to get this to a satisfactory point for me, but I'm having trouble wrapping my head around how to create the faces outside of the theme itself (so I can test the colors out before I modify base16-theme.el to craft a PR). I'll keep working and get something soon-ish.

[belak]

@bbenne10 I've got a use-package block in my dotfiles which sort of gives away how I do local dev:

https://github.com/belak/dotfiles/blob/master/emacs.d/README.org#base16-theme

The general idea is that I clone all packages I work on to ~/.emacs.d/site-lisp then add those dirs to the load-path and then require them, along with any other tweaks which need to be done.

One of the oddities is that all of the theme files are in the build dir, so that needs to be added to the custom-theme-load-path.

[bbenne10]

No progress, but mostly because I've forgotten. I might have some time this weekend to get around to it :P

[belak]

No rush. Thanks for following up! I've been a bit busy myself as well, so I can understand.

[bbenne10]

After 6 months of nothing, I have gotten frustrated enough with another color scheme that I wanted to come back to this problem. (I would also be lying to say that its not bugging me simply because this is "assigned to me" but I've not done anything about it)

To simplify the below discussion, I will assume we're always discussing modifying the colors for non-file-backed buffers only. Base16's concepts are pretty strict and I would say that this applies to "editors", which traditionally means "editors editing files" so I feel this is a decent assumption.

I see a few complications for implementing this in such a way as to not look like crap. Base16's general scheme is REALLY narrowly defined. Solaire somewhat requires a bit of...tinting to make the non-file based buffers stand out from file-backed ones but at the same time not burn your retinas out. This is difficult to do when you're limited to 16 colors.

This is further complicated by the fact that the global base16 colorscheme uses the bottom-most color as the "background" which means that there's no way to go "darker" (or "lighter" in light themes). (there's no "base-01" to fall back to, essentially).

What I might propose is a way of slightly darkening a provided hex color (such a function can sort of be found here, though this operates at point and replaces the contents rather than evaluating to the color in question. but the basic functionality is there).

For instance, I have hacked solaire support onto the zerodark theme. It looks like this (ignore that I'm an idiot and mis-hit my dmenu-bind and so am searching for a project :P)

I feel this looks pretty decent and would port pretty well into base16 if we could add the additional colors to support it. A remaining question would then be "Is darkening like this the right answer for light themes?". I have no idea (I despise light themes in general, so it'd be hard for me to judge), but it's a good place to start.

HOWEVER, one might argue that this attacks the very idea of base16 (and can't REALLY be done portably between implementations of the base16 schemes, since using this at a shell without truecolor support would essentially be impossible). In that case, I don't think solaire-mode's goals are in line with the base16 project, and I don't think there's really a resolution to that problem.

So what does this mean practically? If there's no objection, I'll probably implement a basic "darken by 10%" function that takes a color and returns a darkened version and use that globally until someone comes along and complains. Once that happens, we can have a discussion about a more nuanced solution. Anyone have thoughts here?

[belak]

That seems reasonable to me. I think stuff like that is fine as long as it's used sparingly and there's a good reason for it, both of which seem to fit this situation. The other option is a function to mix colors, which might be more flexible (if that's too complicated don't worry too much). Your proposed solution could also provide a better option for diff colors.

A few things to note: it's a little hard to put function calls into the theme itself so they might go well where we handle settings... And I'm not sure how to handle darkening when in the terminal... Might have to only enable it if you're using >= 256 colors. I'd be happy to help with the plumbing for that if you need it.

[bbenne10]

Okay! I've finally (FINALLY) found a day to sit down and work on this!

My first approach was to add solaire-mode faces that make some sense into base16-theme-define and adding a new defcustom for making them look distinct. I'm not sure this resolves the problem of running at a terminal though because we're looking at a specific color/key combo in base16-transform-color-key (and thus have already been passed the modified color map)

Another solution is to simply offer a function that can be called to MODIFY the already specified theme. In this case, we can fix the terminal colorscheme problem by lifting the issue to the user space

(require 'base16-theme)
(load-theme base16-gruvbox-dark-medium)
(if 'display-graphic-p
  (base16-inject-solaire-faces) ;; or something
)

This is, however, not in line with the rest of the customizations offered by this theme group already.
I have started pursuing this approach, as it solves most of the integration problems pretty nicely, even if it is inconsistent with existing code.

In this second approach, we simply use defface and do some mucking around with the color variables to assign custom colors. @belak: Thoughts?

[bbenne10]

Just an update: So I have a basic implementation of the color modification (i've yet to build the faces, but that's not going to be difficult, so I'm leaving it till last). I had, however, forgotten the case where the source color isn't a hexadecimal color but rather a built-in color name. There's a path forward for these cases (color-name-to-rgb in color.el, but divide by 65535.0 to scale between 0 and 1), but the hard part is detecting them as my current approach assumes that the input is either an rgb list ((1.0 0.25 0.75)) or a hexadecimal string to convert to an rgb list.

I'm implementing a regex based solution that should fix this issue, but it's taking a while...I'm definitely feeling the fact that elisp was born in 1985. I should have something to show this evening after dinner.

[belak]

One thing I've been thinking about - and I don't know why I didn't think of this before - you can call base16-set-faces multiple times. Would it work to just call that multiple times in base16-theme-define with different values depending on the settings?

[bbenne10]

Oh! I didn't recognize that base16-set-faces could be called multiple times. That'll make integration with a defcustom much easier.