Powerlevel9k: Request: Custom icons for custom folders

[KSXGitHub]

I didn't see any way to add icon for custom folders other than $HOME so I guess this is not implemented.

My idea is this:

First, I define an array of regex-icon pairs, like this:

POWERLEVEL9K_CUSTOM_FOLDER_ICONS=(
  ^${HOME}/Videos/ $video_icon
  ^${HOME}/Videos/YouTube/ $youtube_icon
  ^${HOME}/Music/ $music_icon
  ^/mnt/ $disk_icon
)

Then, powerlevel9k tests current-working-directory with each regex, when find a match, set the corresponding icon

P.S. This is the icon that I'm talking about

[bhilburn]

Hey @KSXGitHub - Wow, I like this idea a lot. It's a great way to further style the directory listing, and even provide something of a shortening strategy for common paths.

Your suggestion for implementing it is pretty straight-forward, I think. The biggest downside I can think of is that if the user defines a long list, we might be introducing too much latency with each prompt-redraw as it must compare to the list each time. Perhaps this could be mitigated by caching the cwd and only running through the list if we detect a change. So, basically, we incur the cost of a string compare vs a regex list traversal.

Thoughts?

[KSXGitHub]

The other way to implement this is to use YAML and Python. The downside of this method is that it is not straightforward, therefore harder to maintain.

Oh, why not just use Python? User provides a python code via variable POWERLEVEL9K_CUSTOM_FOLDER_ICONS_PYTHON that results an array of regex-icon tuples, p9k then use Python to eval() it.

[bhilburn]

Hm, calling out to Python, and adding another "language" (YAML) are things I would really like to avoid. Perhaps it's worth giving a go with the simple caching mechanism, and then profiling it to see how it performs. If it's still slow, then we can figure out how to be more clever with it.

@dritter - Any thoughts, here?

[jhriv]

I thought about this idea. What about dropping a logo into .directory_logo and having Powerlevel use that, if it exists? No arrays, and a simple check if a file exists.

[KSXGitHub]

@jhriv That too, is a great idea. The name .directory_logo should customizable via an environment variable named DIRECTORY_LOGO_FILENAME.

[KSXGitHub]

@bhilburn You previously said

The biggest downside I can think of is that if the user defines a long list, we might be introducing too much latency with each prompt-redraw as it must compare to the list each time.

It's users' choice, don't worry about that.

Perhaps it's worth giving a go with the simple caching mechanism

Maybe, but it's not always necessary, users don't always specify a list long enough to make a significant impact on performance. If the "simple caching mechanism" is actually not simple, it can wait.

[bhilburn]

@KSXGitHub - Agreed on the goal of avoiding premature optimization, but I also don't want to make it possible to slow your prompt to a crawl "on accident". If we add the feature, I just want to do it in a smart way =)

So, major problem with the directory_logo ideas is that we cannot render images in the prompt. It's just not possible. What you currently see are glyphs that part of fonts. If a glyph is in a font, we can use it. If it's an image, we can't. Otherwise, that's a great idea =)

I think @KSXGitHub's original idea of a simple array is probably best. Unfortunately, the dir prompt is already one of our most complicated due to the code for the various shortening strategies we support (see the prompt's code, here). This feature raises the possibility of yet another shortening strategy.

There are two ways I can envision people wanting to use this: as a decorator, and as a shortening strategy. For example, if you just want it is a decorator you might print something like:

~/downloads/music <music_glyph> <prompt>

You could also use it as a shortening strategy, though, and if you're in one of the listed directories just print:

<music_glyph> <prompt>

If we are going to implement one, it would be fairly easy to implement the other.

I think we have enough to start hacking on this, now, and I'd definitely like to see it get done. It's a great idea. I don't have time to get to it immediately, so if anyone else is interested in taking a crack at it, please let us know and then file a PR to get some code review comments!

[kabakakao]

I really love this idea. Any news?

[bhilburn]

I am on a issue-cleaning spree. This issue hasn't had motion in quite some time, and so I am closing it out due to inactivity. If anyone would like to re-open it because they feel it is un-resolved and is something they care about, please feel free to re-raise the discussion!

[jhriv]

Fair. I will make a fix and submit a merge request.

--
John H. Robinson, IV
[email protected][e-mail]

On Jul 17, 2019, at 18:37, Ben Hilburn <[email protected][e-mail]> wrote:

I am on a issue-cleaning spree. This issue hasn't had motion in quite some time, and so I am closing it out due to inactivity. If anyone would like to re-open it because they feel it is un-resolved and is something they care about, please feel free to re-raise the discussion!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/bhilburn/powerlevel9k/issues/606?email_source=notifications&email_token=AAUARE265QYIZOBFHME3WU3P77CODA5CNFSM4DXQ5KIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2HB36Q#issuecomment-512630266, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAUARE2CCNT5WTCE3X44PEDP77CODANCNFSM4DXQ5KIA.