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

[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.

> "The clear lesson to be learned from this is that, while flexibility in such a
> system is indeed essential, great care must be paid to get the default
> behaviours to be simple and natural, and to provide very clear and simple ways
> to use a carefully chosen small set of the most commonly desired
> customizations.

Certainly, I agree. What customizations do you find common among
xmonad.hses (a. applicable to xmonad-core, and b. from xmonad-contrib)?

> 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.)

> >                         , keys = \c -> myKeys c `M.union` keys defaultConfig c

*gasp* shut your mouth! EZConfig has ears, you know.

> 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")

> 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?