Comments (12)
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!
from base16-emacs.
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.
from base16-emacs.
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.
from base16-emacs.
@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
.
from base16-emacs.
No progress, but mostly because I've forgotten. I might have some time this weekend to get around to it :P
from base16-emacs.
No rush. Thanks for following up! I've been a bit busy myself as well, so I can understand.
from base16-emacs.
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?
from base16-emacs.
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.
from base16-emacs.
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?
from base16-emacs.
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.
from base16-emacs.
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?
from base16-emacs.
Oh! I didn't recognize that base16-set-faces
could be called multiple times. That'll make integration with a defcustom
much easier.
from base16-emacs.
Related Issues (20)
- Update base16-theme-256-color-source to use symbols, not strings
- fix command spell mistake in README HOT 2
- Emacs doesn't update colors with updated theme until I restart Emacs HOT 3
- Org todo/done faces match some heading faces HOT 2
- Foreground base04 is unreadable on background base03 with onedark theme HOT 4
- Solaire mode support HOT 15
- Weird black block when using global-display-line-numbers-mode HOT 1
- dired mode background color HOT 1
- Face definition by indirection — define base16 named colors, or faces to inherit from? HOT 5
- git changes on fringe HOT 2
- Tomorrow Theme Terminal Colors HOT 3
- ansi-term-color-vector improperly overridden HOT 2
- Warning (comp): base16-theme-pkg.el:7:1: Warning: the function ‘define-package’ is not known HOT 1
- font-lock-comment-delimiter-face = base02, which is for selection background
- Increase selection contrast on tomorrow day theme
- base16-emacs breaks on zoom when global-display-line-numbers-mode
- Maintainers outside of base16-project HOT 1
- Add support for `tab-bar`
- Doom Emacs support
- Some colorschemes are missing when compared with base16-vscode HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from base16-emacs.