07:30 <LarstiQ> ifreund: cheers, I'll see if we can manage that. Visiting an elderly relative is the main goal.

10:33 <dotdash> Hi, discovered river the other day and love it so far. One oddity I've noticed is that when I close a window, the focus doesn't seem to jump to the next window in the stack but seems to depend on the order in which the windows have been created. Is this a known issue/feature and/or is there an option to change this? I'd always like to have the

10:33 <dotdash> focus jump to the next window in the stack when I close a window.

10:38 <dotdash> For example, if I create three terminal windows, then focus the one first created (bottom of the stack), move it to the top of the stack (zoom) and then close it, then the last created window becomes top of the stack, but the other window gets the focus.

11:33 <LarstiQ> dotdash: hmm, I don't get that with `riverctl default-attach-mode bottom

11:33 <LarstiQ> `

11:33 <LarstiQ> wonder if I'm reproducing that exactly enough

11:36 <ifreund> dotdash: the idea is that whenever no window is focused (i.e. because the focused window was closed or tags have been switched) river focuses whichever visible window last had focus

11:36 <ifreund> there is no configuration option to change this behavior

11:37 <ifreund> also, behold my first ever lispy macro, a wayland scanner in less than 100 lines: https://codeberg.org/ifreund/janet-wayland/src/commit/e181b692ec1d4da5cff20e8b4f553693ba9745c5/src/wayland.janet#L82

11:38 <ifreund> It took me a while to get all the quoting right, definitely a steep learning curve

11:38 <ifreund> but oh so powerful

11:38 <dotdash> Ah! It's last focus, not order of creation, that makes sense. I guess that just happened to match up due to the way I tested things. Thank you!

11:38 <ifreund> no problem!

12:04 <stib> Hi, I'm looking through the manpage for riverctl, but can't find what I'm looking for. Is there a way to scale the output on hi DPI displays?

12:09 <dotdash> river doesn't do display configuration itself, it needs external tools to do that, see https://codeberg.org/river/wiki#how-can-i-configure-outputs -- I personally just use wl-randr as I have a static setup and it does all I need

12:10 <dotdash> *wlr-randr

12:19 <stib> Thanks, I'll go look that up.

12:29 <ifreund> finally a window opened with janet: https://codeberg.org/ifreund/janet-wayland/src/commit/5343f4b4086ef916ad66b02ff48ecd1add736748/example/hello.janet

12:29 <stib> Nice! wlr-randr Does a good job, the scaling looks fine.

12:29 <ifreund> no separate build step required because macros, making this quite ergonomic for scripting

12:30 <ifreund> there's still a lot of polish to do, but the proof of concept is good :)

12:42 <ifreund> leon-p: I am curious to see what kind of high level API you come up with in scheme, I wonder if something more "functional" would be possible

12:43 <ifreund> though I guess the wayland protocol itself is inherently object oriented

12:49 <leon-p> OOP and FP aren't necessarily at odds, f.e. see guiles GOOPS which I am also using for my wayland implementation

12:50 <leon-p> although in scheme it is still pretty canonical to use imperative programming

12:53 <leon-p> huh, janet macros are quite different from scheme macros apparently

13:58 <szgy> ifreund: that's pretty neat! I've played with a janet a couple of times! Wondering, whats lemongrass? its seems you pull that lib but couldn't find a repo anywhere. Waiting for that `build.janet` so I can _sort of_ play myself :)

14:01 <leon-p> probably an XML parser

14:03 <ifreund> szgy: lemongrass is this: https://github.com/pyrmont/lemongrass

14:04 <ifreund> probably the most ergonomic XML "parsing" I've ever experienced

14:04 <ifreund> apparently the idea is copied from the clojure ecosystem

14:05 <ifreund> as for how to build it, I haven't put effort into making things easy yet. Currently you need to run build.sh from the root of the repo to build wayland-native.c

14:06 <ifreund> and have the lemongrass repo in your $JANET_PATH

14:06 <leon-p> lisp in general is well suited for parsing XML. In guile I can tokenize XML into a list of symbolds with sxml and use the typical match macro to parse that

14:07 <ifreund> The janet build/package management seems to be in flux and nowhere near as nice as build.zig yet, I will probably use zig to build my own janet projects

14:09 <ifreund> leon-p: this thing goes a step further than that. there's no "match token" loop, it converts the XML to a native janet data structure that you can then inspect/iterate over using the standard functions :)

14:09 <ifreund> and yes, janet is very different from scheme

14:10 <ifreund> macros aren't hygenic

14:10 <ifreund> I think overall it's simpler though IMO, I hate the thing in scheme where there are like 5 different kinds of equality

14:11 <ifreund> in janet equality is so much simpler

14:11 <leon-p> there are actually only two types of equality: checking whether objects are the same or whether they have the same value, the latter only being relevant for immediate vs. non-immediate objects

14:12 <leon-p> the other equality operators are just macros over lists

14:13 <ifreund> https://standards.scheme.org/corrected-r7rs/r7rs-Z-H-8.html#TAG:__tex2page_sec_6.1

14:13 <ifreund> this lists 3

14:13 <ifreund> I guess I am probably wrong about 5 though

14:14 <leon-p> equal? can be implemented as a macro using eqv? so doesn't really count IMO

14:14 <ifreund> The numerical tower is also cool, but a significant complexity increase over "everything is a f64"

14:15 <leon-p> it's quite similar to a C-like language w.r.t. comparisons. You can compare pointers or you can compare the memory at the pointer address. For comparing linked lists you'd write a new function, but I doubt anyone would call that an additional type of equality

14:16 <ifreund> I guess scheme doesn't have a distiction between immutable and mutable values like janet does

14:17 <ifreund> janet always compares immutable values by value and mutable values by reference

14:17 <leon-p> ah that makes sense

14:18 <ifreund> also, since you understand scheme's hygenic macros better than I do, is it possible to write the equivalent of the scan macro I shared in scheme?

14:18 <ifreund> Do macros get to read from the filesystem and have side effects?

14:18 <ifreund> (at compile time)

14:19 <leon-p> you can control that with (eval-when )

14:20 <leon-p> although I have enver tried doing file system operationg at compile time

14:20 <leon-p> I have found that parsing the wayland xml is pretty fast actually, about 100ms, so I just do that at startup

14:21 <leon-p> if I wnated to speed that up, I would probably store the GOOPS state in a chache file