ranger
Adding a new colour scheme to parse $LS_COLORS
Following the discussion from https://github.com/ranger/ranger/issues/169#issuecomment-406814926
Plugin and colour scheme to parse the $LS_COLORS
The colour scheme still needs some work. It works for the extensions (such things as *.txt), but doesn't work for special files (denoted di, ln, ...)
os.stat.st_nlink can be used to determine if a file is a hard link. I don't know if we get access to the file path in the color scheme though. Probably other special file types can be polled with the same method.
@Nelyah, pinging you about this. It's something many people've wanted so it'd be great if you could fix this up/or rationalize why it can't be fixed up so we can merge this : )
Thanks for the reminder, I had indeed left it all a bit behind. I'm working on it right now, and I will probably give a more detailed update later (hopefully tonight). :)
I pushed another commit, which should properly parse the LS_COLORS. Let me know if it works for you.
I added as well device and socket colouring, however it seems to be more than just doing a os.stat on the file. From what I have seen, I should look into the container/* directory for directions about how to handle other specific kind of UNIX files.
As of now, the colour scheme recognises:
- executable
- fifo
- link
- Block Device and Character Device
- Socket
- Directory
- all specified extensions
I specifically added a rule to prevent the directory from being coloured since they (mostly) are exectuable.
Also, one issue I've been running into (but which seems irrelevant to this issue), is ranger not having the LS_COLORS variable properly set. If you intend to use ranger as a default file manager, the LS_COLORS value should be available session wide, and not only from the shell.
Briefly testing this seemed to work. About the plugin, what's your reasoning for having that code in a plugin? (I'm just thinking about simplicity of distribution it'd be easier if there was only one file. Otherwise we have to completely rethink the colorschemes repo ; )
I originally followed the documentation which was suggesting to define new context tags from the plugin folder.
However, I put the code from the plugin file to the colorscheme one and it seems to work. I pushed the last version with the colorscheme file at the top level of the git repo so you wouldn't have to reorganise it :)
edit: Also added a rule to no colour links as executables (same as with ls I believe).
I removed the try/except block inside the class.
That also made me think about the necessity of putting some code outside the class itself. Do you think it would be a good idea to put the "global" code in an __init__ function inside the class (which I should probably rename ls_colors)?
This would probably allow for better interaction with potential plugins.
Maybe keeping it in the class is better yeah. That way themes based on this one can override the behavior. And I agree about the name. It's not necessary but it's nicer when people start extending your colorscheme.
I haven't had much time these past few days, just to let you know I have not forgotten it. I'll try to get on to it this week-end!
I (finally) added the code correctly, and called the super for the Colorscheme class (compatible python2).
As mentionned in the commit, I also fixed an issue that would make files highlighted if they ended with the extension (but without the .). For instance, considering the extension .bar, the file foobar shouldn't get coloured while foo.bar should.
Awesome. I'll be taking a look at getting this installed locally soon. Also eagerly awaiting this being added to master.
I just want to let you know that I'll go for an extended (~1 year) trip around the world and since I like to travel light I won't have any computer (except a smartphone), which means I won't be able to patch should any issue arise.
I'm leaving on the 28th of October, and on the case where we haven't resolved this PR by then someone will have to take it up from there (I could add that someone as a contributor to my repo).
@Nelyah, no problem. We already have access to your repo because of the PR. I'm only waiting for @Vifon to verify the earlier issues were resolved. This should be merged before you leave.
Currently it works great. Just one nitpick: the tags are no longer in a distinct color. Is that intentional?
I have found 3 more problems:
- the selection doesn't seem to get highlighted
- if I name a directory for example
something.png, it gets colored as a directory but it's bold since the PNG files are bold in my config - if a file has a colored background, it behaves strangely in ranger
I guess @Nelyah has left for their trip. I'll try to see if I can find time to pick up the slack. I very much want to see this landed.
@Vifon @toonn I'm working on some fixes for your comments. Since this isn't my PR I can't push to it. Should I send a separate PR?
@rpdelaney, I don't think there's a better way, just refer to #2 in your PR so they're both linked.
@rpdelaney I'm not able to code anymore at the moment but I could add you to the contributers?
@Nelyah has added me to their fork, so I'll be able to update this PR as I get the time. Thanks Nelyah.
@toonn I've tested it again as you asked and the selection problems seems to be gone. The one with the bold files is still valid and I don't have anything to test the background coloring on right now.
Anyone who could review this? I'm using it with this patch but would love to have it in the official build.
@rightaway, there's some remaining issues:
- dir.png will be colored as a png rather than as a directory
- @Vifon talked about funky behavior for items with a colored background
- We need to decide on how to handle tag contrasting, should tags contrast to yanked/cut files, marked files?
I've been using this for month and it is working great.
It should be merged in my opinion, even if there are still issues, it is just an optional theme, and it is better than the status quo.
Good to hear. The issues I listed still have to be resolved before I'll consider merging this. I'll try to pick it up again soon™.
We need to decide on how to handle tag contrasting, should tags contrast to yanked/cut files, marked files?
Can you say more about this?
Tags in the default theme contrast to the files they tag, they're red while the files are colored variously iirc. But this isn't true when the file is marked or highlighted or in the copybuffer.