[xmonad] Extensible programs & defaults: the Gosling Emacs experience

[Gwern Branwen]

On Thu, Jul 31, 2008 at 12:59 AM, Devin Mullins <me at twifkak.com> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/xmonad/attachments/20090221/4b02f93c/signature.bin