Battery and Powerline-multiline conflict

[aarmn]

when battery plugin is enabled this happen

[Delta456]

How is the battery plugin enabled?

[JaydevSR]

I am also getting a similar a behavior with battery and powerline-multiline together, I did a fresh install no customizations from my side.

[KrappRamiro]

Same issue on my side, clean installation with powerline-multiline and battery plugin enabled

[akinomyoga]

No one seems to describe what is the issue explicitly, but you are talking about the extra line between the line showing information (times, batteries, etc.) and the line where the user command will be input, right?

[aarmn]

No one seems to describe what is the issue explicitly, but you are talking about the extra line between the line showing information (times, batteries, etc.) and the line where the user command will be input, right?

Yup, that extra blue line was the problem. But at this point this issue is so old that I do not use oh-my-bash, and my machine OS changed multiple times, therefore I cannot share a MWE, but I had some similar issues with starship as well, tho rarely, therefore I think it's a general problem with all these codes, If I had that config available I would have been able to check it on different terminals, but I don't think it only happened on yakuake, but I don't know, maybe it was a font problem or a bug fixed by now!

update: I guess the problem is emoji, use nerd font with a mono font and use space after nerd font glyphs and the problem would not sustain with a 99% chance

[akinomyoga]

Thank you for the information!

I would have been able to check it on different terminals, but I don't think it only happened on yakuake, but I don't know,

OK, so you have been using yakuake at that time? I have now tried konsole, lxterminal, termit, terminology, terminator, xfce4-terminal, xterm, rxvt, urxvt256c, alacritty, mintty, and kitty, but I couldn't reproduce the problem in any of these terminals. I also tried mlterm with which the rendering is broken even without battery, but this is because mlterm uses a different width mode of Unicode East_Asian_Width informative property. Maybe I should set up yakuake later.

maybe it was a font problem

Yeah, probably it is related to the calculation of the width of each character. Some terminals uses the font metrics to determine the character width, but the basic agreement between most terminals and terminal applications are to use the system's wcwidth. Even with this rule, there will be problems when the user log into the host from the remote terminal because the behavior of wcwidth depends on the system (with different combinations of Unicode versions, Unicode Emoji versions, and support for the emoji sequences and the level of grapheme clusters such as "legacy" vs "extended", etc.).

or a bug fixed by now!

The original problem might be solved in the latest version of yakuake, but @KrappRamiro seems to have experienced the same now, though I'm not sure if @KrappRamiro uses the same terminal. Hi, @KrappRamiro, what is your terminal and the font used there?

[akinomyoga]

I now tried yakuake in Ubuntu 20.04 LTS and confirmed that the problem is still present there! In addition, I could also reproduce the problem in gnome-terminal, lxterminal, and kitty in Ubuntu 20.04 LTS even though they did not exhibit the problem in my default host, Fedora 36 Server Edition. It seems to be related to the fonts installed on the system.

I'm not sure if this is something that can be fixed at the oh-my-bash side but will later take a look at it.

[aarmn]

I think the best we can do is to pinpoint the problem, because foremost, it's not "just omb" problem, then we can at least warn users in README about such problems happening again. But first we clarify its fonts? Terminals? Even I am not really sure at this point
An effective solution can later be copied by many other projects as well!

[KrappRamiro]

Hi, @KrappRamiro, what is your terminal and the font used there?

Hi, sorry for slow replying, my terminal is gnome-terminal, and the font is SauceCodePro Nerd Font.

But for some weird reason, the bug its not happening anymore. I dont know why, maybe its because the emoji isnt appearing, so its no longer pushing the blue square out of line?

[akinomyoga]

Thank you for the information! So you haven't changed the font since you last reported it? It is interesting that even with the same font, the problem may happen or not happen. Maybe there are even other factors.

[KrappRamiro]

I haven't changed the font, yeah.
But recently, i was able to reproduce the bug, and it only seems to happen when the ⚡ emoji appears, and that is when battery is full and AC is connected. So the bug seems to be related to the use of the ⚡ emoji

[akinomyoga]

Oh, I see. That makes sense. Thank you for the information.

Let me think about possible solutions. I think the powerline theme doesn't have the ability to correctly calculate the width of strings that contain double-width characters. To solve this, we need to either

• A) avoid using emoji characters in the right prompt or
• B) implement the correct calculation of the width of strings that contain double-width characters.

Solution B is ideal, but it is hard to implement in the shell script. My personal project contains such an implementation in a shell script, but I don't think it is a good idea to port it here because it has thousands of lines of code.

• C) Or if there is an external command that internally calls wcswidth(3) for the command line argument, it can be used to properly implement the right prompt, but I'm not sure if there is even such a command. Maybe @dankamongmen, the author of notcurses, might be interested in it. In [kitty] ble.sh not working with the kitty terminal akinomyoga/ble.sh#110 (comment) and do a quick utility that detects/queries the terminal, and reports all capabilities in machine+human-readable format dankamongmen/notcurses#2376, we once talked about a commandline tool that helps to construct terminal UI using shell scripts.

  @dankamongmen: Is there any progress in do a quick utility that detects/queries the terminal, and reports all capabilities in machine+human-readable format dankamongmen/notcurses#2376? What do you think of providing a commandline interface to wcswidth?

Edit: I found notcurses-info as a terminfo replacement command, but its output format doesn't seem to be shell-script friendly like that of tput.

[dankamongmen]

Edit: I found notcurses-info as a terminfo replacement command, but its output format doesn't seem to be shell-script friendly like that of tput.

yeah, i focused on this rather than tput-like functionality. i don't think i have anything to help you immediately, but keep me in the loop!

[akinomyoga]

Thank you for your reply!

[alsimoneau]

I fixed it by replacing the icon in /usr/share/oh-my-bash/themes/powerline-multiline/powerline-multiline.theme.sh at line 41 with the nerdfont character 󱐋 (f140b).
I also used the nerdfont characters for the Python and Ruby symbols while at it.

Another fix is to add a zero-width character afterwards, so that the character count is correct no matter how it is done.