Logs: liberachat/#xmonad
| 2025-09-10 11:39:22 | <Enrico63> | -- more stuff |
| 2025-09-10 11:39:22 | <Enrico63> | : [] |
| 2025-09-10 11:39:23 | <Enrico63> | ``` |
| 2025-09-10 11:39:23 | <Enrico63> | where I don't want to change the mapping on "M-S-<Space>" that, as you made me notice, is shadowing the command to reload the config. |
| 2025-09-10 11:39:24 | <Enrico63> | So I've opted for adding this in `myConfig`, inside the curly braces: |
| 2025-09-10 11:39:24 | <Enrico63> | ``` |
| 2025-09-10 11:39:25 | <Enrico63> | , keys = \l -> M.adjust (const $ setLayout $ XMonad.layoutHook l) |
| 2025-09-10 11:39:25 | <Enrico63> | (modMask l .|. shiftMask, xK_o) |
| 2025-09-10 11:49:26 | <fizzie> | There's no existing binding for M-S-o, and M.adjust only changes existing values for keys that already exist in the map: https://hackage-content.haskell.org/package/containers-0.8/docs/Data-Map-Internal.html#v:adjust |
| 2025-09-10 11:49:37 | <fizzie> | You likely wanted M.insert instead. |
| 2025-09-10 11:49:48 | <fizzie> | (It'll replace existing values too.) |
| 2025-09-10 11:50:31 | <Leary> | Enrico63: I suggest something like this: https://paste.tomsmeding.com/R2BEETca |
| 2025-09-10 11:51:32 | <Leary> | Well, flip the order of `<>` I guess, since `Map` is left-biased. |
| 2025-09-10 11:51:47 | × | tv quits (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-09-10 12:07:03 | → | tv joins (~tv@user/tv) |
| 2025-09-10 12:10:10 | → | xnxn joins (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) |
| 2025-09-10 12:13:33 | <Enrico63> | fizzie, aaaarg, thanks! |
| 2025-09-10 12:16:48 | <Enrico63> | And also Leary, thanks for the approach to clean the code up |
| 2025-09-10 12:17:25 | → | Solid joins (~slot@xmonad/slotThe) |
| 2025-09-10 12:25:03 | × | xnxn quits (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Quit: Client closed) |
| 2025-09-10 13:17:34 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-10 13:34:24 | → | hightower4 joins (~hightower@dh207-82-17.xnet.hr) |
| 2025-09-10 13:37:00 | × | hightower2 quits (~hightower@cpe-94-253-244-59.st.cable.xnet.hr) (Ping timeout: 265 seconds) |
| 2025-09-10 13:37:35 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 2025-09-10 13:41:18 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Client Quit) |
| 2025-09-10 13:47:46 | × | Solid quits (~slot@xmonad/slotThe) (Quit: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)) |
| 2025-09-10 14:50:39 | ← | L29Ah parts (~L29Ah@wikipedia/L29Ah) () |
| 2025-09-10 15:07:55 | × | catman quits (~catman@user/catman) (Quit: WeeChat 4.7.1) |
| 2025-09-10 15:09:45 | → | catman joins (~catman@user/catman) |
| 2025-09-10 15:31:59 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-09-10 16:28:29 | → | ChubaDuba joins (~ChubaDuba@176.212.44.174) |
| 2025-09-10 17:23:23 | → | ft joins (~ft@p4fc2a25a.dip0.t-ipconnect.de) |
| 2025-09-10 18:18:07 | ← | L29Ah parts (~L29Ah@wikipedia/L29Ah) () |
| 2025-09-10 18:23:13 | × | mkoskar quits (~mkoskar@user/mkoskar) (Ping timeout: 248 seconds) |
| 2025-09-10 18:30:19 | → | mkoskar joins (~mkoskar@user/mkoskar) |
| 2025-09-10 18:36:38 | × | ChubaDuba quits (~ChubaDuba@176.212.44.174) (Quit: WeeChat 4.6.3) |
| 2025-09-10 18:39:19 | → | xnxn joins (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) |
| 2025-09-10 18:51:10 | × | xnxn quits (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Quit: Client closed) |
| 2025-09-10 19:10:22 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-09-10 19:59:36 | × | mkoskar quits (~mkoskar@user/mkoskar) (Quit: mkoskar) |
| 2025-09-10 19:59:48 | → | mkoskar joins (~mkoskar@user/mkoskar) |
| 2025-09-10 20:15:24 | × | mkoskar quits (~mkoskar@user/mkoskar) (Quit: mkoskar) |
| 2025-09-10 20:17:25 | → | mkoskar joins (~mkoskar@user/mkoskar) |
| 2025-09-10 20:30:48 | × | ghormoon quits (~ghormoon@ghorland.net) (Ping timeout: 248 seconds) |
| 2025-09-10 20:44:31 | → | ghormoon joins (~ghormoon@ghorland.net) |
| 2025-09-10 21:13:09 | × | mkoskar quits (~mkoskar@user/mkoskar) (Quit: mkoskar) |
| 2025-09-10 21:14:02 | → | mkoskar joins (~mkoskar@user/mkoskar) |
| 2025-09-11 03:25:52 | → | ChubaDuba joins (~ChubaDuba@46.147.209.108) |
| 2025-09-11 04:33:16 | × | ChubaDuba quits (~ChubaDuba@46.147.209.108) (Quit: WeeChat 4.6.3) |
| 2025-09-11 04:33:32 | → | ChubaDuba joins (~ChubaDuba@46.147.209.108) |
| 2025-09-11 05:57:44 | × | kaskal quits (~kaskal@84-115-230-9.cable.dynamic.surfer.at) (Ping timeout: 248 seconds) |
| 2025-09-11 05:58:11 | → | kaskal joins (~kaskal@2a02:8388:15bf:c200:3edd:e10d:d41e:f619) |
| 2025-09-11 06:53:42 | × | ft quits (~ft@p4fc2a25a.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-09-11 07:21:38 | × | redgloboli quits (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2025-09-11 07:23:15 | → | redgloboli joins (~redglobol@user/redgloboli) |
| 2025-09-11 08:02:44 | × | fcser quits (~fcser@booty.farted.net) (Quit: zzzzz) |
| 2025-09-11 08:09:17 | → | tremon joins (~tremon@83.80.159.219) |
| 2025-09-11 08:18:20 | × | catman quits (~catman@user/catman) (Quit: WeeChat 4.7.1) |
| 2025-09-11 08:27:14 | → | catman joins (~catman@user/catman) |
| 2025-09-11 09:14:44 | × | yaslam quits (~yaslam@user/yaslam) (Ping timeout: 258 seconds) |
| 2025-09-11 09:17:50 | → | yaslam joins (~yaslam@user/yaslam) |
| 2025-09-11 09:22:32 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 2025-09-11 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 |
| 2025-09-11 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 |
| 2025-09-11 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. |
| 2025-09-11 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? |
| 2025-09-11 09:27:51 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-11 10:08:30 | → | xnxn joins (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) |
| 2025-09-11 10:08:50 | × | xnxn quits (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Client Quit) |
| 2025-09-11 10:14:13 | × | ChubaDuba quits (~ChubaDuba@46.147.209.108) (Quit: WeeChat 4.6.3) |
| 2025-09-11 10:40:52 | → | xnxn joins (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) |
| 2025-09-11 10:42:10 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 2025-09-11 10:48:34 | × | tremon quits (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2025-09-11 10:53:37 | → | hightower2 joins (~hightower@cpe-94-253-191-254.zg.cable.xnet.hr) |
| 2025-09-11 10:54:25 | × | hightower4 quits (~hightower@dh207-82-17.xnet.hr) (Ping timeout: 244 seconds) |
| 2025-09-11 10:57:15 | × | xnxn quits (~xnxn@dslb-002-206-034-018.002.206.pools.vodafone-ip.de) (Ping timeout: 250 seconds) |
| 2025-09-11 11:07:26 | × | _qw quits (~eqw@user/eqw) (Ping timeout: 256 seconds) |
| 2025-09-11 11:33:01 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-11 11:50:13 | → | fcser joins (~fcser@booty.farted.net) |
| 2025-09-11 12:19:37 | → | tremon joins (~tremon@83.80.159.219) |
| 2025-09-11 12:37:01 | × | scardinal quits (~supreme@0x573d64a9.static.cust.fastspeed.dk) (Quit: leaving) |
| 2025-09-11 12:43:39 | × | FadedOften quits (~OftenFade@user/tisktisk) (Ping timeout: 258 seconds) |
| 2025-09-11 12:49:21 | → | scardinal joins (~supreme@0x573d64a9.static.cust.fastspeed.dk) |
| 2025-09-11 13:13:27 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 2025-09-11 13:19:02 | → | _qw joins (~eqw@user/eqw) |
| 2025-09-11 14:29:29 | × | catman quits (~catman@user/catman) (Quit: WeeChat 4.7.1) |
| 2025-09-11 14:37:46 | → | catman joins (~catman@user/catman) |
| 2025-09-11 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") |
| 2025-09-11 15:30:24 | → | Solid joins (~slot@xmonad/slotThe) |
| 2025-09-11 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? |
| 2025-09-11 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 |
| 2025-09-11 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 |
| 2025-09-11 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? |
| 2025-09-11 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) |
| 2025-09-11 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? |
| 2025-09-11 15:47:06 | <geekosaur> | correct |
| 2025-09-11 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 |
| 2025-09-11 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) |
| 2025-09-11 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. |
| 2025-09-11 15:52:54 | <Enrico63> | So just to ask a seemingly unrelated question but that maybe helps me confirm what I understand: |
All times are in UTC.