> just want my normal windows with title bar and
> buttons back
It made my 24inch screen at the time far more manageable but it was supremely frustrating if I sometimes wanted a certain window to remain in a certain position without being disturbed.
Languages are our best tool for expressivity.
And a well-designed language is better than an ad hoc configuration language any day of the week (see e.g. vimscript for how not to do configuration).
By choosing to use a full language for configuration, we have made possible an enormous ecosystem of user-contributed components -- because the configuration language was rich enough to support them.
You could have accomplished all of this just fine but left the config in yaml and I would have personally been a happier person for it.
You could implement all sorts of funky config formats, by translating them down to the underlying (richer) format. Go nuts!
Yes, yes, it might make me a better person but I want to try XMonad more than I want to fuck around with Haskell.
I think the fact that no one has bothered to write a limited configuration format is telling. It seems to indicate that people who have learned Haskell don't see any benefit in it and appreciate the flexibility offered to them.
> I think the fact that no one has bothered to write a
> limited configuration format is telling.
I'd say the ratio of XMonad users who would build a easy-config system to total XMonad users is small. You're trying to claim that total XMonad users = X, and since X people are using it without creating the 'new system,' it means that no one sees the utility in it.
But the nice thing about starting with a full language using the normal API is that you can always water it down to get something less powerful and easier to use, and this has been done with Xmonad before, as 'xmonad-light'. See https://braincrater.wordpress.com/2008/08/28/announcing-xmon... http://www.haskell.org/pipermail/xmonad/2008-August/006211.h...
xmonad-light has no users and may be bitrotten by now, which shows how much it appealed to Xmonad users.
You're also dismissing the possibility that is just sucked, and was not an improvement in configuration interface.
There are a lot of common things that people do with XMonad, so I'm sure that a number of them could be consolidated into plugins with simple config options.
In fact, there is a text-based configuration system (implemented on top of the full-language configuration system) that does as you describe in the contrib repo somewhere. You could also easily do e.g. JSON, or YAML or whatever.
And that's possible because we use a full language as the base layer. So "dumber" config systems can be layered on top without changing anything.
Even if I want to use one of those libraries, I still need to create an xmonad.hs file, and import the library. Vs having an xmonad binary that determines libraries/etc from a config file, and all code-level customizations are libraries/modules.
love how a "customizable tiling window manager" somehow
requires the user to learn an unusual programming language
and a dozen of inscrutable keyboard shortcuts.
I'm a technical user. I program for a living. I don't care to learn Haskell in order to use a window manager :P. This is all I'm saying.
You might be interested in the tiling window manager I wrote with Node.js (mixu/nwm on github). It's very much inspired by xmonad and dwm, but the engine is Javascript running in Node.js with a native extension for X11 operations/events.
All layouting decisions are made in JS - in fact, the C++ binding doesn't even know the position of the windows or the dimension of the monitors; it's all tracked in JS. It should be easier to customize, though definitely not as battle-tested as xmonad.