<baltazar>
hmm yeah, seems like it. `foot sh -c 'sleep 0.01; bash'` doesn't exhibit the issue
<baltazar>
it's weird though... I just ran `bash -c '. ~/.bashrc; echo ${PS1@P}' >/tmp/prompt.txt`, then if I run `foot cat /tmp/prompt.txt -`, it doesn't display the prompt at the first column
<baltazar>
actually, something might be off with my bashrc. `hexdump -C /tmp/prompt.txt` shows that for some reason the above command printed a bunch of `1b 48 20 20` aka `\eH ` for some reason
<baltazar>
oh wow, I had `tabs 2` in my bashrc, and it was just setting the tab stops
<baltazar>
removing `tabs 2` from bashrc seems to fix it, though I still don't get why it's an issue
<baltazar>
all it does is prints `\e[3g\r` to clear tabstops, then a bunch of ` \eH` to set the tabstops and finally a `\r` to return to the start of the line
<baltazar>
can be reproduced with `foot sh -c 'tabs 2; echo asdf; cat'`. also, tab stops don't actually get set this way.
<baltazar>
plus setting tab stops also seems to have other issues, like if I do `tabs 2; cat` then typing tabs behaves correctly but backspace still deletes back 8 characters, possibly back to the previous line
<dnkl>
backspace is interpreted by the tty driver
<baltazar>
fair enough, same behavior in konsole as well (though there I can't backspace to the previous line at least)
<dnkl>
I'm assuming that setting the tab stops iterates one whole row, with spaces between the tab stops? Guessing that gets reflowed when the terminal resizes
<dnkl>
foot implements BW (auto back-wrap). not many terminals do
<baltazar>
yea, that's what `tabs` does
Nulo has quit [Ping timeout: 260 seconds]
<dnkl>
if it is a reflow issue, then setting a small(er) initial window size (--window-size-chars|pixels) _should_ help - as long as the number of columns never decreases during startup. Compositor also matters, since the number of (size) configure events they send may differ
<dnkl>
the reason tab stops aren't set, as you say, is because foot resets the tab stops on a window resize
<dnkl>
I _think_ I verified this against XTerm, but I'm not 100% sure
<baltazar>
actually, the smaller I make it the worse it gets
<baltazar>
shrinking doesn't seem to affect it. if I set it to anything at least as wide as the final size, there's no issue
<dnkl>
ah, sorry, that's what I meant, but wrote the opposite :)
<dnkl>
yeah, initial size needs to be *bigger*, to avoid text reflow creating wrapped lines
<baltazar>
yeah ok. though, I would've guessed it reflows when it shrinks... that'd make more sense to me but whatever
<baltazar>
for now I'm just removing `tabs 2` as it doesn't even do anything due to window resizes
<dnkl>
hmm, you're right of course. Stop confusing me :)
<dnkl>
I believe the sizes we should be comparing is the initial one reported to the client application **before** the foot window has been created
<dnkl>
that's 80x24 cols/rows
<dnkl>
smaller than that, you get the reflow effect
<dnkl>
it depends on *when* the client application reads the window size
<dnkl>
on Sway, there will typically be *three* different sizes: the initial 80x24, then foot's --window-size-*, and finally Sway's tiled size
<baltazar>
ohh. but then, even --window-size-chars=80x24 is enough to "fix" it
<dnkl>
as long as no size-change reduces the number of columns, yes
<baltazar>
all right, makes sense
ollysmith has quit [Quit: ZNC 1.8.2+deb2+b4 - https://znc.in]
ollysmith has joined #foot
an3223 has quit [Remote host closed the connection]