1. That hasn't been true for quite some time. 2. Awesome's never crashed on me. Sure, that's anecdotal evidence but so is "awesome always crashed for me". 3. Ha. Haha. Hahaha. Seriously, the xmonad configuration format made me want to cry. I really wanted to give xmonad a try but there's too much fiddling around just to get a useful set up, at least for me. No, the format is not "more readable" because of Haskell, it's because the author is used to Haskell. 4. With this logic any C program should use C as it's configuration language. Awesome's lua config does everything I need it to and along with the sane defaults I feel no need to construct elaborate hacks. Maybe I'm just more interested in doing other stuff rather than fiddling with my window manager. I see this as a strength for awesome. Less need for hacks, more time to do what I really want.
Cheers, On Sat, Oct 1, 2011 at 2:15 PM, Teika Kazura <[email protected]> wrote: > Hi. A comment critical on Awesome appeared in xmonad mailing > list[1]. I also often came across these points browsing web. Some may > be outdated, as he says, and for Awesome's sake, it's worth > correcting, if possible. (And add them to the FAQ.) So please advocate > Awesome. (I'm not an Awesome user.) > > [1]http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/11551 > > On Tue, 27 Sep 2011 17:40:15 -0300, Norbert Zeh wrote: >> I came to xmonad via awesome. Here are my reasons for the switch, >> in no particular order. >> >> 1) [...] The awesome config file syntax is a moving target, changing with >> pretty >> much every major release. This may have changed in the recent past. >> 2) xmonad never once crashed on me, while awesome segfaulted at some very >> inopportune moments while I used it. Again, stability may have improved >> in recent releases, [...] >> >> 3) I always considered xmonad's configuration files much more readable than >> an >> awesome configuration file doing the same thing. I guess that's a >> result of >> the greater expressive power of Haskell vs lua and, probably even more >> so, a >> result of the well thought-out interface provided by the base xmonad >> library. >> >> 4) Using the same language for implementing xmonad and for configuring it >> blurs the line between configuring things and implementing new features. >> In >> this instance, this is a good thing because it makes it much easier to >> add >> non-standard features and tinker with ideas that over time may grow into >> new >> add-on modules in XMonadContrib. When I used awesome, I tried to apply >> the >> kind of heavy customization I apply to xmonad nowadays and I almost >> always >> found myself either hacking C or writing really clunky and round-about >> lua >> code. Of course one may argue that, since xmonad is implemented in >> Haskell, >> writing non-trivial Haskell code in my configuration file is the same as >> adding >> to the C code base of awesome, but it's not because Haskell allows me to >> express myself at a much higher level of abstraction. >> > > Let me deepen this point a bit. I'm a user of Sawfish and Emacs, and > I understand what he says about Xmonad. But a good structure to harness > your own hack and upstream codes is lacking. (For example, I override > /usr/share/emacs/.../paren.el with my own code. But upgrading Emacs > is a bit of headache.) I think there should be "something" in this point. > >> 5) The power of a DIY windowmanager such as xmonad or awesome depends >> heavily >> on the quality of the documentation. In the case of xmonad, I find the >> base >> xmonad library and the vast majority of the modules in XMonadContrib to >> be >> extremely well documented and as a result easy to use. In contrast, I >> find >> awesome's documentation nearly useless. The wiki provides documentation >> by >> example without a comprehensive list of objects/functions that are >> available. >> The API documentation just strikes me as extremely terse and possibly >> incomplete. > > This person also says there's pros of Awesome over Xmonad, but I omit > them. See the reference URL above. > > With best regards. > Teika (Teika kazura) > > > > -- > To unsubscribe, send mail to [email protected]. > -- To unsubscribe, send mail to [email protected].
