<ericonr>
dnkl: ifreund: investigated this in #xbps, void's libutf8proc package has a bug in the pkg-config file
<ericonr>
I will be pushing a fix for that and the foot update without needing to work around it with CFLAGS
<ericonr>
then novakane should be able to build it as well
<ericonr>
without CFLAGS, I mean
yyp has joined #foot
<dnkl>
ericonr: that's great, thanks for letting me know :)
novakane has joined #foot
yyp has quit [Read error: Connection reset by peer]
yyp has joined #foot
sterni has quit [*.net *.split]
sterni has joined #foot
sterni has joined #foot
sterni has quit [Changing host]
yyp has quit [Ping timeout: 272 seconds]
yyp has joined #foot
yyp has quit [Read error: Connection reset by peer]
yyp has joined #foot
yyp has quit [Read error: Connection reset by peer]
<ifreund>
ericonr: nice, thanks for taking care of that
<dnkl>
ericonr: regarding your font issue, where e.g. ❯ is being cut off... I have an idea. However, my fonts well behaved, and have single-column glyphs for the two characters you mentioned.
<dnkl>
I even tested with IBM plex
<dnkl>
but that font doesn't have those glyphs
<dnkl>
in other words, they are loaded from a fallback font
<dnkl>
I'd like to know which font they're loaded from in your case
<dnkl>
if you run "foot sh" from another terminal, and then paste ❯, and/or ➜, you should see another font being loaded (in the log output). Can you tell me which font that is?
fnurkla has joined #foot
fnurkla has quit [Quit: WeeChat 3.2]
st3r4g has joined #foot
<cherti>
hey, I'm again observing an issue that I can't really pinpoint, so it might not be a foot issue at all, but so far it only ocurred in foot:
<cherti>
when I have an empty sway workspace and I start a foot, I get my zsh prompt, but quite regularly I get a black-backgrounded %, followed by two newlines and *then* the actual zsh prompt
<ifreund>
that sounds like it's probably an issue with your zsh config
<cherti>
when I open a second foot on that same workspace (horizontal split), this foot doesn't exhibit the issue, but now the foot that I already had has its black-backgrounded % and now 4 newlines (if that is newlines in the first place)
<dnkl>
cherti: that's zsh not handling the foot window being resized a couple of times in quick succession at startup
<dnkl>
Other terminals, and shells, have similar issues
<cherti>
ah, that could be
<cherti>
I was only able to reproduce that in foot, neither alacritty nor gnome-terminal, so I wasn't sure where the problem is located
<cherti>
dnkl: you don't happen to have a dirty fix for that? it's not particularly bad, but if I coudl get rid of it I wouldn't mind
<cherti>
I have tried to use "clear" at the end of the zshrc, but that didn't help
<cherti>
probably because zshrc is done before those resize-options happen
<cherti>
*operations
<cherti>
interestingly, I can only reliably reproduce that on the first terminal on an empty workspace… might be with the dimensions
<cherti>
dnkl: foot doesn't happen to have the option of triggering a ctrl+L once startup is finished, possibly?^^
<dnkl>
Would be the best workaround from the terminal side
<cherti>
I see. not surprising, but was worth a try :D
<cherti>
I mean, it's not particularly problematic, I was just irritated^^
<dnkl>
I hear fish no longer has this problem, so should be fixable in zsh
<dnkl>
Probably just not bothering people enough to get fixed
<cherti>
probably
<dnkl>
cherti: fwiw, I see it occasionally on the second or third terminal
<cherti>
me too, but not reproducably right now
<cherti>
(or I simply haven't found the right setup for reproducing
<cherti>
I see it fairly often on a secondary screen where I have stacked layout
<cherti>
dnkl: do you think the problem would be reduced by using footclient instead of foot?
<cherti>
probably not as the size has to be determined by footclient as well, right?
<dnkl>
cherti: my guess is it would be worse...
<cherti>
ah, because the shell would be started by footserver before the UI-startup even starts to run?
<dnkl>
cherti: yes, it goes through the same sequence of resize events
<dnkl>
Sort of; less things needed to be done inside the foot process before it can handle the resize events, and thus push them to the shell
<dnkl>
Note that foot is being reactive here; it's the compositor that's sending us resize events
<cherti>
question on that: with a footclient, if my serverprocess dies, it still tears all terminals down with it, right? because they are still bound to the server process?
<dnkl>
cherti: that's right. The footclient processes are not involved at all in running the terminal
<dnkl>
In fact there's a --no-wait option
<cherti>
they are merely proxy processes for the server?
<dnkl>
That tells them to exit as soon as the new window is up
<cherti>
ah, so it's just a startup requester, so to say
<dnkl>
They instruct the server process to instantiate a new terminal, and then wait for the exit value of that terminal, before exciting
<dnkl>
Exiting
<dnkl>
Correct
<cherti>
ah, I see
<cherti>
quite neat
<dnkl>
They do get their own rendering threads
<cherti>
although I'm not heavily using that at the moment
<dnkl>
But vt processing is multiplexed between all terminals in the main thread
<cherti>
should lower at least the memory footprint, cpu time probably not so much, but it also increases startup time iirc
<cherti>
the latter is the one I'm actually most interested in^^
<ifreund>
I can't reproduce the issue on river for whatever reason, though that could just be that what ever SIGWINCH race zsh is hitting doesn't trigger easily on my hardware
<dnkl>
With footclient you get both smaller memory footprint, and reduced startup time
<cherti>
but foot itself is actually still quick enough, so I'm mostly not using footclient currently
<cherti>
yeah, alacritty is *noticably* slower on startup time
<cherti>
after pointing that out to a friend, I got a grudging response and he switched over to foot as well^^
<cherti>
things you cannot unnotice anymore and such :D
<dnkl>
ifreund: between thumb and finger, I'm getting it maybe 1/20 times
<cherti>
ifreund: I also only get that in certain layouts (I guess)
<cherti>
so reproducibly when foot is almost fullscreen and reproducibly not if it's not
<dnkl>
cherti: yeah, plain foot is fast enough. I use it in server mode mainly for the reduced memory footprint. And since the font and glyph cache is shared, it's slightly faster at loading glyphs
<cherti>
so might be that your startup size is simply in a way that the issue doesn't pop up
<dnkl>
cherti: i believe it's a combination of a race inside zsh, and the actual sizes involved
<cherti>
let's see if I'm switching over to the server at some point, I already have it set up as a systemd user service already just in case :D
<ifreund>
I think the sizes are just one of the factors contributing to the timing the race needs to trigger
<cherti>
and given that I'm still using a browser, memory usage is currently not my prime worry about my terminal^^
<ifreund>
It's probably possible for it to happen on my compositor/hardware just less likely for a combination of reasons
<cherti>
yeah, race conditions are a… highly on many things dependent thing^^
<dnkl>
ifreund: agreed, size is just one factor
<cherti>
(actually, given the prevalence of electron, I'm actually running at least three browsers typically…)
<ericonr>
and now info: fcft.c:757: /usr/share/fonts/TTF/DejaVuSansMono.ttf: size=12.00pt/14px, dpi=81.19 after some configuration and it looks ok-ish
<ericonr>
I find I prefer the sans symbol
<ericonr>
just slightly, though
<ericonr>
that glyph seems to be rare among fonts, from what I can see?
<dnkl>
ericonr: yeah, looks that way. I had two fonts with it. In one it was clearly a single column glyph, sand and in the other it was wide enough to be treated as a double width.
<ericonr>
anyhow, thanks for the debugging help :_
<dnkl>
Since it's using a fallback font, this also depends on the primary font; if it is very narrow, you're more likely to have these glyphs being cut off
<ericonr>
what I did now was explicitly configure font = IBM Plex Mono:size=12, DejaVu Sans Mono:size=12
<ericonr>
then it uses a reasonably sized glyph
<ericonr>
idk if that's accidental or working as intended though
<dnkl>
ericonr: no worries. I have something I'm going to test. Hopefully it works out...
<dnkl>
ericonr: makes sense; you're adjusting the fallback font do that it either fits in a single cell, or becomes wide enough to be treated as a double width
<ericonr>
I think in this case it's single cell
<cherti>
testuser[m]1: two browsers, technically, if we want to actually nitpick the irrellevant details
yyp has joined #foot
<dnkl>
ericonr: aaaaah. _now_ I see...
<dnkl>
your original fallback font was Dejavu Sans
<dnkl>
not Dejavu Sans *Mono*
<dnkl>
that does explain everything
<dnkl>
ericonr: then your workaround - to explicitly configure the fallback font - is the right one
<dnkl>
well, you could of course configure fontconfig to pick dejavu sans mono over dejavu sans in general, but I'm guessing dejavu sans (non-mono) is better for non-terminal applications
yyp has quit [Ping timeout: 268 seconds]
yyp has joined #foot
st3r4g has quit [Quit: おやすみ]
yyp has quit [Read error: Connection reset by peer]
st3r4g has joined #foot
yyp has joined #foot
novakane has quit [Quit: WeeChat 3.2]
novakane has joined #foot
<ericonr>
dnkl: yes, I think being explicit in the foot config is best :)
<ericonr>
foot's font rendering is noticeably different from alacritty's, but I find myself enjoying it
<ericonr>
my only remaining issue is that the memory bars in htop inside tmux seem broken, the used/total numbers aren't shown :/
<ericonr>
but that might have to do with color settings, I will have to investigate
novakane has quit [Quit: WeeChat 3.2]
yyp has quit [Remote host closed the connection]
<Arnavion>
They work for me with my (non-default) colors, so yes you probably have some wrong colors