[xmonad] Config File Format

[Gwern Branwen]

On 2008.05.15 01:52:31 -0700, Devin Mullins <me at twifkak.com> scribbled 2.5K characters:
> On Thu, May 15, 2008 at 01:20:08AM -0400, Gwern Branwen wrote:
> > For example, why do we have all these repeated <:>? If monads are
> > 'programmable semicolons', surely we could get rid of them. :)
> That is an interesting option. (I wasn't being that clever.) However, a
> (non-programmer) beginner probably won't ask "why are there repeated
> semicolons?", but rather tell himself, "oh, I use semicolons to
> configure xmonad". This could, of course, teach a bad habit. :)
>
> > Another thing: when I cast myself into a beginner's mind, I see no
> > reason that modMask and terminal use '<=>', but layout and layoutHook
> > must use '<+>'. All look like they're updating a variable.
> Again, try to imagine you're not a programmer, and hence don't know what
> 'updating a variable' is. :)

Well, I'll be blunt: if a user doesn't even know what updating a variable is, I don't see them ever mastering xmonad to a point they can enjoy using it more than Fluxbox or Metacity or something.

Why? Because a tiling WM, particularly xmonad, is very abstract and complex internally. We've got all kinds of hidden state and stuff going on: You have the ideas of focus follows mouse, you've got the whole window stack thing, you've got the distinction between floating and tiled, you have the invisible layout stuff (when I've closed out all windows on workspaces, what layout is xmonad going to use when two or more windows get opened up? this is hidden state), you have undiscoverable keybindings which need to be memorized (is anyone going to claim that vi-inspired bindings are 'intuitive'?), what workspace am I on now?, heck, what are these invisible workspace thingies, and so on.

You see my point - once you've learned the model, things are great. I wouldn't be using xmonad if I didn't think it suited me. One no longer has to manually manage memory^Wwindows. But xmonad is like a command line shell, I hope I've made clear: I don't see any hope for someone who wants to be as effective in a CLI as in a GUI but won't learn about variable updates. So I think we need to accept that there's always going to be something elitist about using xmonad or haskell, or heck, just being programmers period.

> The distinction I was trying to draw (and perhaps failing at) was that
> <-> removes something <=> sets something, and <+> adds something. Not
> every thing supports every operation. For example, you can add and
> remove keybindings (or set the whole list from scratch), but can only
> add new layout choices, or set the list from scratch (since our types
> won't allow removal).
>
> > So I worry that this approach might lead to too much 'magic' and mysteriousness.
> Fair point.
>
> > The current config file at least is discoverable: once you learn
> > haskell syntax, you can then consult the haddocks and find out
> > everything you need to know, and why everything is the way it is.
> Is learning basic Haskell syntax and semantics too much to ask new
> users? This is a genuine question; I'm not sure what xmonad's "mission
> statement" is, here. :P

See my above point. We (humanity) have been developing programming languages for more than half a century. So far, all the software I've heard of which try to let you do all the arbitrary complex things power users want to do ultimately wind up using a language - with syntax and semantics.

Yes, perhaps we could develop a GUI to write xmonad.hs or even replace it entirely. But will it ever be as powerful or flexible as xmonad.hs? History suggests no, when even bloody music players like Amarok need to add scripting capabilities (Ruby, in Amarok's case).

--
gwern
recondo boobytraps sigvoice UT/RUS nkvd TDYC Smith utopia n WANK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20080519/ed819df0/attachment.bin