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

bug: eza assigns icon from config-file's filenames and extensions to matching directories #1116

Open
hasecilu opened this issue Sep 4, 2024 · 3 comments
Labels
errors Something isn't working

Comments

@hasecilu
Copy link
Contributor

hasecilu commented Sep 4, 2024

Icons from config file are assigned to directories on match, that doesn't happen with built-in filenames and extensions. Bug or easter-egg? =P

  • The version of eza being used: (v0.19.2), compiled from latest main branch, config file here.
  • The command-line arguments you are using: eza -l --icons --group-directories-first testing
  • Your shell and terminal: Alacritty 0.13.2 with tmux 3.4 using zsh 5.9
  • Your operating system and hardware platform: Arch Linux, x86_64 GNU/Linux

image


@hasecilu hasecilu added the errors Something isn't working label Sep 4, 2024
@gierens
Copy link
Member

gierens commented Sep 6, 2024

Bug or easter-egg?

At the moment this is expected behavior. For both filename- and extension-based style overrides Theme.style_override just matches on File.name and File.ext not taking into account File.is_directory.

The reason is simple: To keep it simple. The filenames section in the theme.yml is at least for now supposed to be used for both files and directories. The assumption is, that most users likely want to use overrides for files and those that also wanna use it for directories will likely not have overlapping cases of special file- and directory names. Sure, this is a heuristic and does not fit all cases, but that was the trade-off made.

If we were to advance this to distinguish between directories and files, we would have to discuss how we handle this both in the theme file and in the code. Do we add another HashMap? Do want a separate section directory_names or do we require a trailing / for directory names? How do we handle symlinks? Are they just files or do we want to distinguish by what they are pointing to, which might introduce overhead?

So there are quite a few things to consider and discuss, but at least I am not (yet) convinced that the, I believe, few edge cases warrant the discussion, design and implementation effort. I think we should let this big new feature settle first. Let users discover it, see how they make use of it, and let feedback flow back to us, so we later actually know how to improve it best.

But that's only my opinion on this, maybe the others like @PThorpe92 think differently about this.

@hasecilu
Copy link
Contributor Author

hasecilu commented Sep 6, 2024

At the moment this is expected behavior. For both filename- and extension-based style overrides Theme.style_override just matches on File.name and File.ext not taking into account File.is_directory.

I assumed that filenames was targeted only to files and not directories in the same way as in icons.rs file the directory and file icons are separated in 2 mappings.

I mentioned it because the docs didn't mentioned directories nor the example config file had a directory example.

... as well as the option to specify different icons for different file types and extensions.

Icons can now be customized as well in the filenames and extensions fields

Maybe mentioning the directories on docs should help.


Regarding the extension match, certainly is an edge case, I found it first while extracting compressed file that created a directory including the extension of the file, certainly not expected, so the dir got the extension icon; then when trying icons on .git and .cache files also the dirs got icons. This behavior don't cause inconveniences, it just that is not documented so I though on mentioning it. Maybe a "discussion" was a better choice.

@PThorpe92
Copy link
Member

I see what you mean, I agree and think it is probably fine the way that it is.. Unless there turns out to be a particularly common example of a directory that is named the same as a file in which one would want to distinguish.

Maybe something gets added to the documentation to clarify that this is the expected behavior?

Glad to see people are using the feature 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants