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

newer
Issue 40 in xmonad: Screen focus...

older
Issue 40 in xmonad: Screen focus...

Brent Yorgey

3 Jan 2008 3 Jan '08

5:18 p.m.

Hi all, I was just talking with cce in #xmonad, who suggested that it would be nice if xmonad, when starting up, checked for the presence of xmonad.hs in ~/.xmonad/ and installed the template xmonad.hs if it's not there. Especially for those installing xmonad via a packaged distribution, it may not be immediately obvious how to start configuring xmonad, where to put xmonad.hs, and so on. I thought I'd run this idea by the list to see what people think before I implement it... perhaps there's a good reason it doesn't do this already. -Brent

Attachments:

attachment.html (text/html — 593 bytes)

Show replies by date

Don Stewart

3 Jan 3 Jan

5:19 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

byorgey:

...

Hi all,

I was just talking with cce in #xmonad, who suggested that it would be nice if xmonad, when starting up, checked for the presence of xmonad.hs in ~/.xmonad/ and installed the template xmonad.hs if it's not there. Especially for those installing xmonad via a packaged distribution, it may not be immediately obvious how to start configuring xmonad, where to put xmonad.hs, and so on. I thought I'd run this idea by the list to see what people think before I implement it... perhaps there's a good reason it doesn't do this already.

well, a lot of other apps don't put stub config files in, vim/mutt/ion etc. they instead document what needs to be done. -- Don

David Roundy

6:08 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Thu, Jan 03, 2008 at 02:19:23PM -0800, Don Stewart wrote:

...

byorgey:

...
I was just talking with cce in #xmonad, who suggested that it would be nice if xmonad, when starting up, checked for the presence of xmonad.hs in ~/.xmonad/ and installed the template xmonad.hs if it's not there. Especially for those installing xmonad via a packaged distribution, it may not be immediately obvious how to start configuring xmonad, where to put xmonad.hs, and so on. I thought I'd run this idea by the list to see what people think before I implement it... perhaps there's a good reason it doesn't do this already.

well, a lot of other apps don't put stub config files in, vim/mutt/ion etc. they instead document what needs to be done.

True, but it still sounds like a nice idea to me. It wouldn't hurt to be more friendly than other programs. -- David Roundy Department of Physics Oregon State University

Brandon S. Allbery KF8NH

8:16 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 3, 2008, at 17:19 , Don Stewart wrote:

...

well, a lot of other apps don't put stub config files in, vim/mutt/ion etc. they instead document what needs to be done.

As a counterexample, last I checked Pine did copy in a default config. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Don Stewart

8:19 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

allbery:

...

On Jan 3, 2008, at 17:19 , Don Stewart wrote:

...
well, a lot of other apps don't put stub config files in, vim/mutt/ion etc. they instead document what needs to be done.

As a counterexample, last I checked Pine did copy in a default config.

So I'm open to the idea, but need a good story for how to avoid *requiring* ghc at runtime. At the moment, as soon as you create a config file, xmonad will try to compile it. If you never customise xmonad, then that runtime dependency isn't required. But maybe that doesn't matter? -- Don

Brandon S. Allbery KF8NH

8:30 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 3, 2008, at 20:19 , Don Stewart wrote:

...

allbery:

...
On Jan 3, 2008, at 17:19 , Don Stewart wrote:

...
well, a lot of other apps don't put stub config files in, vim/ mutt/ion etc. they instead document what needs to be done.

As a counterexample, last I checked Pine did copy in a default config.

So I'm open to the idea, but need a good story for how to avoid *requiring* ghc at runtime. At the moment, as soon as you create a config file, xmonad will try to compile it.

If you never customise xmonad, then that runtime dependency isn't required. But maybe that doesn't matter?

I am inclined to think that, unless we provide some common "canned" configurations precompiled (e.g. ManageDocks + EwmhWindows for people who want to use panels) or some way to build such configurations without recompiling, users *will* do runtime configuration that requires ghc. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brent Yorgey

4 Jan 4 Jan

1:12 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 3, 2008 8:19 PM, Don Stewart wrote:

...

allbery:

...
On Jan 3, 2008, at 17:19 , Don Stewart wrote:

...
well, a lot of other apps don't put stub config files in, vim/mutt/ion etc. they instead document what needs to be done.

As a counterexample, last I checked Pine did copy in a default config.

So I'm open to the idea, but need a good story for how to avoid *requiring* ghc at runtime. At the moment, as soon as you create a config file, xmonad will try to compile it.

If you never customise xmonad, then that runtime dependency isn't required. But maybe that doesn't matter?

Well, that's a good point. An idea to get around this easily would be to copy the template to a file called something different (e.g. xmonad.hs.customize-me) with a comment at the top saying to rename it to xmonad.hs. I really can't imagine there will be many (if any) users that use xmonad without customizing it, though (?). -Brent

David Roundy

1:22 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 4, 2008 1:12 PM, Brent Yorgey wrote:

...

...
If you never customise xmonad, then that runtime dependency isn't required. But maybe that doesn't matter?

Well, that's a good point. An idea to get around this easily would be to copy the template to a file called something different (e.g. xmonad.hs.customize-me) with a comment at the top saying to rename it to xmonad.hs . I really can't imagine there will be many (if any) users that use xmonad without customizing it, though (?).

Another possibility would simply be to only compile xmonad.hs if ghc is in the path. So the only runtime overhead of putting that xmonad.hs there (if ghc isn't installed) would be to check the PATH for ghc. Doesn't seem too onerous for those mythical users who are content with xmonad's default configuration. David

Don Stewart

1:23 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

daveroundy:

...

On Jan 4, 2008 1:12 PM, Brent Yorgey wrote:

...
...
If you never customise xmonad, then that runtime dependency isn't required. But maybe that doesn't matter?

Well, that's a good point. An idea to get around this easily would be to copy the template to a file called something different (e.g. xmonad.hs.customize-me) with a comment at the top saying to rename it to xmonad.hs . I really can't imagine there will be many (if any) users that use xmonad without customizing it, though (?).

Another possibility would simply be to only compile xmonad.hs if ghc is in the path. So the only runtime overhead of putting that xmonad.hs there (if ghc isn't installed) would be to check the PATH for ghc. Doesn't seem too onerous for those mythical users who are content with xmonad's default configuration.

Maybe it's also time to look at the default configuration, so that more people are satisfied with it. -- Don

gwern0＠gmail.com

5:18 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On 2008.01.04 10:23:52 -0800, Don Stewart scribbled 1.0K characters:

...

daveroundy:

...
On Jan 4, 2008 1:12 PM, Brent Yorgey wrote:

...
...
If you never customise xmonad, then that runtime dependency isn't required. But maybe that doesn't matter?

Well, that's a good point. An idea to get around this easily would be to copy the template to a file called something different (e.g. xmonad.hs.customize-me) with a comment at the top saying to rename it to xmonad.hs . I really can't imagine there will be many (if any) users that use xmonad without customizing it, though (?).

Another possibility would simply be to only compile xmonad.hs if ghc is in the path. So the only runtime overhead of putting that xmonad.hs there (if ghc isn't installed) would be to check the PATH for ghc. Doesn't seem too onerous for those mythical users who are content with xmonad's default configuration.

Maybe it's also time to look at the default configuration, so that more people are satisfied with it.

-- Don

Well, we could revisit some old decisions. # Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask. # Maybe change the default border colors. Looking through the configs, I don't see much consistency though. # Random note on configs: they seem to either be long or short, with all the long ones doing complex stuff with Dzen; I don't use Dzen and don't entirely understand what they are doing, but it looks pretty repetitious. This seems like a fruitful area to examine for abstracting and factoring out stuff. Similar comments apply with Xmobar, although the situation doesn't seem as bad there. # Add some more convenience functions for manipulating keymaps. Look at Rossato's config in XMC - you see line after line of stuff like

...

, ((modMask x , xK_F6 ), windowPromptBring defaultXPConfig )

Bleh. -- gwern 777 bce data-haven NSV 2600 NAWAS devices nowhere the Bess

Thomas Adam

5:24 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

Hello -- On 04/01/2008, gwern0@gmail.com wrote:

...

# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask.

I'd argue yes, seeing as the Windows key is not a ubiquitous key on all keyboards. Leaving it as Alt, whilst potentially annoying for some users, is tough, IMO. :)

...

# Maybe change the default border colors. Looking through the configs, I don't see much consistency though.

Maybe, but that's horses for courses, since no two colours are ever going to please everyone; it distills down to having to choose two colours as the default, chosen by the person who wrote the template at the time.

...

# Random note on configs: they seem to either be long or short, with all the long ones doing complex stuff with Dzen; I don't use Dzen and don't entirely understand what they are doing, but it looks pretty repetitious. This seems like a fruitful area to examine for abstracting and factoring out stuff. Similar comments apply with Xmobar, although the situation doesn't seem as bad there.

The Dzen configs from within XMonad have gotten *much* easier with the 0.5 release. -- Thomas Adam

Joachim Breitner

5 Jan 5 Jan

6:05 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

Hi, Am Freitag, den 04.01.2008, 22:24 +0000 schrieb Thomas Adam:

...

Hello --

On 04/01/2008, gwern0@gmail.com wrote:

...
# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask.

I'd argue yes, seeing as the Windows key is not a ubiquitous key on all keyboards. Leaving it as Alt, whilst potentially annoying for some users, is tough, IMO. :)

We could be more bold, without overriding existing key combinations, and remap the CapsLock key (which most people don’t use) to a modifier key and use that per default. It’s what I’m doing :-) PRO: * Does not conflict with other Ctrl or Alt bindings. * Quite a handy spot on the keyboard. * Most people don’t use the CapsLock. CON: * Some already remap that key (but they are power users that most likely modify their xmonad config anyways) * Some might actually want to USE THE CAPSLOCK KEY :-) * It might be a bit less intuitive than the Alt key. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

Isaac Dupree

6:37 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

Joachim Breitner wrote:

...

Hi,

Am Freitag, den 04.01.2008, 22:24 +0000 schrieb Thomas Adam:

...
Hello --

On 04/01/2008, gwern0@gmail.com wrote:

...
# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask. I'd argue yes, seeing as the Windows key is not a ubiquitous key on all keyboards. Leaving it as Alt, whilst potentially annoying for some users, is tough, IMO. :)

We could be more bold, without overriding existing key combinations, and remap the CapsLock key (which most people don’t use) to a modifier key and use that per default. It’s what I’m doing :-)

