bash-it prompt themes - wrap-around glitches

[yang]

On Mac, I'm seeing the cursor and input characters overlap with the powerline status display once text exceeds a certain length. It has something to do with the wrap-around, since maximizing the iTerm such that the line doesn't spill does not experience the same problem.

I do not experience these problems when unsetting BASH_IT_THEME and instead setting a custom PS1 that also produces a long-enough line.

[nwinkler]

Looks similar to #1125 to me...

[yang]

Maybe, though I didn't need to resize windows to run into this.

On Wed, Jul 18, 2018, 2:52 AM Nils Winkler [email protected] wrote:

Looks similar to #1125 https://github.com/Bash-it/bash-it/issues/1125 to me...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-405828435, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAb2dLNuUUS4AH9_3lemf1yAb1vj4j8ks5uHts3gaJpZM4VBrhU .

[bulldozier]

The root cause is 2-byte unicode characters, which Powerline uses for spaces and triangles, getting treated as 2 printable characters instead of 1. To fix this, make sure the locale is set to something that supports unicode such as en_US.UTF-8. In particular, the default glibc locale is "C" which predates unicode and does not handle 2-byte unicode characters correctly. See this man page for more info.

[nwinkler]

Thanks - do you have a concrete setting that people could apply, or that we could add to the documentation?

[bulldozier]

Our use model was a bit different since we are running in Docker. Our fix was the following:

In Dockerfile: -ENV LANG=en_US.UTF-8 +ENV LANG=en_US.utf8 +sed -i 's/UTF-8/utf8/' /etc/yum.conf

Then we ran "locale -a" and "locale" to verify that en_US.utf8 was there. When we used the capital letter form (UTF-8), it was getting set to "C" which caused the bad wrapping.

[yang]

Any tips on how to debug this? I tried again recently, but still is an issue for me for the past few years:

[gaelicWizard]

Any tips on how to debug this? I tried again recently, but still is an issue for me for the past few years:

@yang, LANG should be "en_US.UTF-8". I have no idea on earth why it would ever be set to end with lowercase "utf8" as that's not a valid encoding name anywhere that I'm aware of. The name of the encoding that locale understands is "UTF-8" so end with that.

