Home freenode/#xmonad: Logs Calendar

Logs: freenode/#xmonad

←Prev  Next→
Page 1 .. 280 281 282 283 284 285 286 287 288 289 290 .. 397
— 39,606 events total
2021-04-03 05:56:20 × palo quits (~weechat@c-base/crew/palo) (Ping timeout: 265 seconds)
2021-04-03 05:56:20 palo1 is now known as palo
2021-04-03 06:26:21 × rekahsoft quits (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection)
2021-04-03 06:29:07 → rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 06:34:15 × rekahsoft quits (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection)
2021-04-03 06:36:08 × davemq quits (~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-04-03 06:37:02 → davemq joins (~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-04-03 06:38:03 → rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 06:47:47 → thoros joins (~thoros@194-166-47-167.hdsl.highway.telekom.at)
2021-04-03 06:50:01 × rekahsoft quits (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Ping timeout: 268 seconds)
2021-04-03 08:09:51 <mc47[m]> How so? That way all the statusBar functions have the same interface (at least with respect to the return type and the PP)
2021-04-03 08:32:38 <Liskni_si> on the other hand if we make statsuBarProp pure, it becomes easier to use than statusBarPipe which may nudge users towards not using pipes :-)
2021-04-03 08:33:37 <Liskni_si> anyway I just realized that withSB and withEasySB are unnecessarily IO, which would make composition awkward in my config :-)
2021-04-03 08:37:08 → materiyolo joins (~materiyol@112.204.174.249)
2021-04-03 08:45:07 <Liskni_si> hm, but by making statusBarProp pure, we'll be quite limited in what we can do there: it might be a good idea to identify dynamic status bars via Data.Unique rather than the command line, for example
2021-04-03 08:46:31 <Liskni_si> oh and since dynamicSBs is pure, withSB should definitely also be pure
2021-04-03 08:46:54 <Liskni_si> (and we might want to be consistent in the SB vs SBs thing too)
2021-04-03 08:47:29 <Solid> mc47[m]: http://ix.io/2UT2
2021-04-03 08:47:53 <Solid> maybe it's just my use-case, I don't know
2021-04-03 08:49:57 <Liskni_si> does <> work for Monoid a => IO a ?
2021-04-03 08:51:39 <Solid> IO has a Monoid a => Monoid (IO a) instance
2021-04-03 08:51:48 <Solid> I would guess it's just liftA2'ing (<>)
2021-04-03 08:52:06 <Liskni_si> then it'd probably be acceptable, yeah
2021-04-03 08:52:14 <Liskni_si> the relevant discussion was here: https://github.com/xmonad/xmonad-contrib/pull/443#discussion_r566106540
2021-04-03 08:53:02 <Liskni_si> and we apparently ended up somewhere in the middle: doesn't evaluate the SBC argument but still returns IO
2021-04-03 08:54:13 <Liskni_si> I'd personally prefer the variant that doesn't evaluate and doesn't return IO as I (intend to) compose withSB with docks and ewmh and withUrgency and other XConfig combinators
2021-04-03 08:54:29 <Liskni_si> but your config would benefit from the other variant
2021-04-03 08:56:54 <Liskni_si> (actually, I don't intend to use withSB at all, I'll have dynamicSBs the type of which is perfect now: evaluates but still manages to be pure to compose with other XConfig → XConfig stuff)
2021-04-03 08:56:55 <Solid> would it? something that takes a `PP` instead of an `X PP` and that doesn't return IO sounds exactly like what I want
2021-04-03 08:57:22 <Solid> or do you mean withSB shouldn't return IO
2021-04-03 08:57:24 <Liskni_si> it'd have to be X PP still but that's a minor detail
2021-04-03 08:57:39 <Solid> yeah that's not too bothersome
2021-04-03 08:58:06 <Liskni_si> oh, I think I was talking about withSB the whole time
2021-04-03 08:58:15 <Liskni_si> whereas you're talking about statusBarProp, sorry
2021-04-03 08:59:07 <Solid> ah I see
2021-04-03 08:59:34 <Solid> I have no opinion about withSB; for me that's just a matter of =<< vs. <$>
2021-04-03 09:00:33 <Liskni_si> well the idea was that if withSB is IO StatusBarConfig -> XConfig -> IO XConfig, your last config works as well
2021-04-03 09:00:46 <mc47[m]> Well I see your points, it would be better if we return a pure value in the statusBarProp
2021-04-03 09:01:10 <mc47[m]> It just wouldn't be usable the same way as
2021-04-03 09:01:48 <mc47[m]> statusBarPipe, which might be okay so users are nudged to the better alternative
2021-04-03 09:02:30 <mc47[m]> The IO in withSB is unnecessary, I forgot why I had it that way
2021-04-03 09:04:34 <mc47[m]> Liskin_si the problem with Data.Unique is that it doesn't have a Show instance, which means we can't persist it between restarts
2021-04-03 09:05:04 <Liskni_si> mc47[m]: oh
2021-04-03 09:13:09 <mc47[m]> I still think that we should keep X PP though
2021-04-03 09:14:39 <Liskni_si> we absolutely have to keep X PP
2021-04-03 09:15:13 <Solid> you can probably abuse Data.Unique.hashUnique and store that Int instead
2021-04-03 09:15:22 <Liskni_si> none of those clickablePP, dynamicIconsPP, workspaceNamesPP would work without X PP
2021-04-03 09:15:40 <Solid> you'll have a problem when the Ints wrap around but that's probably not going to be an issue for xmonad
2021-04-03 09:16:03 <Solid> oh but you can't construct back a unique
2021-04-03 09:16:04 <Solid> meh
2021-04-03 09:16:42 <Liskni_si> we don't really need an actual Unique, any global counter would be fine
2021-04-03 09:17:10 <mc47[m]> If people really need to launch the same command, they can always add a space to the end
2021-04-03 09:18:19 <Liskni_si> yeah, that's a good point
2021-04-03 09:38:17 → idhugo joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-04-03 09:44:10 × materiyolo quits (~materiyol@112.204.174.249) (Read error: Connection reset by peer)
2021-04-03 09:46:26 → lchapoguzman joins (~manjaro-i@172.56.17.65)
2021-04-03 09:50:27 × idhugo quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Quit: Leaving)
2021-04-03 09:57:09 → mc47 joins (~yecinem@196.179.170.230)
2021-04-03 10:01:33 × ericsagn1 quits (~ericsagne@2405:6580:0:5100:d0a0:d77a:4eaa:16c) (Ping timeout: 258 seconds)
2021-04-03 10:09:11 <mc47> I'll push a PR so we have something concrete to evaluate
2021-04-03 10:13:33 → ericsagn1 joins (~ericsagne@2405:6580:0:5100:4487:11af:62b0:68c1)
2021-04-03 11:03:05 → azg256 joins (~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 11:32:26 × lchapoguzman quits (~manjaro-i@172.56.17.65) (Remote host closed the connection)
2021-04-03 11:33:02 → geekosaur joins (ac3a5331@172.58.83.49)
2021-04-03 11:53:11 → seschwar joins (~seschwar@unaffiliated/seschwar)
2021-04-03 12:51:29 <psibi[m]> Solid: Thanks for the org mode support, I'm already finding it quite handy!
2021-04-03 13:07:54 × azg256 quits (~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 13:09:10 → azg256 joins (~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 13:21:23 → materiyolo joins (~materiyol@112.204.174.249)
2021-04-03 13:30:29 <Solid> psibi[m]: awesome! I'm glad you like it :)
2021-04-03 13:30:43 × mc47 quits (~yecinem@196.179.170.230) (Remote host closed the connection)
2021-04-03 13:30:51 → mc47 joins (~yecinem@196.179.170.230)
2021-04-03 13:35:57 × hexo quits (~hexo@gateway/tor-sasl/hexo) (Ping timeout: 240 seconds)
2021-04-03 13:35:57 × srk quits (~sorki@gateway/tor-sasl/sorki) (Ping timeout: 240 seconds)
2021-04-03 13:50:28 × geekosaur quits (ac3a5331@172.58.83.49) (Quit: Connection closed)
2021-04-03 13:57:06 × seschwar quits (~seschwar@unaffiliated/seschwar) (Quit: :wq)
2021-04-03 13:57:37 × azg256 quits (~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 13:58:28 → azg256 joins (~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 14:09:36 × ericsagn1 quits (~ericsagne@2405:6580:0:5100:4487:11af:62b0:68c1) (Ping timeout: 246 seconds)
2021-04-03 14:14:07 → Shadorain joins (uid453914@gateway/web/irccloud.com/x-cpxcxkqoopjeuddr)
2021-04-03 14:21:59 → ericsagn1 joins (~ericsagne@2405:6580:0:5100:7445:6b92:4b01:cfc6)
2021-04-03 14:34:55 × mc47 quits (~yecinem@196.179.170.230) (Remote host closed the connection)
2021-04-03 14:38:40 × azg256 quits (~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 14:40:56 → azg256 joins (~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 14:51:30 → rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 15:04:22 × azg256 quits (~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 15:05:02 → azg256 joins (~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 15:18:26 × _ashbreeze_ quits (~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-04-03 15:22:29 → _ashbreeze_ joins (~mark@64.85.214.234.reverse.socket.net)
2021-04-03 15:29:04 × azg256 quits (~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 15:29:54 → azg256 joins (~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 15:49:59 → Buliarous joins (~gypsydang@unaffiliated/buliarous)
2021-04-03 16:11:35 → qbit2821 joins (~qbit2821@94-255-133-216.cust.bredband2.com)
2021-04-03 16:13:15 × qbit2821 quits (~qbit2821@94-255-133-216.cust.bredband2.com) (Client Quit)
2021-04-03 16:17:02 → geekosaur joins (82650c7a@130.101.12.122)
2021-04-03 16:55:56 × ericsagn1 quits (~ericsagne@2405:6580:0:5100:7445:6b92:4b01:cfc6) (Ping timeout: 258 seconds)
2021-04-03 16:59:51 × xaltsc quits (~xaltsc@unaffiliated/xaltsc) (Quit: WeeChat 3.1)
2021-04-03 17:02:39 × thoros quits (~thoros@194-166-47-167.hdsl.highway.telekom.at) (Quit: WeeChat 3.0.1)
2021-04-03 17:07:46 → ericsagn1 joins (~ericsagne@2405:6580:0:5100:1b1e:6b9b:245f:d5e2)
2021-04-03 17:22:13 × materiyolo quits (~materiyol@112.204.174.249) (Quit: WeeChat 3.0.1)
←Prev  Next→
Page 1 .. 280 281 282 283 284 285 286 287 288 289 290 .. 397

All times are in UTC.