On Mon, Jun 11, 2007 at 10:32:11AM -0500, Spencer Janssen wrote:
Also nice would be the ability to catch exceptions in the X monad (as discussed before). It seems that xlib crashes when I try to find the width of a string. I'd enjoy not having to log in again when this happens.
The ability to catch exceptions would be nice, but it's hard to say how such a facility should work. Do we roll back state on an exception? We have to be careful here because there are certain state components (like mapped, waitingUnmap) that bring dire consequences when lost.
Obviously thought would need to go into it, and we'd only explicitely catch exceptions--particularly when calling user-defined code.
Furthermore, I think that catching errors in layouts is the wrong attitude: we want xmonad to crash in these early development stages to reveal bugs.
I disagree.
For xmonad hackers, I suggest using a wrapper script that restarts xmonad when it returns with a non-zero exit code.
Not a bad idea, but for the moment I suspect that all xmonad users are xmonad hackers. And since the only way to configure xmonad is to hack its code, and there doesn't seem to be any consensus for changing that, I think it's a good idea to make it easier to safely hack xmonad.
In general, stability seems to be the weakest point of xmonad at the moment--contrary to the advertizing.
I disagree with this statement. In general, xmonad's core has been very stable. All the crashes I've seen lately are due to buggy contrib modules.
The problem is that very little of xmonad's code is in its core. The pleasant aspect of xmonad (or rather, what I wished I had with ion3) is the nice interface for extending and customizing it. When that nice interface causes xmonad to crash when you make a mistake, it's not so nice. I end up keeping an ion3 open for editing xmonad, because xmonad is so unstable. -- David Roundy http://www.darcs.net