02:24 <mrkomododragon> hey yall, i heard about river, and seems cool. how does it compare to sway, and is this stable enough where I can daily drive it?

05:17 <LarstiQ> leon-p: when does that leaking happen? Every time a client binds to `zriver_control_v1` and goes away without calling `destroy`?

05:20 <LarstiQ> seeing the river-control-unstable-v1 commit in riverguile and your musings I guess so

05:37 <LarstiQ> leon-p: any particular reason you're not using (ice-9 match) module? At least to me it seems a lot nicer than the cond eq? chains

11:55 <leon-p> LarstiQ: because I am not aware of all ice-9 modules

12:55 <LarstiQ> leon-p: check :) Want me to contribute my version with match usage?

12:55 <leon-p> too late, but feel free to share you config anyway :)

12:57 <LarstiQ> I'll try to make some time for some cleanup this week

15:27 <tiosgz> fwiw #961 reminds me of #830. may be worth checking their river version, though i suspect they're on ~ master

18:15 <ifreund> Testing out some codeberg migration stuff today

18:16 <ifreund> looks like I probably have to delete the current codeberg repo and create a new one to use codeberg's migration feature

18:17 <ifreund> not terrible, but we would lose tiosgz's 7 PR threads

18:24 <ifreund> tiosgz wrote good commit messages though so I don't think it's a terrible loss

18:24 <ifreund> I'm doing a test migration to a private codeberg repo now to see how things look

19:20 <novakane> the main thing that could be a bit annoying is that if the wiki can't be edited by anyone

19:36 <ifreund> novakane: hmm, IMO the optimal wiki situation would be a normal repo people can make PRs to and is automatically mirrored to the repo backing the wiki on the main river repo

19:37 <ifreund> and then I'd just give out commit access to that wiki repo liberally

19:37 <ifreund> I wonder if anyone's set something like that up before

19:38 <ifreund> Actually, it doesn't have to be that complex

19:39 <ifreund> I can have codeberg link to an arbitrary URL from the wiki tab on the river repo

19:39 <ifreund> and that could just point to a separate river/wiki repo

19:39 <novakane> oh yeah that nice then

20:09 <peppenna> Hi guys, is there a way to query informations at runtime like the actual configuration (layouts, filters, colors, modes) or the views assigned to each tag, etc? I wish there was a query mode in riverctl, but there is not (by design, I suppose). I see there is the river-status protocol, but it looks it does not cover all configuration parameters, also I'm not sure how to use it. I just tried ristate

20:09 <peppenna> too, but that's not exactly what I'm looking for. Just for asking, what about having a simple query mode in riverctl? The way, for example, if I simply type 'riverctl background-color` (with no parameters), I get the current value. Sorry for the long question and thanks

20:19 <tiosgz> ifreund: should i delete my fork just for case? basically i'm asking if you're sure about deleting the current repo, cos idk if some data would be lost from the prs if i deleted mine

20:20 <tiosgz> (i don't think i'll have any prs in the near future, and even if so, i can always fork and then delete the fork again)

20:24 <ifreund> tiosgz: I don't think deleting your fork or not would really affect anything

20:25 <ifreund> in any case, I'm not going to do the final migration today, I was just doing a bit more research

20:25 <tiosgz> well it could mess up its relation to the main repo or something

20:25 <tiosgz> i never trust that stuff that doesn't happen very often is well-handled

20:26 <ifreund> fair enough :D

20:26 <ifreund> yeah, I could see you needing to delete your fork and create a new one if I delete and recreate the river/river repo

20:27 <ifreund> I wouldn't worry about trying to do that ahead of time though

20:27 <tiosgz> so... shall you tell me once you're ready to do the migration?

20:30 <ifreund> I mean I can if you want but I don't think it should matter if you delete/recreate your fork after I delete/recreate river/river

20:31 <ifreund> peppenna: I have no plans in the sort term to add that kind of feature sorry

20:31 <tiosgz> ok, thanks

20:32 <ifreund> in the longer term I plan to move to something more like a windom management protocol that pushes as much state as possible out of the compositor process to something like a beefed up layout generator

20:34 <ifreund> with all that state outside of river in a user-modifiable process it should be much more accessible and it should be easier to serve whatever use-case you want it for