(There's actually files with those names somewhere under /usr, that need to be matched exactly. Running locale -a will show you all the valid choices on your system; anything not on the list will fail.)

[gaelicWizard]

Any tips on how to debug this? I tried again recently, but still is an issue for me for the past few years:

@yang, LANG should be "en_US.UTF-8". I have no idea on earth why it would ever be set to end with lowercase "utf8" as that's not a valid encoding name anywhere that I'm aware of. The name of the encoding that locale understands is "UTF-8" so end with that.

(There's actually files with those names somewhere under /usr, that need to be matched exactly. Running locale -a will show you all the valid choices on your system; anything not on the list will fail.)

Looking at your screenshot again: if you have any of the $LC_* variables set, then $LANG is ignored. Don't set those without very specific reason.

[yang]

@gaelicWizard Just to clarify, "en_US.UTF-8" is what it was originally - the above screenshot just shows me trying to change it from that to what was mentioned further up this thread (to no avail).

[yang]

The only LC_ env var that's set for me is LC_TERMINAL=iTerm2 (set by iTerm2)

[gaelicWizard]

@yang, could you run these commands and post your results?

set | grep LC_
unset "${!LC_@}"
export LANG="en_US.UTF-8"
locale
LC_CTYPE=UTF-8 locale
type -p locale iconv

You've caught my curiosity, so I'll try to track this down for you! 😃

[bulldozier]

As per https://perlgeek.de/en/article/set-up-a-clean-utf8-environment:

Most of the time it works to set all of these to the same value. Instead of setting all LC_ variables separately, you can set the LC_ALL. If you use bash as your shell, you can put these lines in your ~/.bashrc and ~/.profile files:

export LC_ALL=en_US.UTF-8 export LANG=en_US.UTF-8 export LANGUAGE=en_US.UTF-8

On Wed, Sep 15, 2021 at 10:59 AM Yang Zhang @.***> wrote:

The only LC_ env var that's set for me is LC_TERMINAL=iTerm2 (set by iTerm2)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920249942, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLY5HO3ZXHMJ2BLJORL7LUCDNJVANCNFSM4FIGXBKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[yang]

Here's what I see:

[bulldozier]

Are you sourcing the ZSH setup files or BASH ones?

On Wed, Sep 15, 2021 at 3:34 PM Yang Zhang @.***> wrote:

Here's what I see:

[image: image] https://user-images.githubusercontent.com/7129/133518627-ebbb23d1-86af-41b1-ad6b-edbd8787dfb3.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920432226, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLY5GBGC7ZGNBM546ELZTUCENNRANCNFSM4FIGXBKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[yang]

My shell is already set to bash (as confirmed by echo $SHELL etc.)

On Wed, Sep 15, 2021 at 3:42 PM bulldozier @.***> wrote:

Are you sourcing the ZSH setup files or BASH ones?

On Wed, Sep 15, 2021 at 3:34 PM Yang Zhang @.***> wrote:

Here's what I see:

[image: image] < https://user-images.githubusercontent.com/7129/133518627-ebbb23d1-86af-41b1-ad6b-edbd8787dfb3.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920432226, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABYLY5GBGC7ZGNBM546ELZTUCENNRANCNFSM4FIGXBKA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920437613, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABXWLWLL2EEKFJ724VHEDUCEOPFANCNFSM4FIGXBKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bulldozier]

Did you try the things suggested here:

https://github.com/zsh-users/zsh-autosuggestions/issues/153 (terminal settings for locale)

and a couple here:

https://stackoverflow.com/questions/43267978/powerline-ps1-line-wrapping

On Wed, Sep 15, 2021 at 3:44 PM Yang Zhang @.***> wrote:

My shell is already set to bash (as confirmed by echo $SHELL etc.)

On Wed, Sep 15, 2021 at 3:42 PM bulldozier @.***> wrote:

Are you sourcing the ZSH setup files or BASH ones?

On Wed, Sep 15, 2021 at 3:34 PM Yang Zhang @.***> wrote:

Here's what I see:

[image: image] <

https://user-images.githubusercontent.com/7129/133518627-ebbb23d1-86af-41b1-ad6b-edbd8787dfb3.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920432226 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABYLY5GBGC7ZGNBM546ELZTUCENNRANCNFSM4FIGXBKA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920437613, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAABXWLWLL2EEKFJ724VHEDUCEOPFANCNFSM4FIGXBKA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-920439878, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLY5EO4QSIDM2F4GTQIFDUCEOWRANCNFSM4FIGXBKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[yang]

Hmm, I'm actually just using bash-it, I'm not directly sourcing powerline at all.

Also, some more info: this seems to mainly kick in when the prompt is about a certain length - no more, and no less:

[gaelicWizard]

I would recommend against messing around with the locale settings. From what you posted, it seems like there is nothing wrong with your locale.

I'm curious what's going on so I will try to reproduce this in the evening and see what I can find. My current hunch is that it may be related to characters not being fully escaped in the prompt string.

Bash counts the length of the prompt string and if it is not perfectly escaped, then Bash will sometimes draw over itself because it counts colors and escape codes as taking visual space.

[gaelicWizard]

@yang, sorry for not getting back sooner. Are you using screen or tmux?

I've reproduced the weird behavior on my system, so I'll track it down 😃

[gaelicWizard]

@yang, ok so it looks like @bulldozier is 100% correct that this is a multibyte character issue but I'm alsö pretty sure that it won't be fixed by messing with locale settings.

Inside screen, the weird character when my terminal width is exactly 113 characters wide:

It's counting the length on byte boundaries, not character boundaries, so it's counting half a char and therefore is chopping the escape code off the "return to normal" code at the end of $PS1.

That said, I think this may be a bug in some of powerline's prompt functions. I'm working through it now. 👍

[yang]

Awesome, thank you for looking! I really have no idea how to debug this, but please let me know if there's anything else I can provide to help. I just use raw iTerm2, without screen or tmux (I sometimes use those, but the problem comes up even outside).

On Thu, Sep 23, 2021 at 11:38 AM John D Pell @.***> wrote:

@yang https://github.com/yang, ok so it looks like @bulldozier https://github.com/bulldozier is 100% correct that this is a multibyte character issue but I'm alsö pretty sure that it won't be fixed by messing with locale settings.

Inside screen, the weird character when my terminal width is exactly 113 characters wide: [image: image] https://user-images.githubusercontent.com/52194/134559915-5bb06995-92e4-44c1-9d17-051270b3c484.png

It's counting the length on byte boundaries, not character boundaries, so it's counting half a char and therefore is chopping the escape code off the "return to normal" code at the end of $PS1.

That said, I think this may be a bug in some of powerline's prompt functions. I'm working through it now. 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bash-it/bash-it/issues/1207#issuecomment-926061219, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABXWMBCTR7DWNGKUHAZYDUDNX4DANCNFSM4FIGXBKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[davidpfarrell]

Hi All,

Yes the unicode chars are likely throwing off the padding logic.

You can test this by removing all unicode characters from your prompt. Pretty much every powerline pompt segment has a configurable character so you could override each to use a standard ascii char or just temporarily remove some prompt segments for testing ...

(Assuming it is a unicode padding issue)

The main problem is that there is no portable way to get the width of a unicode character/string.

You can see a previous discussion here:

• https://github.com/Bash-it/bash-it/pull/1447#issuecomment-569929454

The Powerline Multiline theme has support for a padding override to help this out a bit, but if you have a prompt segment that adds/removes (unicode) characters based on state (ie the battery segment), then the padding sometimes be wrong ...

If we can find a portable tool (or all-bash function) for computing the width of a unicode string, we can fix the padding logic, but without that, my plan would be:

• Allow each prompt segment config to allow the user to set a related PADDING value .. These would be pre-set with values matching the default character patterns BUT would need to be overridden by the user if/when they configured their own patterns. Each segment would add their related padding value to the padding accumulator and the final padding logic would hopefully compute the correct values.

Again though I think we need to do a test with prompts that have no unicode characters to confirm (and remember, the default powerline separators are themselves unicode) ... Maybe the powerline plain prompt would be a good candidate for the test.

[gaelicWizard]

Yes the unicode chars are likely throwing off the padding logic

I'm trying to run powerline.base through shellcheck and fixing the little things...and now I'm not able to reproduce, despite no (intentional) logic changes so that's why I say it may be a bug in the prompt functions. Still working through it!