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

[Feature Suggestion] Custom icons for files and folders #343

Closed
j-maynard opened this issue Apr 7, 2020 · 8 comments · Fixed by #707
Closed

[Feature Suggestion] Custom icons for files and folders #343

j-maynard opened this issue Apr 7, 2020 · 8 comments · Fixed by #707
Labels
kind/enhancement Enhancement on current feature

Comments

@j-maynard
Copy link

I can think of many ways to implement this but simply put I'd like to have a mechanism for assigning custom icons to files and directories and overriding those already defined within LSD. I'd also like to be able to configure LSD to match its directory icon assignment and this feature suggestion would allow me to do that. See the example below to see the difference between colorls and LSD:

image

As for implementation the two ideas I have are to either have an LSD config somewhere where these options can be defined along with the request to configure colors which has been suggested in the past. Alternatively would be to follow my suggestion for .hidden files. Define a file format in say a .icon or .lsd file which specifices either an icon or hex which people can get from https://www.nerdfonts.com/cheat-sheet followed by the name of the file they want to change. The best maybe to support both options.

@meain meain added the kind/enhancement Enhancement on current feature label Apr 17, 2020
@KSXGitHub
Copy link
Contributor

I prefer this feature work out-of-the-box. If a it has to be configurable, I would prefer global configuration (e.g. ~/.config/lsd/something.json).

@j-maynard
Copy link
Author

I prefer global configuration as well generally not least of all I can throw it in to my dot-files repo and have the same experience wherever I work.

@neezer
Copy link
Contributor

neezer commented Aug 17, 2021

I'd also love this feature, but IMO it should support wildcards for the filename. As an example, I have a folder with a bunch of Dockerfiles in it that all have various extensions, eg.

Dockerfile.eslint
Dockerfile.prettier
Dockerfile.typescript-language-server
...

In vim, I have one autocmd to correctly set the filetype for all of them:

autocmd BufRead,BufNewFile Dockerfile.* set filetype=dockerfile

Would be great if I could do the same for lsd so they all have the Docker icon without requiring me to name them all explicitly.


The best maybe to support both options.

👍 on this suggestion, with the understanding that local .hidden files supersede the top-level configuration.

As an example: this would help in JS projects with extension-less multi-format configuration files, eg. .eslintrc or .prettierrc. These can be configured with JSON or YAML (or in some cases TOML), so I could set a top-level default icon for whatever I think they should be, then override on a per-project basis.

@zwpaper
Copy link
Member

zwpaper commented Aug 18, 2021

after we support the color configuration in #452, I will try to look into this. A global configuration for icons would be the basic implementation, and we can keep discussing the necessity of local .lsd here.


we should discuss this feature here.

As I can figure, it should support the match by:

  1. filename
  2. custom extension
  3. file type
  4. default

There is some more feature we need to discuss, I would add some comment for each feature, if you would like the feature to be implemented, please add and 👍(+1) emoji on that comment, and we can discuss base on the count.

if there is some other feature you would like to be implemented, please explain and let people add +1 for it.

@zwpaper
Copy link
Member

zwpaper commented Aug 18, 2021

prefix by dot match

like the custom extension, but for prefix, like matching Dockerfile.*, log.*.

please notice it must be split by dot ., there would be no much cost to support this feature.


if you would like this feature to be implemented, please add and 👍(+1) emoji

@zwpaper
Copy link
Member

zwpaper commented Aug 18, 2021

regex match

it is a much more general match mechanism, could nearly be used to match all the cases,
but please notice there would BE a performance impact if the number of regex matches grows.


if you would like this feature to be implemented, please add and 👍(+1) emoji

@zwpaper
Copy link
Member

zwpaper commented Aug 18, 2021

local configuration

it could overwrite the global configuration if some file like .lsd existed.

but the cost is:

  1. we have to try to read one more configuration for each excution
  2. how do we choose the local file, base on just the local dir, or git project, or some others

for 2., js project, or some other project having .xxrc file, there is a project concept on it, they could find rc file on the project root, but lsd did not case about projects, It may be a mess if we add .lsd everywhere, or not that worth to look for the project root.


if you would like this feature to be implemented, please add and 👍(+1) emoji

@neezer
Copy link
Contributor

neezer commented Aug 18, 2021

Thanks for the breakdown on the options, @zwpaper ! 👏

how do we choose the local file, base on just the local dir, or git project, or some others

I'd say the first pass should only check the directory you're trying to list and nothing more. In my experience .xxrc files live predominately at one level of a given project, so there's rarely a need to re-use the same definitions deeper in the hierarchy. But maybe I don't have much experience with those projects that would have these kinds of files all over the place, so 🤷 ?

IMO—despite the possibility of "be[ing] a mess if we add .lsd everywhere"—in practice I'm not sure it would actually be that bad. I agree lsd should not care about the concept of a project.


Another option to consider would be to add a section in the top-level configuration that maps paths explicitly, eg.

overrides:
  - { is: json, path: ~/code/project-1/.prettierrc }
  - { is: yml,  path: ~/code/project-1/.babelrc }
  - { is: yml,  path: ~/code/project-22/.eslintrc }
  # ...

Sure, might be tedious, but I imagine it wouldn't add much overhead to implement, and may offer enough to appease those users who care—like me 😉. Looking over my 50ish local projects, I'd probably only need to add about 10 lines here personally. Also saves "reading one more configuration for each execution" and avoids littering .lsd files everywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Enhancement on current feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants