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

Git staged tick is rendering grey, not white #371

Open
jamieburchell opened this issue Jan 16, 2023 · 7 comments
Open

Git staged tick is rendering grey, not white #371

jamieburchell opened this issue Jan 16, 2023 · 7 comments
Labels

Comments

@jamieburchell
Copy link

Describe the bug
Git staged tick is rendering grey, not white

Screenshot 2023-01-16 134215

To Reproduce
Install latest version of powerline-go and Cascadia Code 2111.01 (Cascadia Code PL)

Expected behavior
Tick should be white

Environment (please complete the following information):

  • OS: Windows 11 / WSL
  • Shell: Bash

Additional context
Using Windows Terminal Preview 1.16.3464.0

@justjanne
Copy link
Owner

That looks like a bug in Windows Terminal instead, the color is set to white and the character should be rendered as regular character. Windows Terminal seems to render it as emoji instead.

@jamieburchell
Copy link
Author

jamieburchell commented Jan 16, 2023

@justjanne Apologies, I didn't know which component was causing the problem. It's possible that this has happened as a result of switching to Terminal Preview (from regular Terminal) for a feature I wanted.

@justjanne
Copy link
Owner

But no matter which component causes the issue, we should look into a way to fix it. Potentially adding a U+FE0E variation selector might already be enough to fix it.

@thijsputman
Copy link

Potentially adding a U+FE0E variation selector might already be enough to fix it.

@justjanne, that visually works, but has (recently) started causing some major issues on my end.

In order to remedy some half-width emojis in my "WSL2/Ubuntu/Windows Terminal (Preview)"-setup, I added the following to the configuration some time ago:

"Modes": {
  "patched": {
    "Lock": "\uE0A2\uFE0E",
    "Network": "\u260E\uFE0E",
    "RepoBranch": "\uE0A0\uFE0E",
    "RepoDetached": "\u2693\uFE0E",
    "RepoAhead": "\u2B06\uFE0E",
    "RepoBehind": "\u2B07\uFE0E",
    "RepoConflicted": "\u273C\uFE0E",
    "RepoStashed": "\u2691\uFE0E",
    "RepoNotStaged": "\u270E\uFE0E",
    "RepoStaged": "\u2714\uFE0E"
  }
}

This works like a charm on Ubuntu 20.04 (with bash 5.0.17). After recently upgrading a couple machines to Ubuntu 22.04 (bash 5.2.2) it started to become problematic though: When copy-pasting text onto the terminal or scrolling through history (arrow-key up/down) input becomes totally garbled.

It appears that for every "\uFE0E-emoji" on the prompt, two spaces are "lost". It's most obvious when copy-pasting something: Paste, press left arrow-key once, the entire input on the prompt moves two spaces to the left (and leaves the last two characters duplicated at the end). After this point input is "broken"; what's shown on the screen is not actually what's there any more...

Removing \uFE0E from the above configuration, or navigating to a folder that doesn't have any emojis on its prompt, resolves the issue.

I haven't had the time/opportunity to dig any deeper, so I'm not entirely what's causing it (outside of the Ubuntu upgrade)...

@jamieburchell
Copy link
Author

This is still an issue using v1.24 on Windows Terminal Preview Version 1.18.1462.0 and Ubuntu 22.04.2

@jamieburchell
Copy link
Author

Any update on this @justjanne ?

@jamieburchell
Copy link
Author

microsoft/terminal#15592

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants