| 2025-09-11 05:25:52 +0200 | ChubaDuba | (~ChubaDuba@46.147.209.108) ChubaDuba |
| 2025-09-11 06:33:16 +0200 | ChubaDuba | (~ChubaDuba@46.147.209.108) (Quit: WeeChat 4.6.3) |
| 2025-09-11 06:33:32 +0200 | ChubaDuba | (~ChubaDuba@46.147.209.108) ChubaDuba |
| 2025-09-11 07:57:44 +0200 | kaskal | (~kaskal@84-115-230-9.cable.dynamic.surfer.at) (Ping timeout: 248 seconds) |
| 2025-09-11 07:58:11 +0200 | kaskal | (~kaskal@2a02:8388:15bf:c200:3edd:e10d:d41e:f619) kaskal |
| 2025-09-11 08:53:42 +0200 | ft | (~ft@p4fc2a25a.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-09-11 09:21:38 +0200 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2025-09-11 09:23:15 +0200 | redgloboli | (~redglobol@user/redgloboli) redgloboli |
| 2025-09-11 10:02:44 +0200 | fcser | (~fcser@booty.farted.net) (Quit: zzzzz) |
| 2025-09-11 10:09:17 +0200 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-09-11 10:18:20 +0200 | catman | (~catman@user/catman) (Quit: WeeChat 4.7.1) |
| 2025-09-11 10:27:14 +0200 | catman | (~catman@user/catman) catman |
| 2025-09-11 11:14:44 +0200 | yaslam | (~yaslam@user/yaslam) (Ping timeout: 258 seconds) |
| 2025-09-11 11:17:50 +0200 | yaslam | (~yaslam@user/yaslam) yaslam |
| 2025-09-11 11:22:32 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-09-11 11:26:10 +0200 | <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 |
| 2025-09-11 11:26:10 +0200 | <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 |
| 2025-09-11 11:26:11 +0200 | <Enrico63> | So I've searched online for "xmonad jump to previous layout" but I've only found old threads suggesting it was not possible. |
| 2025-09-11 11:26:31 +0200 | <Enrico63> | Is it possible today to go to previous layout, just like the default Super+Space goes to next layout and loops? |
| 2025-09-11 11:27:51 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-11 12:08:30 +0200 | xnxn | (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) |
| 2025-09-11 12:08:50 +0200 | xnxn | (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Client Quit) |
| 2025-09-11 12:14:13 +0200 | ChubaDuba | (~ChubaDuba@46.147.209.108) (Quit: WeeChat 4.6.3) |
| 2025-09-11 12:40:52 +0200 | xnxn | (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) |
| 2025-09-11 12:42:10 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-09-11 12:48:34 +0200 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2025-09-11 12:53:37 +0200 | hightower2 | (~hightower@cpe-94-253-191-254.zg.cable.xnet.hr) hightower2 |
| 2025-09-11 12:54:25 +0200 | hightower4 | (~hightower@dh207-82-17.xnet.hr) (Ping timeout: 244 seconds) |
| 2025-09-11 12:57:15 +0200 | xnxn | (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Ping timeout: 250 seconds) |
| 2025-09-11 13:07:26 +0200 | _qw | (~eqw@user/eqw) (Ping timeout: 256 seconds) |
| 2025-09-11 13:33:01 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-11 13:50:13 +0200 | fcser | (~fcser@booty.farted.net) |
| 2025-09-11 14:19:37 +0200 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-09-11 14:37:01 +0200 | scardinal | (~supreme@0x573d64a9.static.cust.fastspeed.dk) (Quit: leaving) |
| 2025-09-11 14:43:39 +0200 | FadedOften | (~OftenFade@user/tisktisk) (Ping timeout: 258 seconds) |
| 2025-09-11 14:49:21 +0200 | scardinal | (~supreme@0x573d64a9.static.cust.fastspeed.dk) scardinal |
| 2025-09-11 15:13:27 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-09-11 15:19:02 +0200 | _qw | (~eqw@user/eqw) eqw |
| 2025-09-11 16:29:29 +0200 | catman | (~catman@user/catman) (Quit: WeeChat 4.7.1) |
| 2025-09-11 16:37:46 +0200 | catman | (~catman@user/catman) catman |
| 2025-09-11 17:30:22 +0200 | <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") |
| 2025-09-11 17:30:24 +0200 | Solid | (~slot@xmonad/slotThe) slot |
| 2025-09-11 17:37:26 +0200 | <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? |
| 2025-09-11 17:38:29 +0200 | <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 |
| 2025-09-11 17:40:45 +0200 | <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 |
| 2025-09-11 17:45:31 +0200 | <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? |
| 2025-09-11 17:46:39 +0200 | <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) |
| 2025-09-11 17:46:59 +0200 | <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? |
| 2025-09-11 17:47:06 +0200 | <geekosaur> | correct |
| 2025-09-11 17:47:54 +0200 | <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 |
| 2025-09-11 17:50:06 +0200 | <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) |
| 2025-09-11 17:51:18 +0200 | <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. |
| 2025-09-11 17:52:54 +0200 | <Enrico63> | So just to ask a seemingly unrelated question but that maybe helps me confirm what I understand: |
| 2025-09-11 17:52:55 +0200 | <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? |
| 2025-09-11 17:53:18 +0200 | <geekosaur> | right. Choose happens to act mostly like a list, but other things act in more complex ways |
| 2025-09-11 17:53:46 +0200 | <geekosaur> | because what you're not seeing there is the LayoutClass, which is where the real work is done (in doLayout) |
| 2025-09-11 17:54:03 +0200 | <geekosaur> | which means it's not just a renamed list, it's a smart list |
| 2025-09-11 17:54:12 +0200 | <geekosaur> | it's a programmable `:` |
| 2025-09-11 17:54:32 +0200 | <geekosaur> | but it does share with lists that there can't be back-pointers, only forward |
| 2025-09-11 17:54:38 +0200 | <Enrico63> | So it is not even possible to query "what would be the next layout if I press now Super+Space?", is it? |
| 2025-09-11 17:54:53 +0200 | <geekosaur> | right |
| 2025-09-11 17:55:30 +0200 | <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" |
| 2025-09-11 17:57:19 +0200 | <Enrico63> | haskellbridge, but that wouldn't solve the problem, would it? I mean, where do I get the name of the previous layout from? |
| 2025-09-11 17:58:37 +0200 | <Solid> | You can't really in a general way, which is why it doesn't solve the problem |
| 2025-09-11 17:58:55 +0200 | <Solid> | But for your user-specified layout you can make a lookup table if you want |
| 2025-09-11 17:59:04 +0200 | <Solid> | and then bind that to a key |
| 2025-09-11 18:00:01 +0200 | <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 |
| 2025-09-11 18:00:02 +0200 | <Enrico63> | can be, and I'm not even going to try, but I'm curious to know if it could work. |
| 2025-09-11 18:01:10 +0200 | <Leary> | You can interrogate the layout by pulling it out of the `WindowSet` and manually applying `handleMessage`/`description`. |
| 2025-09-11 18:02:35 +0200 | <Leary> | That's enough to get the "name" of the next layout, anyway, which you could indeed iterate until you see a repeat. |
| 2025-09-11 18:02:38 +0200 | <geekosaur> | there is a JumpToLayout message which works by name |
| 2025-09-11 18:04:19 +0200 | <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? |
| 2025-09-11 18:05:11 +0200 | <Enrico63> | The more I understand of XMonad, the more I question whether I'm turing-complete at all X) |
| 2025-09-11 18:12:01 +0200 | <geekosaur> | it's just complex in the name of flexibility |
| 2025-09-11 18:12:18 +0200 | <geekosaur> | but any time you add flexibility in one dimension, you lose it in others |
| 2025-09-11 18:14:03 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-11 18:15:58 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
