00:37 <leon-p> huh, so the senpai IRC client somehow sets foots app-id?

00:40 <leon-p> anyway, it's quite nice how quickly I can implement window management policy in scheme; That feature I talked about earlier is already implemented

00:41 <leon-p> and it does work quite nice for things like IRC. Alt-i to check irc, Alt-i again to hide the irc window and return to whatever I was doing previously

00:42 <leon-p> also the decission to move state into the C library was a success as well: the state alist I had previously would have been really unwieldy. Instead if I now want extra state, I can just add the window to another list or something, data oriented design without the efficiency I guess

00:45 <leon-p> also really loving that if-let macro, simplifies control flow so much, no idea why that isn't part of scheme already

15:04 <szgy> <3

15:05 <szgy> ifreund: is river_shell_surface a sort of client that implements wlr-layer-shell?

15:06 <szgy> (meaning I could add this fzy-layer-shell as a component of the wm?)

15:08 <szgy> leon-p: pretty cool that Alt+i keybind for IRC. how is it that "i" gets map to IRC? if you're using senpai, wouldn't it be Alt+s ? (and it tries to match a window with title "s*"?)

15:18 <leon-p> szgy: because the WM allows to explicitly binds Alt-[a-z] as well, which overrides the implicit binding. I bound A-i to (focus-or-hide-or-run "senpai" "foot senpai &), which tries to focus or hide the terminal running senpai, or if that does not exist, runs the given command to spawn it

15:19 <leon-p> szgy: river_shell_surface is a replacement for layer-shell, so that WMs have more flexibility in positioning their custom UI

15:20 <szgy> ohh, right

15:22 <szgy> what would be the 'implicit binding'? binding of the selected window e.g.??

15:23 <szgy> like, a program has some binding, but if you pressed smth like Alt+i, the wm takes over?

15:25 <leon-p> no, the reference WM implicitly binds Alt-[a-z] to (focus-or-hide-by-prefix x) where x is the letter as a string

15:33 <leon-p> keybind logic is here: https://git.sr.ht/~leon_plickat/antares/tree/master/item/antares/antares.scm#L223

15:35 <leon-p> also that cadddr is a great illustration of why Lisps really should just have syntax suger for accessing lists at indeces

15:41 <leon-p> szgy: btw, did you see that window/output/seat state is now inside the C lib and that you can cast the object ptr to a state ptr to access it? Curious to know how well / ergonomic that is from LuaJit

15:45 <leon-p> anyway, I'll be off for one or two hours, need to take advantage of the wheather and go for a walk, later

16:17 <szgy> leon-p: haven't pulled from antares for a while! will do soon but havent had the time. Is that struct 'fixed'? or does it allow to add custom state to it?

16:17 <szgy> I've been handling state from the lua side, and its not thaat baad, but yeah, keen to try state managing from c side

16:18 <szgy> also yeah, my usual bond with lisp/scheme ends on `caddrdddraar`; thats why I prefer lisp-like langs like fennel or janet... (which also adds syntax sugar for lists and hash-maps)

16:19 <szgy> later!

20:38 <marcelleismann> clear

21:22 <Industrial> Hi. I just found River, and I'm loving it. I like the ctl cli design, makes it very flexible. I'm wondering about two things. 1) I guess, since there's a bash script ran for configuring it, restarting it is hard, so I have to quit and re-login? 2) I would like to bind Super+H/L to next/previous tag and Super+Control+H/L to Swap Client to Next/Previous Tag. Is that possible?

21:29 <Industrial> riverctl map normal <Mod> PERIOD send-next-tag

21:29 <Industrial> riverctl map normal <Mod> COMMA send-previous-tag

21:29 <Industrial> found it :)

21:32 <Industrial> Nope, that didn't work.

21:57 <szgy> Industrial: if you want to reload the config, just re-run the bash script! I don't think there are controls for next/previous tag, only a specific tag

22:00 <szgy> leon-p: tried using all the state from the c side and went pretty well! (need to undone some state handling on the lua side still). Once I figured out the syntax to cast between pointer types everything went pretty smooth

22:01 <szgy> only 'inconvenience' is to cast between state and 'thing' (window, output, seat) and back for different uses

22:02 <szgy> next-up, binds