I would like to suggest that the context segment be split into host and user segments for the following reasons:
路 host and user can be colored separately
路 we can add an icon to each (optional)
路 host can be made to change color/icon for local and remote hosts
路 user can be made to change color/icon for local user/root and remote user/root
路 it is easier for the end user to specify which to show than to learn the correct format required by POWERLEVEL9K_CONTEXT_TEMPLATE
I have added prompt_user and prompt_host to my repository. At the moment it does the following:
prompt_user
路 changes color & icon based on user / root
prompt_host
路 changes color & icon based on local / ssh
Any comments?

Thanks for your input @onaforeignshore . The stakeholders of such a change would be @bhilburn and @shibumi .
Btw. Your prompt looks nice!
That prompt is a beauty.
Hey @onaforeignshore - this is a really great idea! I'm re-opening this because I don't want to lose the item. I think this would be a really excellent improvement.
Can you file a PR against next from your fork? It would be great to start working on getting this merged. One item, though, is that we'll need to maintain the existing monolithic context so as not to break existing prompts. So, we would have three segments in total - context (current), and then two more that are individual.
@bhilburn so what's the difference to our current solution? Instead of a ssh prompt on the right we have an custom icon in front of the hostname + font-color changes. I definitly like this idea! The prompt looks awesome with the icons. I also like the style that he broke with the 'standard' USER@HOST prompt and did something like HOST>USER>PWD.
@onaforeignshore can you provide your custom .zshrc or changes? Would be nice to see it. I am curious now :)
Maybe you guys have also an idea for an icon for the virtualization-detection.. I thought about lightning first but we have this icon already for root.
One Suggestion: Instead of the terminal icon for remote-hosts we could also use a cloud icon. What do you think?
@shibumi - The piece of this that's different from what we currently have are a USER and a HOST segment, which are separate from the context segment. Everything else that @onaforeignshore has done in that screenshot is configuration of existing features :) (I think!)
@shibumi - I created two new segments for user and host, so context isn't used.
@bhilburn - also different is coloring the directory separator and changing the color / making bold the last directory in $PWD
@bhilburn I like the idea of seperating user and host and getting rid of context. What do you think about this? This would make the SSH part more simple and opens new opportunities.. also: do we have already bold support?
@shibumi - We can't get rid of context entirely because it will break backwards compatibility with configs. As soon as we get the separate segments merged, though, we can move the default configuration over to use them.
We do not already have bold support - that's something new @onaforeignshore is building into #476.
@bhilburn Can we move context to deprecated though? (in #476)
@onaforeignshore - I'd actually like to keep context as a supported segment. It's fundamentally different from the separate segments you are creating, and there will likely still be users that want to use it as one monolithic item.
Moving the default configuration over to using your new segments is something of a "soft" deprecation, though, and will result in the vast majority of our users using the new segments, anyway.
@bhilburn why not building the context segment with @onaforeignshore two segments for host and user? would be just one line at beginning of the code.. something like:
context="$(user)@$(host)"
@shibumi - So, the advantage of the monolithic segment is that it won't break backwards compatibility for folks who are using BASH-expansions. See this line in the code:
https://github.com/bhilburn/powerlevel9k/blob/master/powerlevel9k.zsh-theme#L542
I don't think there is a way to use the split segments and still honor those formatting strings without doing a bunch of parsing, which would be a huge pain in the ass, hah :)
@onaforeignshore - You up for breaking this out into a PR? I would love to get this in for the next release.
Whoops! Forgot to close this when #489 was merged =)
Hah, not sure what I was thinking. #489 wasn't merged, it was closed in favor of #497.
Anyway, just leaving this closed since we are discussing in the PR, anyway =)
Most helpful comment