Move Git action after dirty with space and default color

[camsteffen]

Summary
Moves the dirty indicator to be always adjacent to the branch. Separate the git action with a space instead of a pipe. Bestow a distinct default color to the git action, yellow.

This is following up to other recent changes #491 and #486. (which are great!)

I feel that the re-arranging would be a less welcome change without the default color also being changed.

Before:

After:

Of course this is all subjective but here is my rationale...

The dirty indicator should be adjacent to the branch since they are very closely related in my mind. Together they tell me the status of the working tree. The git action seems like it belongs at the end since it is a "special state", relatively uncommon, important to notice. A space and a distinct color is cleaner and more readable than a pipe.

I chose yellow instead of red (as in #486) for the git action since red looks like an error.

If these changes are agreed upon, I can update the readme too.

[sindresorhus]

I agree it makes sense that * is always after the branch, also highlighting the rebase action. I'm not sure about using just space between them though. It makes it seem like they're not connected. Is there any other Unicode symbol we could use that is more subtle than |?

[camsteffen]

Is there any other Unicode symbol we could use that is more subtle than |?

Here's a few: ‣, ›, », •, ⬩

[camsteffen]

My vote would still be for just using a space. Putting another symbol next to the "dirty" asterisk looks messy.

[mafredri]

How about rebase-i(master*)? To be honest I'm not too opinionated about this, I think the default display of master|rebase-i* makes sense. The way I think about it is that we're on branch master, which is in a state of rebase, and it's dirty.

[camsteffen]

How about rebase-i(master*)?

I think it's best for the git action to be on the right so that the branch name stays in the same position (more or less) as you work.

The way I think about it is that we're on branch master, which is in a state of rebase, and it's dirty.

Maybe we have different mental models. To me, the current git action is orthogonal to the current git branch. I would not say that a branch is in a state of rebase or merge.

[sindresorhus]

How about using gray and dimmed parens around the rebase state?

[camsteffen]

How about using gray and dimmed parens around the rebase state?

Good! I'll code that up.

[camsteffen]

Umm can you give me a hint for getting dimmed gray? Do I need to add an entry to prompt_pure_colors?

[sindresorhus]

You can see the ansi codes for dim and gray style here: https://github.com/chalk/ansi-styles/blob/74d421cf32342ac6ec7b507bd903a9e1105f74d7/index.js#L68

[sindresorhus]

Do I need to add an entry to prompt_pure_colors?

No, I don't think we need the parens to be customizable.

[camsteffen]

Okay, ready for review.

[sindresorhus]

@mafredri LGTY?

[mafredri]

This looks good, but I'd like some clarity on the escape codes used.

[camsteffen]

I updated the code to...

1. Properly escape using %{...%}
2. Separate the git action code from the git branch code (seems more consistent, readable)
3. Add a comment

@romkatv raised an issue about the "faint" escape code not being portable. I don't really understand that issue well enough to comment...

[camsteffen]

Rebased again to update the readme color diagram with user@host at the beginning.

[mafredri]

@romkatv raised an issue about the "faint" escape code not being portable. I don't really understand that issue well enough to comment...

I can't really speak for how well it's supported either, but I do think there is potential for trouble. Thinking of terminals like the Emacs terminal or (u)rxvt.

But also, I do think the color needs to be configurable, otherwise it's kind of anti-theme-ability (that one pesky color you can't change). And if it's configurable, then there's really no reason for it to be faded either (as that would also go against theme-ability). We'd just pick a darker / more faded color.

[sindresorhus]

If the dim style is not supported, it will just be gray, which is fine too. I don't really see the problem.

---

We'd just pick a darker / more faded color.

The benefit of dimming gray is that we just take the gray the user has chosen and that fits with their theme and make it dimmer. If we pick a darker color, it might not look good when put in front of some terminal background colors.

[romkatv]

If the dim style is not supported, it will just be gray

Color 7 is "white". This is often the same color as default foreground, so it's rather bright. On terminals without dim style parentheses will stand out. They'll be much brighter than branch name, for example.

Pure currently uses color 242 in several places (including branch name), which is always #6c6c6c (grey). Pure doesn't use dim style or any kind of grey color that is affected by the terminal theme. Pure doesn't use color 7 (white, affected by the terminal theme) anywhere.

I don't have a strong opinion here. I personally wouldn't define default parameters that make prompt looks weird on terminals without dim style support. I'll survive if you do that, so don't mind me. I'll deal with potential complaints from powerlevel10k users who enable Pure style with the usual retort -- "that's how Pure does it."

[sindresorhus]

If it’s white, that’s wrong. I asked for gray, which is technically called “ansi bright black” (code 90).

[romkatv]

If it’s white, that’s wrong. I asked for gray, which is technically called “ansi bright black” (code 90).

That would be color 8 (%F{8}). Pure doesn't currently use it.

Note that color 8 (without dim) is invisible in Solarized Dark. Color 8 with dim is almost invisible in Tango Dark. I believe these color schemes are among the most popular, if not the most popular.

[camsteffen]

In my test, dim 7, 8, and 90 all look the same and are all invisible in Solarized Dark. That does seem like a non-starter. @romkatv do you have any suggestions?

[romkatv]

@romkatv do you have any suggestions?

I wouldn't presume to suggest but I can tell you what I would do if this was up to me. I wouldn't use parentheses. They are out of place in Pure prompt as it currently has no brackets of any kind. Different parts of prompt are simply separated by spaces and distinguished by colors. The original screenshot you've posted looks fine to me:

I respect the right of @sindresorhus to run this project the way he likes. I don't use Pure myself, so my opinion carries no weight.

[camsteffen]

I agree 100% 👆, except I am a Pure user. I could take or leave the parenthesis.

[sindresorhus]

Note that color 8 (without dim) is invisible in Solarized Dark. Color 8 with dim is almost invisible in Tango Dark. I believe these color schemes are among the most popular, if not the most popular.

That's a problem with those color schemes and not really a concern for Pure.

[sindresorhus]

And if it's configurable, then there's really no reason for it to be faded either (as that would also go against theme-ability). We'd just pick a darker / more faded color.

The benefit of dimming instead of choosing a darker colors is that it works no matter whether the terminal background is dark or light.

[sindresorhus]

Seems like the parens cause too much problems. Let's just drop them. We can tweak the look in the future if we think of a better way to present it.