-
Notifications
You must be signed in to change notification settings - Fork 388
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
Add custom dir suffix colors #231
base: main
Are you sure you want to change the base?
Add custom dir suffix colors #231
Conversation
should we put to make other dirs coloured ??? |
@harmnot it can be added to either the user config or the yaml in the project:
I am fine removing the example here in |
actually leaving the example is not a bad idea. as an example, because it supports i tried cloning this repo, building with rake, and then getting a ghastly error message. Otherwise super excited for this to get merged.
|
@securisec looks like you're on the wrong branch (line 16 is no longer |
yes right, wrong branch. looks awesome! |
@JustinHallquist my dark_color.yaml Main Colorsunrecognized_file: gold Access Modeswrite: darkkhaki Ageday_old: mediumspringgreen File Sizefile_large: orange Randomreport: white Gitaddition: chartreuse dir_suffixes: pink after save, it got error |
@harmnot your |
for the case of these changes we wanted to ensure the added keys were namespaced properly or else it wouldnt be possible to determine the difference between a suffix and any other entry. an example would be something such as:
a hash representation would look something like this:
to address that in yaml, we indent. for the case of this PR we use
a hash representation would look something like this:
for your case above:
please let me know if you have any more questions or if there is anything else regarding these changes you would like to go over. |
Any status on the state of this PR? |
@JustinHallquist any config or how to use changes on these new commits? i have been using your first version and it is very stable |
@avdv hey so after pulling in master I noticed we added I added that change in this PR but, assuming you can validate that bug, do you want me to move it to a separate fix? |
@securisec just merged in master and dealt with some conflicts while waiting on this merge. No new changes in terms of features. |
Yeah, I noticed that too. Bundler requires
Sure, that would be good. 👍 I promise to give you a review next. 🤞 |
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.
@JustinHallquist Please fix the rubocop offenses and see my comments.
lib/colorls/core.rb
Outdated
name.end_with? suffix[0].to_s | ||
end | ||
|
||
suffix_arr ? @colors[:dir_suffixes][suffix_arr.first] : @colors[:dir] |
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.
The color is in suffix_arr[1]
, no need to fetch it again from the @colors
hash.
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.
thanks for pointing that out, updated
lib/colorls/core.rb
Outdated
group = :folders | ||
color = dir_color(content) | ||
key = | ||
if @folders.include?(key) && @folder_keys.include?(key) |
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.
@folder_keys
is gone. And this is dead code, since key
was never defined, so the condition will never be 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.
updated
sorry for the delay, will get on that |
Codecov Report
@@ Coverage Diff @@
## master #231 +/- ##
==========================================
+ Coverage 84.52% 85.09% +0.56%
==========================================
Files 7 7
Lines 420 436 +16
==========================================
+ Hits 355 371 +16
Misses 65 65
Continue to review full report at Codecov.
|
@avdv bumpity bump |
@JustinHallquist I think we should add some documentation about this to the README into the "Custom configurations" section. Also add a dir_suffix section to the light_colors.yaml file to keep it aligned to the dark_colorls.yaml file. Or should we remove it altogether? But an example of the usage would be good to have. BTW, do you have some other examples for dir suffixes that could use a different color? Maybe there is something more common than |
@avdv absolutely agree about the documentation -- will throw an update in the "Custom configurations" section. I think removing it altogether makes sense as it should be on the consumer to determine which folders they want to stand out and the option will be documented for them to figure out how to do it. Otherwise it could be confusing as to why just that one folder in this pr has a different color. I wouldn't be the best person to enquire around examples for this as I haven't a use case for dir suffixes. I'd personally prefer a prefix or regex matcher but that's me. The feature request was up and open source is powered by everyone chipping in 😄 However, everyone does handle their file systems differently so there are probably use cases that are eluding me such as cases, probably more common to devops, where folders are generated at fixed intervals by different services and tagging them and applying this could help with differentiation. It's possible that this could end up being used as a fast implementation of single folder coloration. If I have a react app and I want I default to you on any concerns and necessities around the implementation of this, as well as requests for expanding scope or calling this an edge feature and abandoning. Though I would add that the addition to Just let me know how you want to proceed. |
Description
This adds two things, one is a framework enhancement and the other is a feature request
Nested yaml structures
The framework enhancement is adding the ability to have nested
yaml
structure. Originally we convert all values in our yamls to symbols, but that was done at a flat depth -- keys were already symbolsThis PR replaces that with a method that will convert all key/values to symbols at any depth so we can nest structure in our yamls
dir suffixes
This PR also adds the ability for users to specify custom dir suffixes
If a yaml has a structure that looks like
all directories ending in
_suffix1
and.suffix2
will have the respective colordefault
can remove
as a default if wanted
tests
are there any additional tests we want added for this change if we go with it?
documentation
what documentation, if any, would you like if we accept these changes?