Is there any reason to use xmonad instead of dwm or any other WM?

100% agree. Nothing comes close to stumpwm

The virgin Xmonad vs. the chad DWM
DWM
>Under 2k SLOC
>Written in C, a universal language
>Bajillions of patches available to add whatever functionality you could possibly want, and nothing more
>Even if you don't know C, playing with DWM is a great way to learn
>Truly portable and minimal
Xmonad
>Rewrite (knockoff) of DWM
>Written in Haskell, a language used for buttfuck nothing other than Xmonad
>Needs 100's of MiB of Haskell libraries to even function
>Portable only to systems which already have the aforesaid libraries (so, none)

Attached: 1552023526236.png (957x621, 572K)

is your hard drive only 40GB? Why are you so concerned about file size so much. Especially for a window manager. It's the dumbest thing to be concerned about. so it takes 1,000 more clock cycles to start up. How often are you loading the window manager for that to be something of concern? 50 billion times per minute?

>is your hard drive only 40GB? Why are you so concerned about file size so much.
Not him but at one point I owned chromebook c720 with gentoo. It only had 16gb ssd.

Haskell

those would be reasonable concerns then. but gentoo on that seems nuts. how did you survive? a lot of disk space is required for the building. Or did you compile off machine?

Firefox has prebuilt binary in the gentoo repos. I used ramfs when compiling and 1.5gb seemed to be plenty enough for other packages. Only run updates when I was sleeping and not using the laptop. I think I once compiled something on usb3 stick.

Plenty.
>even smaller codebase due to being written in a high iq language instead of braindead cnile c
>much easier and cleaner to extend thanks to a proper module system instead of the retarded patching mechanism. again, this is due to using a good language
>i personally don't care, but for those who do, it's even more minimal: no bar by default, for example
>recompiling and restarting in-place requires no additional hacks
>adding your own layouts is trivial
Also, it's interesting to note that, while xmonad started out as pretty much a dwm clone, dwm itself incorporated new features xmonad introduced in later vanilla versions.
I've personally used dwm, awesome, xmonad and i3, and they are all good except the latter. xmonad is my favorite by far though, as it's essentially a better dwm.

>Rewrite (knockoff) of DWM
dwm has incorporated a lot of new functionality that originally came from xmonad later on.
>Needs 100's of MiB of Haskell libraries to even function
dwm relies on an entire C toolchain for mere configuration and functionality too.
>Portable only to systems which already have the aforesaid libraries (so, none)
Irrelevant when said libraries are also portable.

>there is no point in putting dwm into a bloated ecosystem.
Why? I use dwm because it works and it works well, I don't care about minimalism. It just happens that a more minimal wm also happens to work well for me.

It's much more customizable

Stumpwm is nice and all for being in CL but it's kind of a mess.
Today I added a keymap for run-or-raising applications. Make a new keymap, map a constructor lambda over a list of sets of arguments for run-or-raise, stuff the resulting commands into a keymap and bind it to a symbol. Should be simple.
But because a command definition in a keymap has to be the command given as a string, I cannot have the lambda construct a bunch of other lambdas for each binding. I have to construct commands, and those need to be named.
How do I name them? Defcommand takes a symbol and derives a string name for it. A key chord for the keymap is a string, and the arguments for run-and-raise are a string and a list of properties, keywords and strings. I could intern one of these strings to name the command with.
The key chord is a single character, it's out. The xporp list is not guaranteed to have the same structure, it's out. If you intern the cmd string, defcommand will make it a string again and when it's called, if it contains spaces for for example a call to env to set variables, the command won't run properly. It's out.
So you use gensym to name the command. It won't cause conflicts, and it does work, but not unless you do (intern (symbol-name (gensym))) to get a symbol that actually corresponds to the string the command will be called with.

And that's why, when I now change anything about this keymap, I end up interning a bunch of extra symbols I wouldn't need if I could just use lambdas in a keymap.

youtube.com/watch?v=70IxjLEmomg

st has lowest input lag of them all
it's great even without seeking minimalism