Skip to content
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

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

JustinHallquist
Copy link

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 symbols

This 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

dir_suffixes:
  _suffix1: blue
  .suffix2: green

all directories ending in _suffix1 and .suffix2 will have the respective color

default

can remove

_venv:  royalblue

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?

@harmnot
Copy link

harmnot commented Oct 24, 2018

should we put
dir_suffixes:
_suffix1: blue
.suffix2: green
on yams file?

to make other dirs coloured ???

@JustinHallquist
Copy link
Author

@harmnot it can be added to either the user config or the yaml in the project:

      @filepath = File.join(File.dirname(__FILE__),"../yaml/#{filename}")
      @user_config_filepath = File.join(Dir.home, ".config/colorls/#{filename}")

I am fine removing the example here in lib/yaml/dark_colors.yaml and solely leaving it up to the user to implement it in their own config.

@securisec
Copy link

actually leaving the example is not a bad idea. as an example, because it supports . suffix, that line could be a different shade of blue to show hidden dirs as a lightly different color. and then from there user decides how else to scale it.

i tried cloning this repo, building with rake, and then getting a ghastly error message. Otherwise super excited for this to get merged.

Traceback (most recent call last):
	9: from /home/ubuntu/.linuxbrew/bin/colorls:23:in `<main>'
	8: from /home/ubuntu/.linuxbrew/bin/colorls:23:in `load'
	7: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/exe/colorls:5:in `<top (required)>'
	6: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/exe/colorls:5:in `new'
	5: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/lib/colorls/flags.rb:24:in `initialize'
	4: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/lib/colorls/flags.rb:168:in `parse_options'
	3: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/lib/colorls/flags.rb:176:in `set_color_opts'
	2: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/lib/colorls/yaml.rb:16:in `load'
	1: from /home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/lib/colorls/yaml.rb:16:in `map!'
/home/ubuntu/.linuxbrew/lib/ruby/gems/2.5.0/gems/colorls-1.1.1/lib/colorls/yaml.rb:16:in `block in load': undefined method `to_sym' for {"_venv"=>"royalblue"}:Hash (NoMethodError)
Did you mean?  to_s
               to_set

@JustinHallquist
Copy link
Author

JustinHallquist commented Oct 25, 2018

@securisec looks like you're on the wrong branch (line 16 is no longer map!) -- could you make sure you're on add-custom-dir-suffix-colors before running the rake install? I think that should clear up the issue

@securisec
Copy link

yes right, wrong branch. looks awesome!

@harmnot
Copy link

harmnot commented Oct 27, 2018

@JustinHallquist my dark_color.yaml

Main Colors

unrecognized_file: gold
recognized_file: lavender
dir: salmon

Access Modes

write: darkkhaki
read: limegreen
exec: red
no_access: indianred

Age

day_old: mediumspringgreen
hour_old: lime
no_modifier: seagreen

File Size

file_large: orange
file_medium: gold
file_small: peachpuff

Random

report: white
user: moccasin
tree: cyan
empty: yellow
error: red
normal: darkkhaki

Git

addition: chartreuse
modification: darkkhaki
deletion: darkred
untracked: darkorange
unchanged: forestgreen

dir_suffixes: pink
_suffix1: blue

after save, it got error

@securisec
Copy link

@harmnot your dir_suffixes: pink does not seen right. Try removing pink from it.

@JustinHallquist
Copy link
Author

yaml use indentation to denote structure.

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: hello.tmp.rb and hello.tmp
that yaml, without namespacing, would look like:

#flat hierarchy, cannot differentiate

.tmp: color_1 #the file type
.tmp: color_2 #the suffix

a hash representation would look something like this:

{
  .tmp: color_1,
  .tmp: color_2
}

to address that in yaml, we indent. for the case of this PR we use dir_suffixes as the namespace, indentation to denote it's a part of that name space, and key values to represent the suffixes and colors:

#namespace hierarchy, can find values correctly

.tmp: color_1 #the file type
dir_suffixes:
  .tmp: color_2 #the suffix

a hash representation would look something like this:

{
  .tmp: color_1,
  dir_suffixes: {
    .tmp: color_2
  }
}

for your case above:

addition: chartreuse
modification: darkkhaki
deletion: darkred
untracked: darkorange
unchanged: forestgreen

dir_suffixes:
  _suffix1: blue

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.

@JustinHallquist
Copy link
Author

Any status on the state of this PR?

@securisec
Copy link

@JustinHallquist any config or how to use changes on these new commits? i have been using your first version and it is very stable

@JustinHallquist
Copy link
Author

@avdv hey so after pulling in master I noticed we added Forwardable in the last few weeks but never included it which was throwing an error when I tried to build.

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?

@JustinHallquist
Copy link
Author

@securisec just merged in master and dealt with some conflicts while waiting on this merge. No new changes in terms of features.

@avdv
Copy link
Collaborator

avdv commented Nov 20, 2018

@avdv hey so after pulling in master I noticed we added Forwardable in the last few weeks but never included it which was throwing an error when I tried to build.

Yeah, I noticed that too. Bundler requires forwardable itself so tests were green.

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?

Sure, that would be good. 👍

I promise to give you a review next. 🤞

@JustinHallquist
Copy link
Author

JustinHallquist commented Nov 20, 2018

@avdv forwardable addition is in this pr: #239

i'll deal with the merge conflict afterwards since it'll be trivial.

@ghost ghost assigned avdv Dec 29, 2018
@ghost ghost added the review label Dec 29, 2018
Copy link
Collaborator

@avdv avdv left a 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.

name.end_with? suffix[0].to_s
end

suffix_arr ? @colors[:dir_suffixes][suffix_arr.first] : @colors[:dir]
Copy link
Collaborator

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.

Copy link
Author

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

group = :folders
color = dir_color(content)
key =
if @folders.include?(key) && @folder_keys.include?(key)
Copy link
Collaborator

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@JustinHallquist
Copy link
Author

sorry for the delay, will get on that

@codecov-io
Copy link

codecov-io commented Jan 22, 2019

Codecov Report

Merging #231 into master will increase coverage by 0.56%.
The diff coverage is 100%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
lib/colorls/core.rb 89.27% <100%> (+0.48%) ⬆️
lib/colorls/yaml.rb 90% <100%> (+4.28%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5804f92...de87d0d. Read the comment docs.

@JustinHallquist
Copy link
Author

@avdv bumpity bump
anything I am missing to close this out?

@avdv
Copy link
Collaborator

avdv commented Mar 13, 2019

@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 *_venv folders... 🤔

@JustinHallquist
Copy link
Author

@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 __tests__ in each sub dir to pop, then I can just add the whole folder name to the yml and it'll match since the whole name is a valid suffix and apply the color.

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 lib/colorls/yaml.rb extends the yamls to allow for nested attrs and that alone could be a benefit for future features.

Just let me know how you want to proceed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants