-
-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yaml based theme support #452
Conversation
Codecov Report
@@ Coverage Diff @@
## master #452 +/- ##
==========================================
+ Coverage 80.71% 82.16% +1.45%
==========================================
Files 35 36 +1
Lines 3449 3494 +45
==========================================
+ Hits 2784 2871 +87
+ Misses 665 623 -42
Continue to review full report at Codecov.
|
5ce8ade
to
9918fc9
Compare
@meain there is a theme config previously, we use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @zwpaper , we had never exposed --no-lscolors
to the user. It was an internal only thing.
Even if we implement themes via config file, we should still have LS_COLORS
used by default as that will work better with user's existing terminal colors. All they would need to override this would be to specify a theme in the config file. I believe most people will expect LS_COLORS
to work as that is a more general standard across multiple tools.
Also, I think we should let the user configure the values of non-name blocks via the config file but still let them use LS_COLORS
for the name block. There are projects like trapd00r/LS_COLORS which has great support for coloring files based on their extension etc. I am not exactly sure as how to approach this yet though.
Two more things:
|
waiting on this PR ogham/rust-ansi-term#71 |
As we were blocked by the I will do some tests and benchmarks for the change later |
new PR created crossterm-rs/crossterm#576 |
status update, I have reimplemented the theme support based on I will then work on the tests and make sure not to break the original functions. |
Codecov Report
@@ Coverage Diff @@
## master #452 +/- ##
==========================================
- Coverage 88.44% 86.72% -1.72%
==========================================
Files 36 37 +1
Lines 3540 3790 +250
==========================================
+ Hits 3131 3287 +156
- Misses 409 503 +94
Continue to review full report at Codecov.
|
Any updates about this PR? Can't wait to have custom theme support. Thanks! |
pin bitflags dependency to |
hi @meain, I have done this implementation, could we leave the code coverage for later improvement. and for the comment:
|
finally, this one-third year PR is coming true 🤩 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
new issue created for the |
Hey, I was looking more into the original color issue that I was talking about. The color values being outputted is different. From what I can tell, old one was using default colors and the new one is using bright colors. If the shell is set up with different normal and bright colors, this will cause issues.
new:
old:
Something like this seems to fix the color issues visually, but the output is still different between the two: Dropping this here for reference: https://misc.flogisoft.com/bash/tip_colors_and_formatting |
Also, lscolors supports |
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
Signed-off-by: zwPapEr <zw.paper@gmail.com>
@meain I have changed to dark color, for the consistency with the older version. for the lscolors supported crossterm part, there is not yet a released version supporting the crossterm, I created an issue for a newer version sharkdp/lscolors#34. I also noticed that the lscolors map its red to the red both but the choice of default colors would be a new problem. |
btw, I think we could make theme happen and do not have to wait for the sharkdp/lscolors#34, we can change to the lscolors implementation any time later. |
Looks great, I think we are good unless you have something else to add/tweak. |
hi @meain, I have done the jobs in my mind currently, let's make this real now! we can add the others in other PRs. |
Awesome, thanks a lot @zwpaper for working on this. |
fix #92
related: #365