01:19 <amanneedsamaid> Hello, I was wondering if anyone knows of a font or method to get better unicode symbol rendering in foot, right now I have font=monospace:size=9 in my foot.ini, and when using scli (a signal messenger terminal frontend) and trying to 'react' to other messages, all of the symbols besides the thumbs up are just identical rectangles, I tried a font I already had installed (Jetbrains Mono Nerd Font), and it did not work.

07:55 <novakane> amanneedsamaid: you tried to setup Jetbrains in foot or you just installed it, because if it is not set as your system monospace font it won't works just using monospace in foot

14:46 <psusi> my foot window background is not full black. Any idea why?

14:49 <anarcat> is there already a feature request open for "double-click to select text within quotes" or equivalent?

15:05 <psusi> ahh, apparently you set the color in foot.ini and it defaults to 111111 instead of 000000

15:08 <psusi> whenever I start foot, it complains: locale '$GARBAGE' is not UTF-8, using 'C.UTF-8' instead. seems to be a bug.

15:10 <psusi> my LANG=en_US.UTF-8 so I'm not sure why it is complaining that it isn't UTF-8, or why it prints garbage instead of en_US.UTF-8

15:17 <dnkl> psusi: LANG is most likely not utf8 in the process the foot terminal is launched from

15:22 <dnkl> anarcat: you can tweak which characters break a word selection. Other than that, no existing feature request that I'm aware of

15:23 <anarcat> dnkl: yeah, so the idea is that in some terminal emulators, you have the following sequence: double-click is "word", triple-click is "words between quotes", and four-clicks gets the whole line

15:23 <anarcat> it's not just like tweaking the word selection, it's actually different things

16:00 <cbb> psusi: what does "$GARBAGE" look like? random bytes or a readable string?

16:06 <psusi> yea, random

16:06 <psusi> dnkl: like I said, LANG=en_US.UTF-8

16:09 <cbb> psusi: I think dnkl meant LANG could be set to en_US.UTF-8 in some contexts, but not necessarily the one you're launching foot from

16:10 <cbb> what distro are you using?

16:11 <cbb> also, how have you set your locale and how do you launch foot?

16:12 <psusi> gentoo, and I'm running foot myself and explicitly setting LANG when doing so

16:12 <psusi> as in I tell bash "LANG=en_US.UTF-8 foot"

16:13 <psusi> hrm... I tried copying this locale_is_utf8 function to a test program but gcc complains: foo.c:16:17: error: converting to execution character set: Invalid argument

16:14 <cbb> do you get any output if you run "env | grep ^LC_"?

16:15 <cbb> (from the same bash session)

16:15 <psusi> ahh, LC_ALL=en_US

16:16 <cbb> yeah that's the problem then

16:16 <cbb> that takes precendence over LANG

16:16 <psusi> right... now for why the random garbage characters...

16:17 <psusi> oh, and why can't I compile this locale_is_utf8 function?

16:17 <cbb> that's harder to determine, I'd have to take a closer look at the relevant code

16:17 <psusi> it's got some umlouted o or something in a quoted string that gcc seems to choke on

16:22 <psusi> ahh, I think I see the problem... foot calls setlocale() again before trying to print the locale name that was previously returned by setlocale()

16:23 <psusi> I think the second call invalidates the string the first one returned

16:23 <psusi> so it needs a strdup

16:26 <psusi> I'm running foot under sway and I notice that it is also complaining that: render.c:2574: compositor is not releasing buffers immediately; expect lower rendering performance

16:26 <psusi> what's that mean?

16:34 <dnkl> psusi: for best performance, foot needs to be able to re-use the same buffer for each and every frame rendered. If foot detects a certain number of frames being rendered on different buffers, it warns.

16:35 <dnkl> sway should however be releasing buffers immediately. So, might be a mis-detection, though that's not something I've ever seen before

16:36 <dnkl> could also be corner cases in Sway, where buffers aren't released immediately

16:40 <cbb> psusi: I think you may be right about the second call to setlocale()

16:44 <cbb> the setlocale() return value is technically an "opaque string" according to the standards, but I don't think any libc you'd be using on Gentoo would return something random looking

16:53 <psusi> cbb: it doesn't... it returns "en_US", but then after setlocale() is called again, that pointer becomes invalid

16:53 <psusi> dnkl: might it be because I'm using a headless instance of sway accessed via wayvnc?

16:57 <dnkl> psusi: very likely, yes

16:58 <psusi> dnkl: is it just so slow without hardware acceleration that it can't copy the buffer to the screen in time for the next refresh?

17:15 <dnkl> psusi: not that slow. It mostly affects (typing) latency

17:17 <dnkl> foot usually has no problems doing full screen refreshes in a few ms (well below 16ms, which is the refresh interval you have for 60Hz)

17:17 <psusi> I'm not sure you understood what I was getting at. I mean is the cause of the warning the fact that sway takes too long to composite the display before it can return the buffer to foot?

17:17 <dnkl> no

17:17 <dnkl> at least i don't think so

17:17 <psusi> hrm... then why isn't it returning it on time?

17:18 <dnkl> under normal operation, Sway would upload foot's shm buffer to the GPU and then release the buffer

17:18 <dnkl> in headless, there's no GPU, and i suspect Sway needs to keep the shm buffer around until the next frame

17:18 <psusi> for that matter, I thought that the memfd buffer was sealed before sending it to the wayland server, so how can it be returned and reused?

17:19 <psusi> why would it do that? i would think it would just bitblt to the frame buffer.

17:19 <dnkl> it's sealed to prevent size changes. the content isn't sealed

17:20 <dnkl> you'd have to ask the sway devs :)

17:22 <psusi> wait, what? I thoguht sealing also prevented changing the contents, and that you wanted to do that so that the buffer can not be changed in the middle of compoziting the frame?

17:23 <dnkl> there are several sealing flags. foot intentionally doesn't set the "future write" flag

17:23 <psusi> I thought that the wayland server wanted that set to keep the client from modifying the buffer mid composite?

17:24 <dnkl> as soon a foot has committed a frame to the compositor, foot doesn't touch it, until the compositor had released it. that's how changes too the buffer is synchronized

17:25 <psusi> yea, but foot *could* touch it... I thought wayland wanted the buffer sealed to make sure the client can't touch it

17:25 <dnkl> if you set the write seal, you'd have to allocate new buffers for each frame. it's just too inefficient

17:25 <psusi> rather than just trusting the client to not do what it shouldn't

17:26 <dnkl> also, the Wayland protocol specifically mentions immediate buffer release as a way to help client performance. That's not possible to do if you write seal the buffers

17:28 <dnkl> so, I guess clients that are unsure about how and when they touch the buffers could set the write seal to prevent them from tripping themselves...

17:36 <dnkl> compositors are/should be more interested in size seals, since a size change could trigger a SIGBUS in the compositor