PRO: * Does not conflict with other Ctrl or Alt bindings. * Quite a handy spot on the keyboard. * Most people don’t use the CapsLock.

CON: * Some already remap that key (but they are power users that most likely modify their xmonad config anyways) * Some might actually want to USE THE CAPSLOCK KEY :-) * It might be a bit less intuitive than the Alt key.

FWIW, I disable CapsLock without using it for anything because if I did use it for anything, it would be accidental half the time (I've tried it.). The one time this bit me was when somehow CapsLock mode turned on by itself, and I had no way to turn it off! Also CON: it could confuse anyone who even understood the key ever, but PRO: it could help teach people how to disable the annoying CapsLock. Do we have to remap only one key? What if we allow Windows _and_ Alt keys to trigger our keybindings by default, as if there was no difference between the keys, to xmonad? ~Isaac

John Chu

8:27 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

...

Also CON: it could confuse anyone who even understood the key ever, but PRO: it could help teach people how to disable the annoying CapsLock.

The current Apple keyboard (i.e., the aluminum one) doesn't send a key down event to the computer on a tap to turn on caps lock. You have to press and hold. It does send a key down event on a tap to turn off caps lock. That is, it's biassed against turning on caps lock, and towards turning it off. I think this is a terrific feature. I hope it catches on. Its antecedents are manual and electric typewriters where caps lock had precisely the same behavior (albeit implemented mechanically). However, this makes the caps lock key a bad choice to map to a modifier on an Apple keyboard. Half the time, the keyboard won't send a key down for caps lock and you won't get the modified key. (Yes, the hardware itself does this.) Making this the default, besides being unintuitive, will seriously annoy anyone using the current Apple keyboard.

...

Do we have to remap only one key? What if we allow Windows _and_ Alt keys to trigger our keybindings by default, as if there was no difference between the keys, to xmonad?

This doesn't solve the problem being posed. People change the modifier to the Windows key because they don't want the xmonad to use Alt key combination. (e.g., I use the Windows key for xmonad because I use the Alt key for emacs.) john

Brandon S. Allbery KF8NH

11:34 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 5, 2008, at 6:05 , Joachim Breitner wrote:

...

We could be more bold, without overriding existing key combinations, and remap the CapsLock key (which most people don’t use) to a modifier key and use that per default. It’s what I’m doing :-)

