Logs: freenode/#xmonad
| 2021-03-31 10:46:54 | → | novas0x2a joins (~blah@157-131-126-102.fiber.dynamic.sonic.net) |
| 2021-03-31 11:08:32 | × | materiyolo quits (~materiyol@112.204.174.249) (Read error: Connection reset by peer) |
| 2021-03-31 11:18:37 | <Solid> | 2021-03-30 13:16:42 mc47 regarding the names of the functions, how about `bindSB` instead of `makeStatusBar` and `bindAndManageSB` instead of `makeStatusBar'`? << I don't have any immediate associations to "this creates a thing" then I hear `bind' |
| 2021-03-31 11:18:46 | <Solid> | s/then/when/ |
| 2021-03-31 11:23:32 | → | cfricke joins (~cfricke@unaffiliated/cfricke) |
| 2021-03-31 12:07:02 | → | geekosaur joins (82650c7a@130.101.12.122) |
| 2021-03-31 12:08:38 | × | xaltsc quits (~xaltsc@unaffiliated/xaltsc) (Ping timeout: 258 seconds) |
| 2021-03-31 12:15:34 | × | idhugo quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 252 seconds) |
| 2021-03-31 12:26:06 | → | Shadorain joins (uid453914@gateway/web/irccloud.com/x-rvjmkohkqwhcwsoj) |
| 2021-03-31 12:30:46 | → | xaltsc joins (~xaltsc@unaffiliated/xaltsc) |
| 2021-03-31 12:30:51 | → | eb0t joins (~eblip@unaffiliated/eblip) |
| 2021-03-31 12:31:05 | × | jak_ quits (~jak@cpe-24-90-94-163.nyc.res.rr.com) (Read error: Connection reset by peer) |
| 2021-03-31 12:31:09 | → | eb0t_ joins (~eblip@unaffiliated/eblip) |
| 2021-03-31 12:32:32 | × | eblip quits (~eblip@unaffiliated/eblip) (Ping timeout: 268 seconds) |
| 2021-03-31 12:33:06 | × | def_jam quits (~eblip@unaffiliated/eblip) (Ping timeout: 260 seconds) |
| 2021-03-31 12:33:49 | eb0t_ | is now known as eblip |
| 2021-03-31 12:41:24 | → | idhugo joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-31 12:42:42 | × | geekosaur quits (82650c7a@130.101.12.122) (Ping timeout: 240 seconds) |
| 2021-03-31 12:51:12 | → | materiyolo joins (~materiyol@112.204.174.249) |
| 2021-03-31 12:54:42 | → | geekosaur joins (82650c7a@130.101.12.122) |
| 2021-03-31 12:54:46 | × | xaltsc quits (~xaltsc@unaffiliated/xaltsc) (Ping timeout: 240 seconds) |
| 2021-03-31 12:55:46 | × | materiyolo quits (~materiyol@112.204.174.249) (Client Quit) |
| 2021-03-31 13:10:09 | → | materiyolo joins (~materiyol@112.204.174.249) |
| 2021-03-31 13:11:09 | × | idhugo quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Remote host closed the connection) |
| 2021-03-31 13:11:37 | → | idhugo joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-31 13:17:01 | × | idhugo quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 260 seconds) |
| 2021-03-31 13:21:57 | × | materiyolo quits (~materiyol@112.204.174.249) (Quit: WeeChat 3.0.1) |
| 2021-03-31 13:24:50 | → | idhugo joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-31 13:25:35 | → | materiyolo joins (~materiyol@112.204.174.249) |
| 2021-03-31 13:25:49 | × | materiyolo quits (~materiyol@112.204.174.249) (Client Quit) |
| 2021-03-31 13:29:53 | × | idhugo quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 268 seconds) |
| 2021-03-31 13:37:29 | × | cfricke quits (~cfricke@unaffiliated/cfricke) (Quit: WeeChat 3.1) |
| 2021-03-31 13:39:13 | → | materiyolo joins (~materiyol@112.204.174.249) |
| 2021-03-31 13:41:33 | × | materiyolo quits (~materiyol@112.204.174.249) (Client Quit) |
| 2021-03-31 13:45:29 | × | geekosaur quits (82650c7a@130.101.12.122) (Quit: Connection closed) |
| 2021-03-31 14:21:24 | <Solid> | the CI is moving \o/ |
| 2021-03-31 14:21:36 | × | ChubaDuba quits (~ChubaDuba@5.167.116.34) (Quit: WeeChat 1.6) |
| 2021-03-31 14:21:48 | <Solid> | you even went there and prepared two variants :o |
| 2021-03-31 14:22:10 | <Liskni_si> | yeah because I didn't like the first one |
| 2021-03-31 14:22:16 | <Liskni_si> | and I don't like the second one either |
| 2021-03-31 14:22:21 | <Liskni_si> | I hate it all, to be honest |
| 2021-03-31 14:23:09 | <Liskni_si> | dozens of personhours wasted on generation of keybinding documentation that will never change and that needs to be updated manually in one other place anyway |
| 2021-03-31 14:23:53 | <Solid> | :/ |
| 2021-03-31 14:24:35 | <Liskni_si> | well, a learning experience, that's what it was :-) |
| 2021-03-31 14:25:01 | <Liskni_si> | (and it forced me to learn a bit about modern cabal and haskell-ci, so that's that) |
| 2021-03-31 14:25:22 | <Liskni_si> | https://github.com/orgs/xmonad/projects/2?fullscreen=true is nicely balanced now |
| 2021-03-31 14:27:11 | <Shadorain> | Any news on that vim module!? 🤣 |
| 2021-03-31 14:27:36 | <Shadorain> | Was such a cool idea but seemed like it went away but someone might have been working on if |
| 2021-03-31 14:27:46 | <Liskni_si> | which one? |
| 2021-03-31 14:43:34 | <Solid> | probably the modal editing one |
| 2021-03-31 14:43:40 | <Solid> | mc47[m]: wanted to revive that I think |
| 2021-03-31 14:43:52 | <Solid> | I couldn't get a hold of LSLeary and so I kind of forgot about it ^^' |
| 2021-03-31 14:44:44 | <Shadorain> | Aw darn that stinks, it's such a sick idea |
| 2021-03-31 14:44:53 | <Shadorain> | Would be a really big thing for xmonad too I think |
| 2021-03-31 14:46:41 | × | evanjs quits (~evanjs@075-129-098-007.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2021-03-31 14:49:33 | → | evanjs joins (~evanjs@075-129-098-007.res.spectrum.com) |
| 2021-03-31 14:49:38 | → | seschwar joins (~seschwar@unaffiliated/seschwar) |
| 2021-03-31 14:53:57 | <Solid> | it would certainly be a novelty; I at one point tried it and didn't _really_ get that much benefit out of it |
| 2021-03-31 14:54:19 | <Solid> | but if you often resize/re-order windows then having an extra layer just for that could indeed be a game-changer |
| 2021-03-31 14:55:44 | <Shadorain> | For sure plus the fact it would be vim like / modal would get SOOO much popularity I believe |
| 2021-03-31 14:56:10 | <Shadorain> | Think bout what the big vim users and youtubers, I think they'd jump on the bandwagon |
| 2021-03-31 14:57:11 | × | evanjs quits (~evanjs@075-129-098-007.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2021-03-31 14:57:24 | → | evanjs- joins (~evanjs@075-129-098-007.res.spectrum.com) |
| 2021-03-31 14:59:19 | <Solid> | I don't really follow the vim youtube scene ;) I somehow doubt people would switch their wm just for that |
| 2021-03-31 14:59:21 | <Solid> | but maybe I'm wrong |
| 2021-03-31 15:14:51 | → | cfricke joins (~cfricke@unaffiliated/cfricke) |
| 2021-03-31 15:21:17 | <heck-to-the-gnom> | There's this: [contrib-213](https://github.com/xmonad/xmonad-contrib/pull/213). I've not fiddled with it yet, but it looks like this could be used for vim-like mode switching. |
| 2021-03-31 15:21:56 | → | wonko7 joins (~wonko7@62.115.229.50) |
| 2021-03-31 15:24:58 | <Solid> | heck-to-the-gnom: we were referring to https://gist.github.com/LSLeary/6741b0572d62db3f0cea8e6618141b2f |
| 2021-03-31 15:25:04 | <heck-to-the-gnom> | I'm planning on using this to disable my hotkeys - because if you hit a keybind (at least one that ends up changing the stack) while xmonad's restarting then it crashes, then making escape exit that, so if the restart fails I'm not stuck. |
| 2021-03-31 15:25:08 | <Solid> | which is much more complete and doesn't rely on nested submaps |
| 2021-03-31 15:27:06 | <heck-to-the-gnom> | What's wrong with nested submaps? Haskell doesn't have closure, does it? Which means that it'd take a very very large amount of recursion for it to cause any performance issues. (at least, so I think) |
| 2021-03-31 15:34:28 | <mc47[m]> | It just doesn't work |
| 2021-03-31 15:35:07 | <mc47[m]> | If you use it to kill a window for example, it wouldn't be updated until you exit the mode |
| 2021-03-31 15:36:05 | <mc47[m]> | I'm working my way through understanding the code, but probably won't open any PR until we take care of the status bar stuff |
| 2021-03-31 15:37:27 | <heck-to-the-gnom> | Couldn't we add a `refresh` after each? |
| 2021-03-31 15:37:52 | <heck-to-the-gnom> | Or do I misunderstand `refresh`? |
| 2021-03-31 15:38:36 | <mc47[m]> | Didn't work as far as I remember |
| 2021-03-31 15:39:22 | <Solid> | I'm not sure what closures have to do with recursion depth |
| 2021-03-31 15:40:37 | × | cfricke quits (~cfricke@unaffiliated/cfricke) (Ping timeout: 268 seconds) |
| 2021-03-31 15:41:59 | <mc47[m]> | Plus there's that problem with submaps using too much CPU that we still didn't figure out how to replicate and debug |
| 2021-03-31 15:42:09 | <heck-to-the-gnom> | Closure (not to be confused with closures, this' a JS thing) is where you get to keep local variables out of scope if something was called within that scope, but is no longer there, or a function's been returned. It basically means that recursion stacks up memory really quickly. In a functional language I'd think it abhorrent to have. |
| 2021-03-31 15:42:43 | <heck-to-the-gnom> | `s/been returned/been returned from said scope/` |
| 2021-03-31 15:44:40 | <mc47[m]> | The compiler optimizes tail recursion away so that you basically only use a constant amount of stack (not only in functional languages, but it's a common optimization) if that's what you mean |
| 2021-03-31 15:45:49 | <heck-to-the-gnom> | Yeah, that, the opposite of what JS does. |
| 2021-03-31 15:47:41 | <heck-to-the-gnom> | So, refreshing & CPU are the biggest problems? |
| 2021-03-31 15:49:13 | <Solid> | I'm still not quite sure I understand your explanation |
| 2021-03-31 15:50:11 | <Solid> | and I can't tell if you're just referring to the normal use of the word closure ( https://en.wikipedia.org/wiki/Closure_(computer_programming) ), which is the only sense in which I've ever heard the word |
| 2021-03-31 15:50:18 | <heck-to-the-gnom> | see this: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures |
| 2021-03-31 15:50:32 | <heck-to-the-gnom> | It's a weird highly OOP webdev thing |
| 2021-03-31 15:52:24 | <heck-to-the-gnom> | Oh, just found this, an even simpler explanation: `the closure is a function that remembers the variables from the place where it is defined, regardless of where it is executed later`. |
| 2021-03-31 15:53:34 | <heck-to-the-gnom> | You can see where the memory gets out of hand in that MDN post. |
| 2021-03-31 15:54:26 | <Solid> | oh so it _is_ just capturing lexically scoped information |
| 2021-03-31 15:54:44 | <Solid> | of course we have that in haskell |
| 2021-03-31 15:55:04 | <Solid> | you use it every time you partially apply a function :) |
| 2021-03-31 15:56:34 | <heck-to-the-gnom> | But it's not enforced upon each recursion, in the way that JS does it. Even if it is, the point's that until I heard about the CPU usage problem & the `refresh` issue I saw no issue with the nested submap method. Though, I think they can be overcome. |
| 2021-03-31 16:00:15 | <Solid> | I'm not sure what "enforced upon each recursion" is supposed to even mean. The issue with the nested submaps is not that we reach some unfathomable recursion depth, it's that nested submaps are just extremely brittle (for reasons mentioned above) |
| 2021-03-31 16:00:18 | → | geekosaur joins (82650c7a@130.101.12.122) |
| 2021-03-31 16:10:50 | → | growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net) |
| 2021-03-31 16:11:21 | <Solid> | mc47[m]: since you're also an emacs user, I'd love to get a review from you on #500 (I won't force you though, because I know how annoying it is to review entire modules :)) |
All times are in UTC.