[xmonad] automatically generating template xmonad.hs if it doesn't exist

[David Roundy]

On 1/6/08, gwern0 at gmail.com <gwern0 at gmail.com> wrote:
> > I would, however, suggest considering a reduction in the number of
> > default key bindings.  But then again, key bindings do seem to be the
> > one feature of any application that very few users can agree on.
>
> Which ones would you suggest?

Maybe also the incmaster and mod-H mod-L bindings? (Just to pick four
bindings that have no effect on any of my layouts.)  I know noone will
agree with this, though.

> I can think of some possibilities:
>
>     , ((modMask,               xK_p     ), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"") -- %! Launch dmenu
>     , ((modMask .|. shiftMask, xK_p     ), spawn "gmrun") -- %! Launch gmrun
>
> Why should we include bindings by default for these two launchers - off the top of my head, I know of ShellPrompt in XMC, and I'm sure I could find more if I looked (don't the status bars like Dzen or Xmobar incorporate similar functionality?). The selection strikes me as arbitrary and outdated, as well as kind of odd: should the default bindings have such dependencies?

Agreed.  There's no logic that justifies two distinct launchers eating
up key bindings.  And if we had one launcher, it shouldn't be either
of these.  They're not standard applications on any system that I'm
aware of.

>     , ((modMask,               xK_n     ), refresh) -- %! Resize viewed windows to the correct size
>
> This would be more sensible to bind to something like 'next' (which I guess would be focusDown?); you might say it's a duplicate, but there already are 2 bindings to focusDown. And how often does one need to manually refresh? We recommend using a good terminal emulator like urxvt, so that's that, and I can't think of any others that'd benefit. Does anyone actually use this often? Then it might be better to add refresh to a hook.

Yes, this is only useful as a workaround for xmonad bugs, as far as I
can tell.  (e.g. avoidStruts doesn't notice when a strut disappears).
But there are other workarounds (switching layouts and back).

>     -- toggle the status bar gap
>     , ((modMask              , xK_b     ), modifyGap (λi n → let x = (XMonad.defaultGaps conf ++ repeat (0,0,0,0)) !! i in if n == x then (0,\
> 0,0,0) else x)) -- %! Toggle the status bar gap
>
> I'm not too sure about this one. If you're using an uncustomized totally standard XMonad, are you also going to be using a status bar? More to the point, would you be using a statusbar *and* also be wanting to toggle on/off the status bar? (Which is what this does if I understand it.)

Agreed.  I'm voting for removal of the gap, but I'd vote not to rebind
this to an avoidStruts equivalent.

David