Comments (9)
To better frame why I would like it here's my workaround to set eat's faces:
(require 'term)
(let ((colors '("black" "red" "green" "yellow" "blue" "magenta" "cyan" "white"))
(dolist (color colors)
(set-face-attribute
(intern (format "eat-term-color-%s" color))
nil
:inherit (intern (format "term-color-%s" color)))))
Notice that I needed to load term
only because I needed its faces (I still haven't fully understood how emacs set faces when loads a theme).
from emacs.
Actually your are just looking for this theme to support eat :)
After a quick look, eat itself defines its colors as alias for other thing, which is great as it normally allows seamless integration without cluttering the theme. However, for the color you are looking for, it aliases ansi-color-*
and ansi-bright-color-*
which are not customized in the dracula-theme. We used to set the variable ansi-color-names-vector
but I can see it is now deprecated.
Thus, need to fix all that.
from emacs.
Yes that would be even better! I believe I can send a PR.
But at the same time I would like having access to colors directly. It would improve extendibility and hackability, would you also accept a PR adding new faces dracula-<color>
?
from emacs.
I just pushed a fix regarding ansi-color
definition. Can you try with the new version (as I pushed directly to main
branch, it should be available very soon through melpa repository. You can just pick the dracula-theme.el
file directly from the repository temporarily. Let me know if it’s better now or not (do not hesitate to send a screenshot).
Regarding opening dracula-<color>
variable, I’m not very convinced. This is not how Emacs theme work. If you encounter other issue with other mode/package, the best way to fix that is to support them inside the theme (to let other user benefit from the fix).
Nobody can know all possible Emacs packages out there, thus it’s better for everybody to report here missing packages, instead of having individual fixing missing part on their side just for them :)
And in any case, you’ll have better integration result by re-using some highlevel faces like font-lock-*
faces.
from emacs.
Regarding opening dracula- variable, I’m not very convinced. This is not how Emacs theme work. If you encounter other issue with other mode/package, the best way to fix that is to support them inside the theme (to let other user benefit from the fix).
Nobody can know all possible Emacs packages out there, thus it’s better for everybody to report here missing packages, instead of having individual fixing missing part on their side just for them :)
I agree 100% with both these things obviously but I still think that there should be a way to access the color palette somehow. While a PR upstream is always the best thing to do, it would make easier experimenting and playing with Emacs. I'm a novice so perhaps what I said doesn't make sense on the implementation side I expect a convenient way to get colors, not something like what I did.
And in any case, you’ll have better integration result by re-using some highlevel faces like font-lock-* faces.
Why? As far as I can understand they are not named after the color they represent. I would need to hardcode a map in my code. At this point I could simply copy/paste the colors
variable inside my configuration.
Anyway I've tried it, eat
uses different colors now but they are still different from what I expected. Indeed my goal was having same colors both on terminal emulator (wezterm with the official dracula theme) and emacs' eat terminal emulator.
This is how I see it letting eat use the ansi colors faces defined by dracula-theme in your latest commit:
This is how I see colors on wezterm:
And this is what I see using my manually defined eat-term-color-<color>
with my previous message's hack:
(Ignore the background color which I manually changed for some buffers using solaire-mode)
from emacs.
Thank you for the screenshot, it is exactly what I was willing to see (I’m not using eat at all).
It was just a quick test to see if I can improve the ansi palette or not. Quick explanation here: normally, on terminal ansi colors are defined as a serie of 8 colors, with to variation for each: "normal" color and "bright" color. However the dracula theme does not define any "bright" color and usually themers just copy paste the normal color on the bright one.
During my work on the Emacs theme, I found some situation in which this copy/pasting was no more sufficient (for exemple when dealing with diff output, which involve graduation of the same color). That’s why I previously added some "dark" colors. Those are the one you see in your screenshot.
I’ll change that and move to another idea: same colors for "normal" and "bright", but I’ll enforce a bold face for "bright" colors. It should be sufficient for texts.
I already pushed a new test. Can you check if it’s better now?
from emacs.
Much better, thanks! This is inside eat now using your latest commit:
But there is still something wrong, this is wezterm:
In particular the blue should be more pinky.
from emacs.
Yep, they are using the dracula purple color for blue, when I’m using the "comment" color for blue. That’s a mistake of mine, the term-color-*
also use purple for blue. Last commit should definitely be ok.
from emacs.
Just tried, blue is shown as purple, I believe this can be closed now. Thanks!
from emacs.
Related Issues (20)
- Weird inverse color for some faces HOT 1
- AUCTeX Support HOT 1
- Support diff mode HOT 4
- Set ansi-color-names-vector with theme colors
- Correct emacs-libvterm colors HOT 1
- How to change the background of selection hightlighting? HOT 3
- Unable to load color "unspecified-fg" HOT 1
- On `M-x` White font color on top of gray background confusing #497 HOT 4
- Is it possible to make configuration setup for ivy?
- light is too dark when matching brackets HOT 5
- The background on tooltips makes them unreadable HOT 5
- Deprecate master branch in favor of main HOT 3
- Adding support for tree sitter
- Fixing minor inconsistencies with markdown mode HOT 1
- Minor UI fixes HOT 1
- New face 'apropos-button'
- The icons in the breadcrumbs of lsp-mode cannot be displayed properly HOT 1
- Dracula theme for Emacs does not customize font-lock-number-face HOT 5
- Support Emacs 29.1
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 emacs.