Home liberachat/#xmonad: Logs Calendar

Logs on 2025-09-11 (liberachat/#xmonad)

03:25:52 ChubaDuba joins (~ChubaDuba@46.147.209.108)
04:33:16 × ChubaDuba quits (~ChubaDuba@46.147.209.108) (Quit: WeeChat 4.6.3)
04:33:32 ChubaDuba joins (~ChubaDuba@46.147.209.108)
05:57:44 × kaskal quits (~kaskal@84-115-230-9.cable.dynamic.surfer.at) (Ping timeout: 248 seconds)
05:58:11 kaskal joins (~kaskal@2a02:8388:15bf:c200:3edd:e10d:d41e:f619)
06:53:42 × ft quits (~ft@p4fc2a25a.dip0.t-ipconnect.de) (Quit: leaving)
07:21:38 × redgloboli quits (~redglobol@user/redgloboli) (Quit: ...enter the matrix...)
07:23:15 redgloboli joins (~redglobol@user/redgloboli)
08:02:44 × fcser quits (~fcser@booty.farted.net) (Quit: zzzzz)
08:09:17 tremon joins (~tremon@83.80.159.219)
08:18:20 × catman quits (~catman@user/catman) (Quit: WeeChat 4.7.1)
08:27:14 catman joins (~catman@user/catman)
09:14:44 × yaslam quits (~yaslam@user/yaslam) (Ping timeout: 258 seconds)
09:17:50 yaslam joins (~yaslam@user/yaslam)
09:22:32 Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213)
09:26:10 <Enrico63> Hi there! In this cheatsheet (https://wiki.haskell.org/wikiupload/a/ad/Xmonad_cheatsheet_thumb.png) it is shown that you can use Super+Space to loop through the layouts from first to last and back to first, and this is what I've always used so far. However, there's also an arrow showing that you can Super+Shift+Space to go backward (even though to
09:26:10 <Enrico63> be accurate the image shows only one arrow, rather than the  3 arrows in the case of Super+Space), but in reality Super+Shift+Space by default just resets the layout https://hackage.haskell.org/package/xmonad-0.18.0/docs/src/XMonad.Config.html#keys
09:26:11 <Enrico63> So I've searched online for "xmonad jump to previous layout" but I've only found old threads suggesting it was not possible.
09:26:31 <Enrico63> Is it possible today to go to previous layout, just like the default Super+Space goes to next layout and loops?
09:27:51 × Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
10:08:30 xnxn joins (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de)
10:08:50 × xnxn quits (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Client Quit)
10:14:13 × ChubaDuba quits (~ChubaDuba@46.147.209.108) (Quit: WeeChat 4.6.3)
10:40:52 xnxn joins (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de)
10:42:10 Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213)
10:48:34 × tremon quits (~tremon@83.80.159.219) (Quit: getting boxed in)
10:53:37 hightower2 joins (~hightower@cpe-94-253-191-254.zg.cable.xnet.hr)
10:54:25 × hightower4 quits (~hightower@dh207-82-17.xnet.hr) (Ping timeout: 244 seconds)
10:57:15 × xnxn quits (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Ping timeout: 250 seconds)
11:07:26 × _qw quits (~eqw@user/eqw) (Ping timeout: 256 seconds)
11:33:01 × Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
11:50:13 fcser joins (~fcser@booty.farted.net)
12:19:37 tremon joins (~tremon@83.80.159.219)
12:37:01 × scardinal quits (~supreme@0x573d64a9.static.cust.fastspeed.dk) (Quit: leaving)
12:43:39 × FadedOften quits (~OftenFade@user/tisktisk) (Ping timeout: 258 seconds)
12:49:21 scardinal joins (~supreme@0x573d64a9.static.cust.fastspeed.dk)
13:13:27 Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213)
13:19:02 _qw joins (~eqw@user/eqw)
14:29:29 × catman quits (~catman@user/catman) (Quit: WeeChat 4.7.1)
14:37:46 catman joins (~catman@user/catman)
15:30:22 <geekosaur> Enrico63, it's still not possible because layout toggles are one way and can't easily be reversed (they're effectively functions, so can't be run "backwards")
15:30:24 Solid joins (~slot@xmonad/slotThe)
15:37:26 <Enrico63> geekosaur, thanks for answering! Though I don't really have a grasp of the explanation. But wouldn't it be possible to implement it as a repeated nextLayout based on the number of layouts? I mean, if there's N layouts, doing nextLayout N-1 times is equivalent to "go to previous layout", no?
15:38:29 <geekosaur> the number of layouts isn't fixed, even if we used TH to compute it at compile time. consider using it with onWorkspace or other conditional layout modifiers
15:40:45 <geekosaur> that's part of what we get, and what we lose, by the layout being a function. it's dynamic at runtime and can change to match pretty much anything you choose, but that means there's no fixed way to arbitrarily move through it
15:45:31 <Enrico63> Wait, I still don't get it. Why knowing the number of layouts at runtime, in a given workspace, is not enough to apply next layout that number of times?
15:46:39 <geekosaur> the specific problem with stepping backward, btw, is that the "list" of layouts is actually a chain of Choose constructors containing a flag that says whether to direct layout messages to the current layout or relay it to the next. there's no way to relay backwards (no back-links, and can't be)
15:46:59 <Enrico63> Does your point that  "they're effectively functions" mean that there isn't a "list" that has a number of elemnts being the number of layouts?
15:47:06 <geekosaur> correct
15:47:54 <geekosaur> it's a tree of constructors (which behave as functions) and the behavior of the message handler for each constructor depends on xmonad's state when the handler is invoked
15:50:06 <geekosaur> any of the XMonad.Layout.{On,Per}* modules can dynamically select branches from the tree based on pretty much any condition you feel like (and if it doesn';t already exist, it can be written). there are also modules that can prune branches at runtime (ToggleLayouts, MultiToggle)
15:51:18 <Enrico63> So it boils down to ` ||| :: forall (l :: Type -> Type) a (r :: Type -> Type). l a -> r a -> Choose l r a`, which means that when I do `layout1 ||| layout2`, I'm not really making a list out of those 2 entities.
15:52:54 <Enrico63> So just to ask a seemingly unrelated question but that maybe helps me confirm what I understand:
15:52:55 <Enrico63> I use XMobar, which shows various things, among which the name (I suppose the result of show) of the current layout. If I wanted to always show all layouts in a given moment (maybe highlighting the current one in bold), I would be hitting the same limitation, right?
15:53:18 <geekosaur> right. Choose happens to act mostly like a list, but other things act in more complex ways
15:53:46 <geekosaur> because what you're not seeing there is the LayoutClass, which is where the real work is done (in doLayout)
15:54:03 <geekosaur> which means it's not just a renamed list, it's a smart list
15:54:12 <geekosaur> it's a programmable `:`
15:54:32 <geekosaur> but it does share with lists that there can't be back-pointers, only forward
15:54:38 <Enrico63> So it is not even possible to query "what would be the next layout if I press now Super+Space?",  is it?
15:54:53 <geekosaur> right
15:55:30 <haskellbridge> <Solid (@slot-:matrix.org)> You can, however, jump to an arbitrary layout (that you know by name) by your way of "trying the next thing"
15:57:19 <Enrico63> haskellbridge, but that wouldn't solve the problem, would it? I mean, where do I get the name of the previous layout from?
15:58:37 <Solid> You can't really in a general way, which is why it doesn't solve the problem
15:58:55 <Solid> But for your user-specified layout you can make a lookup table if you want
15:59:04 <Solid> and then bind that to a key
16:00:01 <Enrico63> geekosaur, however the key bindings are `[(String, X ())]`, so the actions have all the power of `X ()`, right? In theory it would be possible to query the name of the current layout, apply next layout repeatedly until we get to the same layout by name, and keep a count in between, then reapply next layout that count-1 times. Sounds as ugly  as it
16:00:02 <Enrico63> can be, and I'm not even going to try, but I'm curious to know if it could work.
16:01:10 <Leary> You can interrogate the layout by pulling it out of the `WindowSet` and manually applying `handleMessage`/`description`.
16:02:35 <Leary> That's enough to get the "name" of the next layout, anyway, which you could indeed iterate until you see a repeat.
16:02:38 <geekosaur> there is a JumpToLayout message which works by name
16:04:19 <Enrico63> Solid, you mean that if I have `a ||| b ||| c` somewhere to make the layouts, I could have a `[a, b, c]` and then pass that to a key binding, while passing the |||-based fold to xmonad?
16:05:11 <Enrico63> The more I understand of XMonad, the more I question whether I'm turing-complete at all X)
16:12:01 <geekosaur> it's just complex in the name of flexibility
16:12:18 <geekosaur> but any time you add flexibility in one dimension, you lose it in others
16:14:03 × Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
16:15:58 Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213)
16:29:38 <Solid> Enrico63: Yeah, something like that. Query the name of the current layout, look that up in the list, and jump to the one you want
16:39:31 <Leary> Enrico63: Try this: https://gist.github.com/LSLeary/28e2157ccb7eb83cf6b63d9a5aed4dd0
16:44:12 <Solid> oh yeah doing it this way is much smarter
16:53:32 ft joins (~ft@p4fc2a25a.dip0.t-ipconnect.de)
18:22:01 × Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
19:09:02 × byorgey quits (~byorgey@user/byorgey) (Ping timeout: 260 seconds)
19:09:20 byorgey joins (~byorgey@user/byorgey)
19:19:42 Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213)
19:37:21 hightower4 joins (~hightower@cpe-94-253-191-254.zg.cable.xnet.hr)
19:39:57 × hightower2 quits (~hightower@cpe-94-253-191-254.zg.cable.xnet.hr) (Ping timeout: 260 seconds)
19:43:31 <Enrico63> Leary, it works, thnaks!
19:51:47 × Solid quits (~slot@xmonad/slotThe) (Quit: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50))
20:54:22 × Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
20:55:52 Guest1 joins (~Guest1@ip174-65-196-198.sd.sd.cox.net)
21:04:47 × Guest1 quits (~Guest1@ip174-65-196-198.sd.sd.cox.net) (Ping timeout: 250 seconds)

All times are in UTC on 2025-09-11.