If you remap CapsLock away in OSX (as I do) then it also doesn't work (doesn't generate events at all) in X11.app. (It might be possible to change this by telling X11.app not to sync keymaps, but judging by the odd interactions I've seen in mouse event mapping I suspect this would cause even more "interesting" behaviors. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

gwern0＠gmail.com

6 Jan 6 Jan

9:27 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On 2008.01.05 12:05:18 +0100, Joachim Breitner scribbled 2.1K characters:

...

Hi,

Am Freitag, den 04.01.2008, 22:24 +0000 schrieb Thomas Adam:

...
Hello --

On 04/01/2008, gwern0@gmail.com wrote:

...
# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask.

I'd argue yes, seeing as the Windows key is not a ubiquitous key on all keyboards. Leaving it as Alt, whilst potentially annoying for some users, is tough, IMO. :)

We could be more bold, without overriding existing key combinations, and remap the CapsLock key (which most people don’t use) to a modifier key and use that per default. It’s what I’m doing :-)

PRO: * Does not conflict with other Ctrl or Alt bindings. * Quite a handy spot on the keyboard. * Most people don’t use the CapsLock.

CON: * Some already remap that key (but they are power users that most likely modify their xmonad config anyways) * Some might actually want to USE THE CAPSLOCK KEY :-) * It might be a bit less intuitive than the Alt key.

Greetings, Joachim

