@typhlosion oh yikes, yeah, i see no reason the single line variant wouldn't but the multiline definitely

@typhlosion HOWEVER
I BELIEVE MULTILINE PROMPTS DO WORK CORRECTLY IN ZSH
WHICH I RECOMMEND TO ANYONE WHO ANTICIPATES SPENDING A LOT OF TIME USING A SHELL

@typhlosion (zsh also supports right side prompts that autohide if you type a line long enough to span the screen but only one line, its a good place to put status info about the previous command imo)

@bossposs even the single line one makes bash barf a little, i guess because multibyte characters throw off its prompt length calculation, so i had to do Weird Stuff to make it work without long commands wrapping in a strange way. i suspect the Weird Stuff is interacting poorly with autocomplete whatnots

i'll play around with it more at some point. i want my screenface prompt dammit

@typhlosion i wonder if there's an option to make bash not choke on unicode...tho, actually, it might be an issue with how your terminal emulator is reckoning character widths?

@typhlosion idk what these characters are but there's a chance they might be considered double width by one of either your terminal or the shell and single width by the other >_> i know some terminals have this issue with emoji which i believe are officially double width now but used to be undefined, so some software that uses an older version of wcwidth (or a naive character width algorithm or a flawed homemade version) gets it wrong

@typhlosion im sorry im kind of ranting at this point because i wasted hours of my life trying to debug where in the stack of weechat -> tmux -> iterm 2 emoji rendering was going wrong and fucking up the character alignment

@typhlosion (turns out it was in two places, and i THINK the actual source of the problem ended up being mac os's outdated wcwidth function)

@bossposs these characters are from the Braille Patterns block, U+28xx. i don't thiiiink they're ever considered double width?

the shell/terminal im using at work is bash in gnome terminal in ubuntu 18.04 lts, and at home it was bash in gnome terminal in ubuntu 19.04

@typhlosion oh yeah, those are not double width... prompt seems to work for me with bash under termite; i don't have the gnome libraries installed and dont really feel like running that at the coffee shop lmao, so i cant test gnome terminal

im wondering if maybe the issue is in fact with the color escapes

@bossposs have you tried putting in a really long command, like long enough that the line would wrap

@typhlosion i just fucken realized you posted the source code so i could test your actual thing

@bossposs not that that's necessarily a good idea, it's a bit duct-tapey

@typhlosion WELL.. it was more so i could poke at the issue because i feel like poking at an issue

@bossposs fair!!! your help is appreciated

@bossposs plus learning more about how the prompt interacts with weird unicode stuff and control sequences is helping me do recon for Secret Projects im working on

@typhlosion got it working! its as i suspected, just wrap the color escapes in \[…\]

@bossposs you're a hero and a scholar

@typhlosion ahaha np i just have a lot of experience tinkering with exactly this kind of thing

@bossposs tinkering with exactly this kind of thing has been a bit of a hyperfocus for me lately so i am glad to have an experienced contact on my side

@typhlosion the explanation is: bash ignores everything between escaped brackets in a prompt string for the purpose of calculating the prompt's visual width. it doesn't even try to parse escape sequences, so you gotta wrap anything non-printing with those characters to tell it that text won't be making an appearance on screen