Closed kfilippenok closed 2 weeks ago
I added a development branch to this issue, where I've added color highlighting for and glyphs for executable files and file archives, I'm planning on adding for media types (video, audio and images) but is there more that can be added?
I added a development branch to this issue, where I've added color highlighting for and glyphs for executable files and file archives, I'm planning on adding for media types (video, audio and images) but is there more that can be added?
You can also add for:
This is difficult to implement correctly because you either need a static hash table for these types (note that the types are not the correct mime types, so you can't just use MIME checkers and that will be bad pattern to hardcode such things) or use the user's predefined OS settings for extensions (because you don't have to decide for the user which app/mime is bound to these extensions). Maybe you can use .rc file for mime/ext and gylph/color pairs.
For example look as different types processed in ls: https://github.com/coreutils/coreutils/blob/master/src/ls.c It checks LS_COLORS and terminal colors
parse_ls_color (void)
{
char const *p; /* Pointer to character being parsed */
char *buf; /* color_buf buffer pointer */
char label0, label1; /* Indicator label */
struct color_ext_type *ext; /* Extension we are working on */
if ((p = getenv ("LS_COLORS")) == nullptr || *p == '\0')
{
/* LS_COLORS takes precedence, but if that's not set then
honor the COLORTERM and TERM env variables so that
we only go with the internal ANSI color codes if the
former is non empty or the latter is set to a known value. */
char const *colorterm = getenv ("COLORTERM");
if (! (colorterm && *colorterm) && ! known_term_type ())
print_with_color = false;
return;
}
......
It is better to be an additional function for the user, such as an argument or a compilation flag. The CLI tool should be quick to read and depends only on basic common user-space conditions. LS_COLORS or colors of terminals can be a source for a better approach
I do agree, the usage of an environment variable would be a lot better I will implement that instead of the compilation flag, I've looked at a couple other ways to refactor it but, the environment variable seems best 👍
Please note that not all terminals or environments support a color palette larger than 16 colors.
I have updated the color for file to be [0m
by default so it supports terminals without extended ansi colors. And the colors are customizable now by the environemnt variable, so adding support for 8 color terminals could be done by setting the env var, I do not believe it is necessary to support it by default.
What is the need to remove the default icon display? I think this is the key feature of this utility, and it should be enabled. Now it is necessary to register export. In addition, the specified example does not work for folders:
What is the need to remove the default icon display?
I believe that it'd give more flexibility to use other glyphs rather than having to rely on nerd fonts, from the issue on #6. This would offer the possibility to use your own glyphs and font.
In addition, the specified example does not work for folders
Ive updated the README.md to work with the glyphs that I personally use. It looks like this now:
export LSR_COLORS="DIR=\x1b[34m :\
SYMLINK=\x1b[36m :\
FILE=\x1b[0m :\
HIDDEN=\x1b[90m :\
EXEC=\x1b[32;4m :\
ARCHIVE=\x1b[31m :\
MEDIA=\x1b[33m :\
DOCUMENT=\x1b[35;3m :"
I'm unsure of using these as default as a terminal without a nerd font would've make the output look very bad.
Hi! There is a great lack of visual display of whether the file is executable, whether it is an archive, etc. In the basic ls, this is implemented through the backlight:
In lsr, it can be made in the form of modified glyphs, and additionally even highlighted.