[xmonad] xmonad as an outsider

[Daniel Schoepe]

On Thu, 10 Nov 2011 14:12:38 +0000, Weeble <clockworksaint at gmail.com> wrote:
> I think I first installed xmonad via apt-get, and at some point had
> some problem that meant moving to cabal or darcs. That was a bit of a
> pain, especially trying to understand where each of these things had
> put files and knowing whether I'd successfully uninstalled them later.
> What is much more of a pain is months later when I try to change
> something and realise I need to upgrade and then I'm not even sure how
> I installed xmonad in the first place, so I'm not sure what I need to
> do to update it. After an upgrade to a new version of Ubuntu there's
> generally a period of a few weeks before I find the time to figure out
> how to get xmonad up and running again.

Yes, releasing a new version so the need to switch to darcs wouldn't
arise so frequently/quickly would definitely be the right thing to do,
but as you probably read in the other thread, there are a few problems
on the way to making that happen at the moment. :)
 
> Configuring xmonad is generally pretty mystifying. Even though I have
> a basic knowledge of Haskell, it's often very hard to untangle things
> in the config file or in examples. Problems I've had:
> 
> * Strange symbols, like ".|.", "|||", "-->", "=?", "<&&>". These can't
> be Googled for, so it's hard to find out what they do or where they're
> defined. Haskell already has lots of operators that aren't
> particularly familiar to programmers coming from other languages, so
> this just seems to add to the confusion.

Most of those are defined by xmonad, with the exception of ".|." which
is also not built into the language, so this is not a problem (if it's a
problem; see below on how to find information on those operators) with
Haskell, but with possibly defining too many operators. FWIW: In my
opinion, it doesn't take long to get used to them and afterwards the
resulting code is a lot clearer than it would be if "normal" function
names were used for those.

> * Hard to find out where functions are defined. Example configuration
> files generally import all modules into the one big namespace. In
> Python, the equivalent construct, "from foo import *" is generally
> discouraged for this reason, but I don't know what's conventional in
> Haskell. It seems the forms "import Module (x,y,z)" or "import
> qualified Module" would be better for example configuration files, as
> they aid discoverability: then when I see a name used in a
> configuration file I can easily see which module it came from without
> having to grep through source files.

Not a perfect solution, but you can load your xmonad.hs into ghci (:l
xmonad.hs) and run, for example ":i (|||)" or ":i doShift" to find out
where those symbols are defined (and look up their documentation, if the
name sounds cryptic or if it's an operator).

> * Poor layout documentation. One of the things I was most interested
> when I was a new user was in finding out what layouts were available
> and how to compose them. I found the layout documentation to be very
> limited. There's no overview and there are no diagrams, just a great
> big list of layout names, so to find anything you pretty much have to
> try them all one by one. Even worse, some of them require arguments
> that they do not document. E.g.
> http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Dishes.html
> If there is somewhere that shows example screenshots of all these
> layouts, it would be good if it was more prominently linked from the
> docs.

That's a fair point, but the only reply that comes to mind is
"patches/screenshots welcome", since at least screenshots don't require
any knowledge of Haskell. :)

> * Baffling failure messages. If you make a mistake in your xmonad
> configuration, or if you upgrade and the API for something has
> changed, the error messages are generally very hard to understand, and
> it can take quite a deep understanding of Haskell to realise that you
> just missed out an argument or used the wrong operator.

Aside from working on that directly by improving GHC, I don't think
there's a lot that can be done about that in xmonad:

If xmonad used a special configuration language, the error messages
would probably be better, but I think that would mean giving up most of
the flexibility that makes xmonad so nice to use/customize.

Hypothetically, if xmonad used some dynamically typed language like
Python or Lua, it would result in the window manager blowing up at
runtime with error locations that might be far away from the actual
source.

If xmonad used a less "abstract" language (e.g. C) that allowed for more
specific error messages (that is not to say that gcc's error messages
are more understandable than GHC's though), I think the config file
would be a lot more convoluted and a lot less fun to write, at least for
me.

> I think most of these things can be improved, though maybe not the
> error messages. I really love *using* xmonad, and I've not found
> another window manager that I'm nearly as happy with, but the horror
> of *configuring* xmonad wastes a lot of my time and makes me
> disinclined to recommend it to others.

Great to hear that you still like xmonad, despite your "perceived
overexposure" to Haskell. :)

If we finally manage to make a release, setting up xmonad on another
machine should be as simple as copying over your old configuration
file. Normally, config-breaking changes are quite rare.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20111111/b6e90600/attachment.pgp>