As much as I hate to rain on this suggestion (since I was the one who said, 'Hey! Let's steal the Win-key! What could go wrong?'), I don't think this would really work. I dunno about your pros and cons, but this strikes me as a difficult task. I've ported my configuration files among several computers/OSs by this point, and as many keyboards - and in general, figuring out what is the capslock keyboard and then using it seems to be pretty hard. I eventually gave up on using .xmodmap and began configuring the Caps-as-Ctrl through the installation process. It certainly would be neat if we could somehow build in a facility to try to steal Win if it existed, Caps if it existed, and then fall back to Alt... but I don't know of anyway to build that into the core in any easy way (although I haven't looked too hard through the X11 library, so feel free to correct me). -- gwern GSM Submarine E. 510 ddnp building y friends RDI JCET

David Roundy

4 Jan 4 Jan

6:39 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 4, 2008 5:18 PM, wrote:

...

# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask.

As pointed out, it really does. Most users will be disappointed when they find that they are unable to exit a new window manager without either killing it externally or killing X windows itself. 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. David

Don Stewart

6:55 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

daveroundy:

...

On Jan 4, 2008 5:18 PM, wrote:

...
# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask.

As pointed out, it really does. Most users will be disappointed when they find that they are unable to exit a new window manager without either killing it externally or killing X windows itself.

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.

We have to also remember that the core system is supposed to be usable (i.e. it should be pretty much what Spencer and I use daily). This is currently the case for me, at least. Of course, I'm also happy to garbage collect stuff that hasn't turned out to be useful, and move things in that are needed. -- Don

gwern0＠gmail.com

6 Jan 6 Jan

9:18 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On 2008.01.04 18:39:22 -0500, David Roundy scribbled 0.7K characters:

...

On Jan 4, 2008 5:18 PM, wrote:

...
# Does it *have* to be mod1Mask? It makes more sense to steal Alt than Ctrl, I'll grant, but stealing the useless Windows is even better since even fewer apps use that; I notice that there are at least 4 or 5 configs on the wiki which change mod1Mask to mod4Mask.

As pointed out, it really does. Most users will be disappointed when they find that they are unable to exit a new window manager without either killing it externally or killing X windows itself.

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.

David

Which ones would you suggest? 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? , ((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. -- 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.) -- gwern GSM Submarine E. 510 ddnp building y friends RDI JCET

David Roundy

7 Jan 7 Jan

10:17 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On 1/6/08, gwern0@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

gwern0＠gmail.com

11:24 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On 2008.01.07 07:17:16 -0800, David Roundy scribbled 2.6K characters:

...

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

OK then, I'll send up a few patches implementing these suggestions. They should follow on the heels of this email. -- gwern GSM Submarine E. 510 ddnp building y friends RDI JCET

Brandon S. Allbery KF8NH

11:38 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Jan 7, 2008, at 11:24 , gwern0@gmail.com wrote:

...

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

And X server bugs and network glitches (anyone else remember that X11 is a *network* windowing environment?) and the occasional odd client bug. And switching layouts has the wonderful side effect of causing my xemacs to get into an argument with xmonad requiring me to kill one or the other. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

John S. Yates, Jr.

4 Jan 4 Jan

10:01 p.m.

On Fri, 4 Jan 2008 10:23:52 -0800, Don Stewart wrote:

...

Maybe it's also time to look at the default configuration, so that more people are satisfied with it.

Converging on a single widely acceptable / popular default configuration may prove a quixotic goal. Perhaps, on detecting an absence of xmonad.hs, run an interactive configuration script. Mod1Mask vs Mod4Mask? Gnome integration? What have you... I think that this could provide a much happier OOTB experience. /john

Joachim Breitner

1:22 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

Hi, Am Freitag, den 04.01.2008, 13:12 -0500 schrieb Brent Yorgey:

...

Well, that's a good point. An idea to get around this easily would be to copy the template to a file called something different (e.g. xmonad.hs.customize-me) with a comment at the top saying to rename it to xmonad.hs . I really can't imagine there will be many (if any) users that use xmonad without customizing it, though (?).

Well, the debian packages are laid out so that it’d be possible to generate a custom xmonad binary package and only install that − for example if you run xmonad on several machines, and only want ghc on one of them. So there are corner cases where it might be useful. The idea with the suffix is nice. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

Spencer Janssen

3:25 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Thu, Jan 03, 2008 at 05:18:06PM -0500, Brent Yorgey wrote:

...

Hi all,

I was just talking with cce in #xmonad, who suggested that it would be nice if xmonad, when starting up, checked for the presence of xmonad.hs in ~/.xmonad/ and installed the template xmonad.hs if it's not there. Especially for those installing xmonad via a packaged distribution, it may not be immediately obvious how to start configuring xmonad, where to put xmonad.hs, and so on. I thought I'd run this idea by the list to see what people think before I implement it... perhaps there's a good reason it doesn't do this already.

-Brent

We ought to look at precedent from most other Unix tools -- they don't install stub configuration files and I think there are good reasons behind that. Consider a user that tries xmonad, but then decides in the end that it isn't for them. We shouldn't leave ~/.xmonad cruft (probably including a 3MB cached binary!) behind. Rather than install boilerplate configuration files in every user's home directory, we should use our prominent documentation locations (the manpage and xmonad.org) to point to an example config. Cheers, Spencer Janssen

Isaac Dupree

3:59 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

Spencer Janssen wrote:

...

We ought to look at precedent from most other Unix tools -- they don't install stub configuration files and I think there are good reasons behind that. Consider a user that tries xmonad, but then decides in the end that it isn't for them. We shouldn't leave ~/.xmonad cruft (probably including a 3MB cached binary!) behind.

Unfortunately, precedent states that lots of ~/.* cruft _is_ left around by many applications; for example, shells leave history-files, and preferences / automatic memories are automatically stored there, and there's not much to do about it (other than avoid the big 3MB cached binaries where possible :-) ... As a user I prefer having the stub config file put there, in general, because it makes me feel more likely that I've actually got the right file that's going to be read by the program, and a basic idea of its syntax. (But then if the app is upgraded, an old stub config file will be left there! Oh Nosies!) ~Isaac

Spencer Janssen

10:30 p.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

On Fri, Jan 04, 2008 at 03:59:48PM -0500, Isaac Dupree wrote:

...

Spencer Janssen wrote:

...
We ought to look at precedent from most other Unix tools -- they don't install stub configuration files and I think there are good reasons behind that. Consider a user that tries xmonad, but then decides in the end that it isn't for them. We shouldn't leave ~/.xmonad cruft (probably including a 3MB cached binary!) behind.

Unfortunately, precedent states that lots of ~/.* cruft _is_ left around by many applications;

I mean that we shouldn't create these files if we aren't using them.

...

As a user I prefer having the stub config file put there, in general, because it makes me feel more likely that I've actually got the right file that's going to be read by the program, and a basic idea of its syntax.

I must say I don't understand this. Do we expect that the user will immediately hunt for a file ~/.xmonad/xmonad.hs? Surely they'll seek the documentation first, in which case we can provide solid information on which file to edit and how it should look.

...

(But then if the app is upgraded, an old stub config file will be left there! Oh Nosies!)

Oh, this is an interesting point I hadn't considered. If the stub file isn't compatible with a later version of xmonad (highly likely), the user will receive error messages about a file they've never edited! Cheers, Spencer Janssen

Isaac Dupree

5 Jan 5 Jan

6:30 a.m.

New subject: automatically generating template xmonad.hs if it doesn't exist

Spencer Janssen wrote:

...

...
As a user I prefer having the stub config file put there, in general, because it makes me feel more likely that I've actually got the right file that's going to be read by the program, and a basic idea of its syntax.

I must say I don't understand this. Do we expect that the user will immediately hunt for a file ~/.xmonad/xmonad.hs? Surely they'll seek the documentation first, in which case we can provide solid information on which file to edit and how it should look.

you sound entirely right; how do I understand it myself? - copying from the documentation to a new file is more complicated mentally than finding it already there (especially when there isn't an obvious complete chunk of text to copy, or file to download) - there is no immediate feedback about whether putting the file there had any effect (maybe the documentation was out of date or for a development version? maybe I typo'ed? maybe my configuration had a syntax error, or silently did nothing for an entirely idiosyncratic reason (like ~/.config/fish/config.fish not propagating the effects of `cd` commands to the resulting shell, even though propagating anything else works, and even the `cd` there works in other shells. Luckily it was a shell so trying "echo" worked to make sure the config was being read in mostly the way I expected.) - basically it's just because I'm unfamiliar every time with the whole configuration system, so every little thing is another thing that could go wrong.

...

I mean that we shouldn't create these files if we aren't using them.

Especially don't create ~/.xmonad/xmonad.hs if you're going to ignore changes to it as long as no GHC is present, because then I could be very confused! Xmonad's log messages may be particularly hard to find since they tend to be mixed in with X's startup log messages. A name like ~/.xmonad/xmonad.hs.example, with appropriate comments inside (THIS IS AN EXAMPLE FILE, REAL CONFIG GOES IN <path>, BUT YOU NEED GHC INSTALLED FIRST OR CONFIGURATION WON'T WORK), would probably be quite clear. Less obvious but less wasteful of space would be to install xmonad.hs.example in some system directory like /usr/share, and it could be clear to the user (if the corresponding xmonad-version is mentioned anywhere, in the file-path and/or comments) that it really corresponds to the currently installed version of xmonad. ~Isaac

6344

Age (days ago)

6348

Last active (days ago)

List overview

Download

27 comments

12 participants

participants (12)

Brandon S. Allbery KF8NH
Brent Yorgey
David Roundy
David Roundy
Don Stewart
gwern0＠gmail.com
Isaac Dupree
Joachim Breitner
John Chu
John S. Yates, Jr.
Spencer Janssen
Thomas Adam