IRCBrowse

2020/12/15

2020-12-15 00:22:32 +0100xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 260 seconds)
2020-12-15 00:26:36 +0100ddellacosta(dd@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 256 seconds)
2020-12-15 00:47:00 +0100notis(~notis@185.51.134.230) (Ping timeout: 256 seconds)
2020-12-15 00:47:58 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net)
2020-12-15 01:06:53 +0100EnchanterTimHash
2020-12-15 01:28:52 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net)
2020-12-15 01:28:54 +0100 <Liskni_si> Solid: here's a tip for your next cleanup: http://hackage.haskell.org/package/extensible-exceptions-0.1.1.4/docs/Control-Exception-Extensible…
2020-12-15 01:29:10 +0100 <Liskni_si> it's used all over the place
2020-12-15 01:32:19 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net) (Client Quit)
2020-12-15 01:46:14 +0100wonko7(~wonko7@lns-bzn-55-82-255-183-4.adsl.proxad.net) (Ping timeout: 260 seconds)
2020-12-15 04:01:47 +0100sgibber2018(~arch-gibb@208.85.237.137)
2020-12-15 04:19:45 +0100theDon(~td@muedsl-82-207-238-224.citykom.de) (Read error: Connection reset by peer)
2020-12-15 04:23:47 +0100theDon(~td@94.134.91.212)
2020-12-15 04:52:15 +0100tux1(~tux@116.251.216.46)
2020-12-15 04:58:19 +0100 <tux1> how to build xmonad-contrib from source? simply cabal install?
2020-12-15 05:03:37 +0100 <tux1> is it normal warnings to appear in xmonad contrib build>
2020-12-15 05:03:39 +0100 <tux1> ?
2020-12-15 05:04:08 +0100tux1(~tux@116.251.216.46) (Quit: WeeChat 2.9)
2020-12-15 05:29:27 +0100ChubaDuba(~ChubaDuba@37.112.227.86)
2020-12-15 05:51:38 +0100MasseR(~MasseR@51.15.143.128) (Quit: Ping timeout (120 seconds))
2020-12-15 05:52:01 +0100MasseR(~MasseR@51.15.143.128)
2020-12-15 06:19:25 +0100materiyolo(~materiyol@112.204.171.225)
2020-12-15 06:54:25 +0100 <psibi[m]> Yeah, it's normal. Although there is work being done to fix that.
2020-12-15 06:55:14 +0100 <psibi[m]> Eg: https://github.com/xmonad/xmonad-contrib/pull/432
2020-12-15 06:55:14 +0100 <psibi[m]> And I see that the person who asked the question has left the room. :-)
2020-12-15 07:00:12 +0100ChubaDuba(~ChubaDuba@37.112.227.86) (Quit: WeeChat 1.6)
2020-12-15 07:01:46 +0100palo1(~weechat@c-base/crew/palo)
2020-12-15 07:05:02 +0100palo(~weechat@c-base/crew/palo) (Ping timeout: 260 seconds)
2020-12-15 07:05:02 +0100palo1palo
2020-12-15 07:59:58 +0100palo1(~weechat@c-base/crew/palo)
2020-12-15 08:00:22 +0100 <Solid> Liskni_si: I was afraid I'd turn into "the cleanup person" ;)
2020-12-15 08:03:22 +0100palo(~weechat@c-base/crew/palo) (Ping timeout: 260 seconds)
2020-12-15 08:03:22 +0100palo1palo
2020-12-15 08:14:26 +0100 <Solid> ?tell mc47 do you want to coordinate your efforts on #433 with #408 somehow? I also have xmobar killing in my dotfiles ( http://ix.io/2I7F ) in case you need more inspriration
2020-12-15 08:14:27 +0100 <lambdabot> Consider it noted.
2020-12-15 08:16:06 +0100materiyolo(~materiyol@112.204.171.225) (Quit: WeeChat 2.9)
2020-12-15 08:17:32 +0100growpotkin(~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-15 08:21:19 +0100sfrique(~sfrique@189.122.177.88) (Ping timeout: 256 seconds)
2020-12-15 08:23:21 +0100cfricke(~cfricke@unaffiliated/cfricke)
2020-12-15 08:26:16 +0100xaltsc(~xaltsc@unaffiliated/xaltsc)
2020-12-15 08:50:52 +0100cfricke(~cfricke@unaffiliated/cfricke) (Quit: WeeChat 3.0)
2020-12-15 08:51:05 +0100cfricke(~cfricke@unaffiliated/cfricke)
2020-12-15 09:04:48 +0100notis(~notis@185.51.134.230)
2020-12-15 09:32:30 +0100mc47(~yecinem@89.246.239.190)
2020-12-15 09:35:17 +0100 <mc47> Solid thanks for the tip!
2020-12-15 09:35:34 +0100 <mc47> I thought about this more, and I had another idea that could work without even relying on persisting PIDs
2020-12-15 09:37:00 +0100HashTHC
2020-12-15 09:37:53 +0100 <mc47> We could set a custom property when launching xmobar/dzen, and add a clean-up function that goes fetches all these windows with the custom property, fetches the _NET_WM_PID and kill that
2020-12-15 09:40:41 +0100wonko7(~wonko7@2a01:e35:2ffb:7040:4535:f480:7dff:b3b5)
2020-12-15 09:40:54 +0100davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Quit: ZNC 1.8.2 - https://znc.in)
2020-12-15 09:42:06 +0100davemq(~davemq@2600:1700:b1c0:2580::4d8)
2020-12-15 09:48:41 +0100thc202(~thc202@unaffiliated/thc202)
2020-12-15 09:57:33 +0100 <Solid> do we need to set a custom property?
2020-12-15 09:58:12 +0100 <Solid> we could probably search through all windows with _NET_WM_WINDOW_TYPE_DOCK
2020-12-15 09:58:21 +0100 <Solid> and then match PIDs
2020-12-15 10:01:30 +0100 <mc47> I thought if we set a property, we won't actually care if it's xmobar or dzen or anything else
2020-12-15 10:01:44 +0100 <mc47> as long as it's a GUI and it has _NET_WM_PID, this will work on it
2020-12-15 10:03:56 +0100 <mc47> the startup hook would then look somethnig like "cleanUp >> spawnOrRestart "xmobar" >> spawnOrRestart "another-thing-that-has-net-wm-pid" >> spawnOrRestart "dzen" "
2020-12-15 10:16:27 +0100 <Solid> well if we check for _NET_WM_WINDOW_TYPE_DOCK we don't really care what status bar it is, just that it's indeed some sort of dock
2020-12-15 10:16:52 +0100 <Solid> there's apparently even a 'Query' for it in X.H.ManageDocks.checkDoc
2020-12-15 10:17:47 +0100 <Solid> we can probably just queryTree the root window on all screen and then filter that list of windows according to checkDoc (I think)
2020-12-15 10:19:20 +0100THCHigh
2020-12-15 10:23:33 +0100 <mc47> I think that would also work, but we'd be limited to docks - which seems not to be a problem, since the problem we're currently having is with docks
2020-12-15 10:28:44 +0100 <Solid> yes since this will be part of `statusBarProp` and the `docks` function that it calls internally to make space for the doc etc. also uses checkDoc and hence only cares about these windows I think that in this case we shouldn't care about just any window that sets _NET_WM_PID
2020-12-15 10:36:32 +0100 <mc47> I see. Thanks Solid! I have a good idea on how it should look like, I'll get on it soon
2020-12-15 10:39:26 +0100al3x27(~plovs@85.254.75.80)
2020-12-15 10:47:26 +0100 <Solid> sounds good!
2020-12-15 10:52:05 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net)
2020-12-15 10:58:11 +0100 <joznia> /exit
2020-12-15 10:58:13 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net) (Quit: leaving)
2020-12-15 11:11:17 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net)
2020-12-15 11:12:24 +0100 <joznia> i've got a weird problem with my colors. when the master is focused and there is >=2 windows in the stack, they appear just fine, but if there is only window in the stack, it's just a darker version of the focused color. how can i change this?
2020-12-15 11:16:20 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net) (Quit: Lost terminal)
2020-12-15 11:17:27 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net)
2020-12-15 11:29:24 +0100joznia(~reno@162-206-187-245.lightspeed.renonv.sbcglobal.net) (Quit: Lost terminal)
2020-12-15 11:38:11 +0100tomsmeding(~tomsmedin@tomsmeding.com) ("WeeChat 2.9")
2020-12-15 13:25:14 +0100davemq(~davemq@2600:1700:b1c0:2580::4d8) (Ping timeout: 264 seconds)
2020-12-15 13:26:00 +0100davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2020-12-15 13:44:17 +0100geekosaur(ac3a8b12@172.58.139.18)
2020-12-15 14:47:09 +0100sgibber2018(~arch-gibb@208.85.237.137) (Ping timeout: 256 seconds)
2020-12-15 14:59:13 +0100 <Liskni_si> mc47, Solid: I keep thinking about this xmobar restarting and I kind of wish we could use the user systemd for this or something :-)
2020-12-15 14:59:45 +0100 <Liskni_si> if only it was capable of managing multiple sessions
2020-12-15 14:59:54 +0100berberman(~berberman@unaffiliated/berberman) (Ping timeout: 258 seconds)
2020-12-15 14:59:57 +0100berberman_(~berberman@unaffiliated/berberman)
2020-12-15 15:00:38 +0100 <Solid> Liskni_si: That sounds even less portable than using pidfds :D
2020-12-15 15:00:59 +0100 <Liskni_si> s/we/I/ then :-)
2020-12-15 15:01:35 +0100 <Liskni_si> I tried to migrate my .xsession to user systemd yesterday, and it almost works, but I keep hitting a roadblock with support for multiple sessions
2020-12-15 15:02:04 +0100 <Liskni_si> but it would be so easy to just delegate restarting of crashed comptons and alttabs to systemd and forget about it
2020-12-15 15:02:52 +0100 <mc47> I'm even more clueless when it comes to systemd than when it comes to X11
2020-12-15 15:04:55 +0100 <mc47> BTW Solid I'm gonna rebase my branch on top of yours when I'll submit the PR, so when everything is reviewed we should merge yours first
2020-12-15 15:05:09 +0100 <Liskni_si> well I'm just fantasizing
2020-12-15 15:05:54 +0100Soliduses runit so wants to stay as far away from systemd as possible
2020-12-15 15:05:55 +0100 <Solid> :>
2020-12-15 15:06:24 +0100 <Liskni_si> I love all the tools that systemd gives me: all the logging, status, process trees, etc.
2020-12-15 15:06:53 +0100 <Liskni_si> and I'd love to have something like that for these little things that my xmonad invokes per-session
2020-12-15 15:07:14 +0100 <Solid> mc47: sounds good; ping me when you have it up and I'll convert mine from a draft to a normal pr
2020-12-15 15:07:24 +0100 <Liskni_si> doesn't need to be systemd, it's that I'd be losing all the tools and the associated muscle memory
2020-12-15 15:13:11 +0100 <mc47> I have no idea why I feel intimidated by systemd.. Whenever I see it I'm like "oh please have mercy"
2020-12-15 15:13:48 +0100 <mc47> Solid sure, it might take till the weekend though
2020-12-15 15:14:10 +0100 <Solid> oh do take your time; no rush in xmonad land :)
2020-12-15 15:14:15 +0100 <Liskni_si> possibly because one needs to learn a lot of stuff before it starts to make sense
2020-12-15 15:17:31 +0100 <Liskni_si> for people like me who already know the concepts and all the troubles, systemd is a welcome abstraction, but it sure can be intimidating
2020-12-15 15:17:38 +0100 <Liskni_si> just like any part of the modern desktop :-)
2020-12-15 15:18:36 +0100 <mc47> It is intimidating, I remember it took me so much time to make xmonad work with KDE and understand what's going on
2020-12-15 15:18:42 +0100kmicumumbles something about modern desktop defining rules in js and pulling in Rust to compile Spidermonkey.
2020-12-15 15:20:09 +0100tugrik(~username@war.funkyjesus.org) (Quit: WeeChat 2.9)
2020-12-15 15:22:14 +0100 <geekosaur> dunno, I keeep hearing about systemd viruses and wondering if we'd been better off with sysvinit
2020-12-15 15:27:55 +0100 <mc47> Liskni_si I'm looking at your dotfiles, in particular the killPid function; do you think we should implement something similar, or is it enough to just traverse the PIDs and send sigTERM?
2020-12-15 15:30:36 +0100growpotkin(~growpotki@130-45-30-154.dyn.grandenetworks.net)
2020-12-15 15:30:55 +0100mrbirkov(uid453780@gateway/web/irccloud.com/x-edxiwdvttjunrmar)
2020-12-15 15:34:47 +0100 <Solid> I'm not sure what race_ even does if xmonad is not compiled with -threaded
2020-12-15 15:34:53 +0100 <Solid> which afaik it's not by default
2020-12-15 15:39:10 +0100geekosaur(ac3a8b12@172.58.139.18) (Remote host closed the connection)
2020-12-15 15:40:52 +0100 <Liskni_si> I had to make it more complex because my xmonad would get stuck in endless wait sometimes
2020-12-15 15:41:26 +0100sfrique(~sfrique@189.122.177.88)
2020-12-15 15:41:58 +0100 <mc47> ah alright
2020-12-15 15:45:13 +0100tugrik(~username@war.funkyjesus.org)
2020-12-15 15:46:30 +0100 <Solid> it may be worth sending a sigKILL if the sigTERM wasn't successful
2020-12-15 15:47:23 +0100 <Solid> `signalProcess` should throw an IOError if something goes wrong on the sigTERM
2020-12-15 15:48:14 +0100 <Liskni_si> it's not going to give you an error if xmobar decides to ignore the sigterm
2020-12-15 15:48:23 +0100 <Solid> oh I see
2020-12-15 15:51:47 +0100berberman_(~berberman@unaffiliated/berberman) (Ping timeout: 260 seconds)
2020-12-15 15:52:25 +0100berberman(~berberman@unaffiliated/berberman)
2020-12-15 16:33:24 +0100seschwar(~seschwar@unaffiliated/seschwar)
2020-12-15 16:33:47 +0100cfricke(~cfricke@unaffiliated/cfricke) (Ping timeout: 260 seconds)
2020-12-15 16:43:42 +0100lally(sid388228@gateway/web/irccloud.com/x-udblkappiwdfbwqx) (Ping timeout: 260 seconds)
2020-12-15 16:46:18 +0100lally(sid388228@gateway/web/irccloud.com/x-qptpvlldxpkwwzmr)
2020-12-15 16:56:05 +0100 <Solid> just wondering; why do we use Data.Map instead of Data.Map.Strict
2020-12-15 16:56:37 +0100 <Solid> basically all of the uses I've come across would be better modelled by a strict map
2020-12-15 16:57:52 +0100 <Liskni_si> no idea
2020-12-15 16:58:24 +0100 <Liskni_si> we also use String instead of ByteString or Text :-/
2020-12-15 16:59:01 +0100 <Solid> well, we can put that down to historical baggage :P
2020-12-15 16:59:25 +0100 <Solid> actually, maybe the strict/lazy map split didn't exist either back in the day
2020-12-15 17:04:13 +0100 <al3x27> is there an example how to use loghook (which i now use for xmobar) to log to sndErr?
2020-12-15 17:04:47 +0100 <al3x27> stdErr
2020-12-15 18:01:55 +0100geekosaur(42d52137@66.213.33.55)
2020-12-15 18:06:15 +0100 <geekosaur> fwiw Data.Map.Strict also did not exist in the early days of xmonad
2020-12-15 18:07:04 +0100 <geekosaur> may have to watch out for compatibility breaks if we change it at this point, though
2020-12-15 18:20:42 +0100 <geekosaur> al3x27, possibly somewhere in DynamicLog to show DynamicLogString or w/e
2020-12-15 18:21:18 +0100 <geekosaur> generally logging to stderr means you'r debugging and I at least tried to hide that in debug modules rather than make users futz with stdErr directly
2020-12-15 18:22:57 +0100 <al3x27> geekosaur: i'm a new xmonad user, and still can't always follow what all the haskell does, so having some way of seeing values etc might help to muddle thru
2020-12-15 18:23:05 +0100 <al3x27> thanks, btw
2020-12-15 18:23:58 +0100 <geekosaur> the basic mechanism is: io $ hPutStrLn stdErr "whatever"
2020-12-15 18:24:43 +0100 <geekosaur> (where `io` is just an alias / shorthand for `liftIO`)
2020-12-15 18:25:05 +0100 <geekosaur> you may also find the Debug.Trace module of interest
2020-12-15 18:29:16 +0100 <al3x27> geekosaur: i can work with that, thanks!
2020-12-15 18:31:14 +0100jamik(~james@d75-159-1-216.abhsia.telus.net)
2020-12-15 18:37:34 +0100 <jamik> Hey guys, why is xmonad intent on creating a ~/.xmonad directory when I have a $XDG_CONFIG_HOME/xmonad directory? Also I'm having trouble recompiling (https://dpaste.com/BAMJBV5VU). I tried using ghci to run `:set -package xmonad` to no avail. I know it's likely something basic but I'm not too familiar with ghc.
2020-12-15 18:40:39 +0100 <geekosaur> is $XDG_CONFIG_HOME set when xmonad starts? also, how did you install xmonad?
2020-12-15 18:41:01 +0100 <geekosaur> if you used stack or cabal v2+ then you need a build script
2020-12-15 18:42:15 +0100 <geekosaur> although "hidden package" sounds like it's there but disabled, possibly in the global package scope from a system package manager. this may again require a build script
2020-12-15 18:43:04 +0100 <Solid> if it's hidden you can try `ghc-pkg expose xmonad`
2020-12-15 18:44:10 +0100 <geekosaur> if it's in global scope that will require sudo… or preferably some other solution
2020-12-15 18:44:40 +0100 <jamik> Ah yes I forgot to mention I have installed xmonad with its ebuild in the main Gentoo portage tree, though it shows up in the output of ghc-pkg list. Yes $XDG_CONFIG_HOME is set and when I rm -r ~/.xmonad before recompiling it will look in the correct place initially (e.g. "$XDG_CONFIG_HOME/xmonad/build does not exist, using ghc) but it will then create ~/.xmonad anyway.
2020-12-15 18:45:00 +0100 <geekosaur> I'm unclear but get the impression the global package scope defaults hidden in recent ghc, to try to avoid it messing with builds
2020-12-15 18:45:34 +0100 <geekosaur> hm. some extension perhaps still uses it? are there any possibly hidden files in ~/.xmonad afterward?
2020-12-15 18:46:22 +0100 <jamik> Solid: I ran ghc-pkg expose xmonad previously but I it didn't seem to change anything
2020-12-15 18:46:24 +0100 <geekosaur> every so often we find an extension which does that and which didn't get updated, and if ~/.xmonad exists it gets used so we don't break existing configs
2020-12-15 18:46:42 +0100 <jamik> Yeah it dumps the xmonad.errors file there
2020-12-15 18:46:53 +0100 <jamik> but no hidden files
2020-12-15 18:49:18 +0100 <jamik> I'm fine with using ~/.xmonad for now but I'd like to get the recompilation working, I don't understand why xmonad is considered hidden after running ghc-pkg expose on it
2020-12-15 18:49:58 +0100 <geekosaur> well, I just partially answered one unrelated question, trying to check if were doing that wrong for some reason (still checking)
2020-12-15 18:51:40 +0100 <jamik> Thank you for your help, it's been bothering me..
2020-12-15 18:53:58 +0100 <geekosaur> I can't see why we would be since the file is created on any rebuild, so putting it in the wrong place should have been fairly obvous
2020-12-15 18:55:50 +0100 <al3x27> jamik: as far as XDG_CONFIG_HOME is concerned, xmonad doesn't care, but you can 'force' xmonad to do the right thing using XMONAD_CONFIG_DIR etc (see http://ix.io/2IbD for a variation)
2020-12-15 18:56:41 +0100 <Solid> al3x27: xmonad does care about XDG_{CONFIG,DATA,CACHE}_HOME
2020-12-15 18:57:18 +0100 <Solid> it just prefers the XMONAD_ env variables or ~/.xmonad, if any of these exist
2020-12-15 18:57:37 +0100 <jamik> Yeah I read the order of consideration is $XMONAD_CONFIG_DIR > $XDG_CONFIG_HOME/xmonad > ~/.xmonad
2020-12-15 18:57:44 +0100 <geekosaur> except in this case it seems to be creating ~/.xmonad afterward
2020-12-15 18:58:10 +0100 <geekosaur> I just confirmed it's doing the right thing, not forcing it into ~/.xmonad unless for some reason $XMONAD_DATA_DIR is set
2020-12-15 18:58:21 +0100 <geekosaur> wit xmonad.errors, that is
2020-12-15 18:59:38 +0100mrbirkov(uid453780@gateway/web/irccloud.com/x-edxiwdvttjunrmar) (Quit: Connection closed for inactivity)
2020-12-15 19:00:08 +0100 <jamik> so it always writes errors to ~/.xmonad, even if it tries to recompile using $XDG_CONFIG_HOME/xmonad? That would be the behaviour I'm getting
2020-12-15 19:00:52 +0100 <geekosaur> no, it should be using wherever xmonad-$arch-$os is found (or written) which should be based on where xmonad.hs is found
2020-12-15 19:01:44 +0100 <geekosaur> last time something like this came up we found an extension writing a data file to ~/.xmonad directly instead of using the functions to find the appropriate directory, but you say that's not happening here
2020-12-15 19:02:27 +0100 <jamik> Yeah I'm just trying to test recompiling the default config
2020-12-15 19:04:39 +0100 <jamik> I have not yet run xmonad successfully on this machine, I just ran find / xmonad-x86_64-linux and it didn't find anything
2020-12-15 19:04:54 +0100 <Solid> this is seriously weird; it sets all the dirs at the start of the recompilation, so if ~/.xmonad doesn't exist when you start the recompile nothing should be created
2020-12-15 19:05:30 +0100 <Solid> jamik: just to make sure, you do have XDG_DATA_HOME set?
2020-12-15 19:06:03 +0100 <Solid> or, if not, ~/.local/share exists
2020-12-15 19:06:05 +0100 <jamik> No I don't have $XDG_DATA_HOME set, I have $XDG_CONFIG_HOME set
2020-12-15 19:06:09 +0100 <geekosaur> hm, actually this looks to me like, if the comments are right, you have to have precreated $XDG_DATA_DIR/xmonad or it will create ~/.xmonad
2020-12-15 19:06:26 +0100 <geekosaur> not just $XDG_CONFIG_DIR/xmonad
2020-12-15 19:06:53 +0100 <Solid> oh right, it's ~/.local/share/xmonad that has to exist
2020-12-15 19:06:58 +0100 <jamik> Ahh
2020-12-15 19:07:07 +0100 <jamik> okay I'll create that
2020-12-15 19:07:42 +0100 <geekosaur> I wonder if there is a way to fix this that doesn't screw over anyone with an existing config but some other files in XDG locations
2020-12-15 19:08:06 +0100 <jamik> okay so that problem is solved, thanks guys! Now the package (XMonad) is still hidden and compilation is still unsuccessful
2020-12-15 19:08:19 +0100 <geekosaur> suppose ideally we'd check for where xmonad.hs is found and set the rest based on that instead of checking separately for each one
2020-12-15 19:09:07 +0100 <jamik> I didn't even realize xmonad was trying to use the data dir
2020-12-15 19:09:20 +0100 <jamik> I just assumed it would throw everything in the config dir
2020-12-15 19:09:29 +0100 <Solid> how would you do the data-dir/cfg-dir split in that case?
2020-12-15 19:10:44 +0100 <jamik> Me? I wouldn't, I was simply ignorant of how xmonad works. The other WMs I use don't have such a split
2020-12-15 19:10:53 +0100 <geekosaur> we used to not do that. and arguably we're still doing it wrong because the compiled config is cache, not data (it can be regenerated by recompiling)
2020-12-15 19:10:56 +0100 <Solid> nono, sorry, I was talking to geekosaur
2020-12-15 19:11:07 +0100 <Solid> jamik: in that case you should also create $XDG_CACHE_DIR/xmonad, as some extensions use that
2020-12-15 19:11:12 +0100 <geekosaur> but we've kinda halfassed the whole XDG thing
2020-12-15 19:12:22 +0100 <Solid> CACHE_HOME*
2020-12-15 19:12:31 +0100 <Solid> too many xdg variables
2020-12-15 19:12:55 +0100 <geekosaur> this at least needs to be documented better that you need to precreate those, or we need to swap the defaults if we find xmonad.hs in an XDG location
2020-12-15 19:13:43 +0100 <jamik> Yeah good idea Solid, I'll create that now
2020-12-15 19:17:12 +0100 <Solid> geekosaur: What would a good default behaviour look like? Check for the XMONAD_ variables and if they are not set; look for xmonad.hs in $XDG_CONFIG_HOME/xmonad and throw everything in there?
2020-12-15 19:17:14 +0100 <jamik> Isn't it sufficient to use any set XDG variables when they are set, otherwise use the default locations (e.g. in my case putting xmonad.errors in .local/share instead of ~/.xmonad, because $XDG_CONFIG_HOME/xmonad was found but $XDG_DATA_DIR was unset)
2020-12-15 19:17:48 +0100 <jamik> $XDG_DATA_HOME***
2020-12-15 19:18:24 +0100geekosaur(42d52137@66.213.33.55) (Ping timeout: 245 seconds)
2020-12-15 19:18:28 +0100tux1(~tux@116.251.216.46)
2020-12-15 19:20:27 +0100 <Solid> jamik: the problem is that it tries putting them in ~/.local/share/xmonad
2020-12-15 19:21:10 +0100 <Solid> so it checks for XDG_WHATEVER_{HOME,DIR} and if that doesn't exist of course uses a standard path, but always appends the xmonad dir to that
2020-12-15 19:21:33 +0100 <Solid> at this point I feel like the split overcomplicates things and using the config dir is probably sufficient
2020-12-15 19:22:04 +0100 <Solid> but I'm not sure how backwards compatible such a change would be
2020-12-15 19:22:40 +0100 <jamik> I see. Well I can't comment on the pros/cons of the split because I haven't wrote any plugins for xmonad, but I'm inclined to agree with you
2020-12-15 19:30:16 +0100geekosaur(42d52137@66.213.33.55)
2020-12-15 19:31:53 +0100 <geekosaur> at one point we did just that, but it violates XDG to put it all in the same place like that. I'm not sure when the current setup showed up though
2020-12-15 19:34:34 +0100 <Solid> mh I see
2020-12-15 19:34:44 +0100 <Solid> so probably no hope of ever seeing this changed? :/
2020-12-15 19:35:43 +0100 <geekosaur> probably not, which is why I recommended the other way which would fix it without breaking things for others
2020-12-15 19:36:28 +0100 <geekosaur> in fact it occurs to me that we should just determine all these dirs up front and stuff them in XConf (not XConfig), then change the function calls that use them to just look them up instead of doing a search each time
2020-12-15 19:37:23 +0100 <geekosaur> which both makes it easier to set the defaults based on where we found xmonad.hs, and should speed up anything else using them (not that that should be a major performance issue unless some extension is being really stupid)
2020-12-15 19:37:42 +0100 <jamik> up front meaning upon xmonad startup? Sounds sensible to me
2020-12-15 19:37:46 +0100 <geekosaur> yes
2020-12-15 19:41:18 +0100tux1(~tux@116.251.216.46) (Quit: WeeChat 2.9)
2020-12-15 19:59:41 +0100 <Solid> geekosaur: just to be clear I'm understanding you correctly: 1. see if xmonad.hs is in $XMONAD_CONFIG_DIR > ~/.xmonad > $XDG_CONFIG_HOME 2. according to the selection in 1., use XMONAD_ env variables > use xdg_ > use ~/.xmonad 3. put these three dirs into XConf, so `recompile` can simply read them from there instead of determining them every time
2020-12-15 20:00:26 +0100 <geekosaur> yes. and other consumers, e.g. Prompt's history file
2020-12-15 20:01:03 +0100 <geekosaur> and there's at least one layout that reads stuff from a file when a workspace is made current (not TopicSpaces but something similar)
2020-12-15 20:01:22 +0100 <Solid> ah yeah, change all of these as well of course
2020-12-15 20:01:36 +0100 <Solid> okay I'll create an issue in xmonad/xmonad to have that there
2020-12-15 20:02:23 +0100 <geekosaur> you'l see all those functions are together and do pretty much the same thing with different default dirs, and do it whenever called instead of remembering the result
2020-12-15 20:03:36 +0100berberman_(~berberman@unaffiliated/berberman)
2020-12-15 20:04:39 +0100berberman(~berberman@unaffiliated/berberman) (Ping timeout: 258 seconds)
2020-12-15 20:07:48 +0100 <Solid> yeah, that part of the code always struck me as a bit weird
2020-12-15 20:10:45 +0100 <geekosaur> hm, actually stuffing thta into XConf won't work for the biggest use case: recompiling xmonad, which is before XConf exists. sigh
2020-12-15 20:11:09 +0100 <geekosaur> at least, the possible-recomp on startup
2020-12-15 20:12:36 +0100 <geekosaur> can't even compute them early and use them late because there's an exec() hopefully in between
2020-12-15 20:13:21 +0100 <geekosaur> so we end up computing them twice ayway. but we'd at lest avoid them getting different answers, as with the case that set this whole thing off
2020-12-15 20:15:02 +0100 <Solid> ah yeah you're right
2020-12-15 20:15:47 +0100 <Solid> I think computing them twice is not big deal, it's not computationally intensive after all
2020-12-15 20:15:53 +0100 <Solid> *not a
2020-12-15 20:16:05 +0100 <Solid> still probably the best solution that maintains backwards compatability
2020-12-15 20:22:20 +0100 <Solid> okay I've created an issue
2020-12-15 20:26:34 +0100 <geekosaur> blugg
2020-12-15 20:28:09 +0100 <geekosaur> I guess we could just have recompile always recompute them, but that's most of the use they get so it kinda makes caching the result mostly pointless.
2020-12-15 20:28:58 +0100 <geekosaur> but then that brings back the original problem that we want to determine defaults based on where we found xmonad.hs, not which dirs exist, so we want to compute all of them at once when we have all that information together
2020-12-15 20:30:36 +0100notis(~notis@185.51.134.230) (Ping timeout: 256 seconds)
2020-12-15 20:31:43 +0100 <Solid> I mean we could compute them once in `xmonad` and then awkwardly thread them through to `buildLaunch` and these kinds of functions
2020-12-15 20:31:57 +0100 <Solid> but that's a pretty "meh" solution
2020-12-15 20:32:25 +0100 <geekosaur> you also have to thread them across an executeFile sometimes (usually, if there's a compiled config or one can be built)
2020-12-15 20:32:59 +0100 <geekosaur> which i why "compute twice" and why the first one doesn't have the XConf until it has failed to find or build a compiled config
2020-12-15 20:46:46 +0100 <Solid> ah I think I understand what you mean now
2020-12-15 20:47:10 +0100 <Solid> this seems reasonably straightforward still (said he, before having attempted to write any code)
2020-12-15 20:53:21 +0100 <geekosaur> it's straightforward,, just annoying
2020-12-15 21:08:17 +0100wonko7(~wonko7@2a01:e35:2ffb:7040:4535:f480:7dff:b3b5) (Ping timeout: 258 seconds)
2020-12-15 21:23:50 +0100wonko7(~wonko7@lns-bzn-55-82-255-183-4.adsl.proxad.net)
2020-12-15 21:43:37 +0100HighPsillyCybin
2020-12-15 21:47:25 +0100notis(~notis@185.51.134.229)
2020-12-15 22:07:56 +0100ddellacosta(dd@gateway/vpn/mullvad/ddellacosta)
2020-12-15 22:53:39 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net) (Remote host closed the connection)
2020-12-15 22:54:15 +0100geekosaur(42d52137@66.213.33.55) (Remote host closed the connection)
2020-12-15 22:57:22 +0100hexo-(~hexo@83.167.228.130) (Quit: ZNC - http://znc.in)
2020-12-15 22:57:49 +0100MasseR(~MasseR@51.15.143.128) (Ping timeout: 264 seconds)
2020-12-15 22:59:03 +0100Liskni_si(~liskin@ackle.nomi.cz) (Ping timeout: 260 seconds)
2020-12-15 22:59:57 +0100hexo-(~hexo@83.167.228.130)
2020-12-15 23:00:00 +0100Liskni_si(~liskin@ackle.nomi.cz)
2020-12-15 23:00:13 +0100MasseR(~MasseR@51.15.143.128)
2020-12-15 23:03:50 +0100xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 272 seconds)
2020-12-15 23:14:22 +0100mc47(~yecinem@89.246.239.190) (Remote host closed the connection)
2020-12-15 23:22:14 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net)
2020-12-15 23:22:19 +0100ashbreeze(~mark@184-157-32-85.dyn.centurytel.net)
2020-12-15 23:23:13 +0100ashbreeze(~mark@184-157-32-85.dyn.centurytel.net) (Client Quit)
2020-12-15 23:23:16 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net) (Client Quit)
2020-12-15 23:23:46 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net)
2020-12-15 23:32:59 +0100thc202(~thc202@unaffiliated/thc202) (Quit: thc202)
2020-12-15 23:48:15 +0100seschwar(~seschwar@unaffiliated/seschwar) (Quit: :wq)
2020-12-15 23:48:36 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net) (Remote host closed the connection)
2020-12-15 23:49:56 +0100_ashbreeze_(~mark@184-157-32-85.dyn.centurytel.net)