On Thu, Jul 31, 2008 at 12:59 AM, Devin Mullins
On Wed, Jul 30, 2008 at 11:24:31PM -0400, Gwern Branwen wrote:
So, I happened to be reading a PhD thesis on exokernels, when I came across a reference. <snip>
Thanks for that. Fun read.
"The key principle is that there is *simple syntax for simple operations*. This does not mean that a more complex syntax should not be available for more complex operations, only that the complexity should not be forced on the programmer in a simple context."
Or, in Perl terms, make easy things easy, and hard things possible.
Yes, that's a good analogy. I hope we'll be able to do things in a more principled & cleaner way than Perl seems to do things though!
Certainly, I agree. What customizations do you find common among xmonad.hses (a. applicable to xmonad-core, and b. from xmonad-contrib)?
I've listed a few already, but I'm sure that I've missed many. For example, I'm sure that some modules are always used together and so one should export the other, but I have no way of analyzing this really. I do invite everyone to pitch on this though! This is precisely why I've constantly touted uploading one's config to the wiki, and why I took the time to write an automated downloader of the xmonad configs at http://haskell.org/haskellwiki/Config_archive#Downloading
to a real key, but is it really impossible for us to, say, autodetect whether Win is usable and only fallback to Alt? Or perhaps on running
Hrm, as I entered xmonad-land via Mac, I definitely would want the autodetect to work. I would have been pissed if xmonad started and wouldn't accept any keys. And learning how to change modMask was a nice feet-wet exercise. (Of course, this was back in the days of Config.hs, when it was, well, blatantly obvious.)
It may be a nice exercise, but *so* many people do it! In my config archive (populated by the aforementioned downloader), I can run 'grep -l mod4Mask *|sort|uniq|wc' and do you know how many configs set the mask to mod4Mask? *40*! There are only 51 configs! So 78% of the known configs do this one setting. I think that's a lot. I understand maybe we can't simply switch bindings, but we need to do something about that, I think.
, keys = \c -> myKeys c `M.union` keys defaultConfig c
*gasp* shut your mouth! EZConfig has ears, you know.
Well, the way forward here is to revamp the key binding system entirely. Spencer has an experimental monoid-based branch of xmonad which I tried, at http://code.haskell.org/~sjanssen/xmonad-newconfig , and it's definitely a cleaner way of doing things. I don't know know how mature or ready for inclusion it is, though.
Or if one is setting ManageHooks. Sure, one *could* write
, className =? "Firefox" --> doF (W.shift "web") But wouldn't a helper function be warranted so one could write: , shiftClassToWS "Firefox" "web"
Hrm, I'm not sure I buy that one. You'd have to create n*m functions, rather than n+m. Perhaps alias =? to for, then that reads:
, for className "Firefox" --> doShift "web" or let for a b c = a =? b --> c, so: , for className "Firefox" (doShift "web")
I have 2 thoughts about this one. The first is that n*m isn't too bad - we match on just class and title, right? So that's just *2. My second is that perhaps everyone should be matching on either class or title. So we have 'match a b = className a =? b || title a =? b'. This is probably just as likely to work - I don't think I've ever seen or heard of two apps where A has B's classname, and B A's title - and more likely to just work (without the user having to deal with finicky details of whether it was classname or title). With 'match', we then need just one function - matchToWorkspace - and we cover a large swathe of functionality. (Grepping through, I think we could cover just about all uses with 5 match* functions: one each for 'doF (W.shift', 'doFloat', 'moveTo', 'doIgnore', and 'doCenterFloat')
In short, perhaps a goal for 0.9 could be to make customizing XMonad easier on the xmonad.hs level.
Agreed. Mind you, there have been some fronts on this. One is PlainConfig, which will eventually autotranslate .conf to .hs. I've tried my hand at a couple of ways that didn't require you to mess with the config record directly, i.e.:
main = run $ do addTo manageHook blah addTo keys [blah blah] set modMask blah
(No need for weird defaultConfig { foo = newfoo + foo defaultConfig }. Just say addTo foo newfoo.)
But I was butting heads with the parameterized Config type (and/or the existential Layout type) and gave my mind a rest. Plus, it got lukewarm reception here. Perhaps I'll give it another shot...
I think a second goal would be to change defaults in the XMonad core, and to perhaps add in some extensions by default - but that's an entirely other discussion.
I'm quite happy with xmonad being entirely minimalistic to start with. I would even love to see ManageHooks as a contrib, as I don't use it. :)
On the other hand, I think perhaps a comparable analogy would be vim. On Windows, for us dumb folk, it auto-installs a .vimrc (in the right place, which is a bit of a mystery) that sources mswin.vim among other things, and makes it act fairly civil. (For instance, when you hit Ctrl-C/V, it cut/pastes with the windows clipboard. I didn't have to hunt through the manual for "*.)
Had I started out on a minimalistic vim, (like the default 'compatible' on unices), well, I probably would have stopped fairly soon. Likewise, mutt was fairly painful until I got some reasonable .muttrc settings.
Not sure what the right answer is, though. We've got tons of example configs floating around on the wiki or in XMonad.Config. Should we pick one to auto-install in the user's .xmonad?
Yes, what's the right thing to do here? I'm not really sure. I think we can get a lot of mileage out of just improving the defaults and adding some intelligence (auto-detection of mod4Mask being my favorite example). Random suggestion: work up a list of xmonad 'paradigms', create a xmonad.hs that implements purely that paradigm, and copy them to ~/.xmonad on startup? -- gwern