i have something very important to share with the class
you have no idea how long it took me to get bash not to mess up the prompt length calculation. you see that line wrap on the long echo command input? that was a LOT OF EFFORT
i made a single-line version as well, if you prefer something less ostentatious
https://pastebin.com/XvfB5kn4 here's the code! stick it at the end of your .bashrc file if you wanna try it. i also made it so you can set SMOLFACE=1 or SMOLFACE=0 to turn on or off the small version
it could definitely be cleaner but if i wanted this to be Product-Quality Code it'd be patreon exclusive or something
i have been made aware (thru experimentation on my work laptop) that this doesn't work properly in conjunction with modern shell features of pressing up and tab and whatnot to autofill commands
oh well. i have more ideas for silly prompt stuff
@typhlosion oh yikes, yeah, i see no reason the single line variant wouldn't but the multiline definitely
@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
@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
@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