darcs patch: Config.hs: rm "Toggle the status bar gap... (and 3 more)

older
Issue 40 in xmonad: Screen focus...

gwern0＠gmail.com

7 Jan 2008 7 Jan '08

11:25 a.m.

Mon Jan 7 11:17:16 EST 2008 gwern0@gmail.com * Config.hs: rm "Toggle the status bar gap" binding Per my discussion with Roundy in the thread '[xmonad] automatically generating template xmonad.hs if it doesn't exist'. Not very useful: " 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.)" Mon Jan 7 11:19:36 EST 2008 gwern0@gmail.com * Config.hs: rm dmenu and gmrun default bindings See previous patch: "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.)" Mon Jan 7 11:21:00 EST 2008 gwern0@gmail.com * Config.hs: rm 'refresh' keybinding See previous patches: "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 for them to add refresh to a hook." Mon Jan 7 11:23:57 EST 2008 gwern0@gmail.com * Config.hs: implement my suggestion to make 'n' bind to next window

Attachments:

config_hs_-rm-_toggle-the-status-bar-gap_-binding.dpatch (text/x-darcs-patch — 7.2 KB)

Show replies by date

Brandon S. Allbery KF8NH

7 Jan 7 Jan

11:35 a.m.

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

...

Mon Jan 7 11:17:16 EST 2008 gwern0@gmail.com * Config.hs: rm "Toggle the status bar gap" binding Per my discussion with Roundy in the thread '[xmonad] automatically generating template xmonad.hs if it doesn't exist'. Not very useful: " 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.)"

If you're using an unmodified xmonad, the status bar gap is (0,0,0,0).

...

Mon Jan 7 11:21:00 EST 2008 gwern0@gmail.com * Config.hs: rm 'refresh' keybinding See previous patches: "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 for them to add refresh to a hook."

My experience with refresh is that it's needed rarely, but when it's needed there's no good way to do it unless the wm supports it. Requiring the user to rebuild xmonad in that case is perhaps less than ideal, especially if the only way they can get to that point is ServerZap because they can't force a refresh. Move it to an out of the way keybinding, perhaps, but removing it is a bad idea. -- 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

Spencer Janssen

12:45 p.m.

New subject: darcs patch: Config.hs: rm "Toggle the status bar gap... (and 3 more)

On Mon, Jan 07, 2008 at 11:25:14AM -0500, gwern0@gmail.com wrote:

...

Mon Jan 7 11:17:16 EST 2008 gwern0@gmail.com * Config.hs: rm "Toggle the status bar gap" binding Per my discussion with Roundy in the thread '[xmonad] automatically generating template xmonad.hs if it doesn't exist'. Not very useful: " 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.)"

It is true that mod-b is a no-op in the default configuration. However, once a user sets some status gaps, they'll immediately want to use this feature. Requiring the user to copy this keybinding makes configuration needlessly difficult.

...

Mon Jan 7 11:19:36 EST 2008 gwern0@gmail.com * Config.hs: rm dmenu and gmrun default bindings See previous patch: "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.)"

The dmenu binding will stay -- users must be able to launch programs out of the box. Perhaps we can remove the gmrun binding, does anyone actually use it?

...

Mon Jan 7 11:21:00 EST 2008 gwern0@gmail.com * Config.hs: rm 'refresh' keybinding See previous patches: "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 for them to add refresh to a hook."

I'm ambivalent on this one. It is rarely needed, but it is important when you do need it.

...

Mon Jan 7 11:23:57 EST 2008 gwern0@gmail.com * Config.hs: implement my suggestion to make 'n' bind to next window

We already have several bindings for this -- it seems counter to your "war on keybindings" to add a third binding to the same action :P Cheers, Spencer Janssen

Don Stewart

1:56 p.m.

sjanssen:

...

On Mon, Jan 07, 2008 at 11:25:14AM -0500, gwern0@gmail.com wrote:

...
Mon Jan 7 11:17:16 EST 2008 gwern0@gmail.com * Config.hs: rm "Toggle the status bar gap" binding Per my discussion with Roundy in the thread '[xmonad] automatically generating template xmonad.hs if it doesn't exist'. Not very useful: " 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.)"

It is true that mod-b is a no-op in the default configuration. However, once a user sets some status gaps, they'll immediately want to use this feature. Requiring the user to copy this keybinding makes configuration needlessly difficult.

+1 from me.

...

...
Mon Jan 7 11:19:36 EST 2008 gwern0@gmail.com * Config.hs: rm dmenu and gmrun default bindings See previous patch: "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.)"

The dmenu binding will stay -- users must be able to launch programs out of the box. Perhaps we can remove the gmrun binding, does anyone actually use it?

I'd be happy to see gmrun gone.

...

...
Mon Jan 7 11:21:00 EST 2008 gwern0@gmail.com * Config.hs: rm 'refresh' keybinding See previous patches: "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 for them to add refresh to a hook."

I'm ambivalent on this one. It is rarely needed, but it is important when you do need it.

...
Mon Jan 7 11:23:57 EST 2008 gwern0@gmail.com * Config.hs: implement my suggestion to make 'n' bind to next window

We already have several bindings for this -- it seems counter to your "war on keybindings" to add a third binding to the same action :P

gwern0＠gmail.com

8:47 p.m.

New subject: darcs patch: Config.hs: rm "Toggle the status bar gap... (and 3 more)

On 2008.01.07 11:45:27 -0600, Spencer Janssen scribbled 2.1K characters:

...

On Mon, Jan 07, 2008 at 11:25:14AM -0500, gwern0@gmail.com wrote:

...
Mon Jan 7 11:17:16 EST 2008 gwern0@gmail.com * Config.hs: rm "Toggle the status bar gap" binding Per my discussion with Roundy in the thread '[xmonad] automatically generating template xmonad.hs if it doesn't exist'. Not very useful: " 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.)"

It is true that mod-b is a no-op in the default configuration. However, once a user sets some status gaps, they'll immediately want to use this feature. Requiring the user to copy this keybinding makes configuration needlessly difficult.

Hm. I'm not sure; a status bar requires a fair bit of configuration already. This seems to be a feature on top of the feature of status bar already - you can happily use a status bar without being able to toggle it (right?), so this is for a subset of a subset of users already...

...

...
Mon Jan 7 11:19:36 EST 2008 gwern0@gmail.com * Config.hs: rm dmenu and gmrun default bindings See previous patch: "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.)"

The dmenu binding will stay -- users must be able to launch programs out of the box. Perhaps we can remove the gmrun binding, does anyone actually use it?

I don't think I've seen anyone use it. There *is* one recent config on the Haskell wiki which uses it - http://haskell.org/haskellwiki/Xmonad/Config_archive/loupgaroublonds_xmonad.... - but I don't know if loupgaroublond actually uses it or whether it was just part of the copy-paste. As for dmenu: there's no more reason to think dmenu is installed than, say, gmrun or XMC's ShellPrompt. This is still an external dependency for what you seem to think is core functionality. Replacing it with some call to ShellPrompt would actually be better because it'd avoid runtime problems (User A hears about XMonad, compiles and installs it, and wonders why she can't launch programs - what's this 'dmenu' thing she sees on the terminal prompt - assuming User A even looks there), and it'd be eating our own dogfood. I don't really see any palatable choices here. Either: we have an external runtime dependency on something we can't assume the user has installed; or, we use ShellPrompt/the Prompt framework in general, and have a compile-time dependency on the previously optional XMC; or, we include bare-bones prompt functionality in the core.

...

...
Mon Jan 7 11:21:00 EST 2008 gwern0@gmail.com * Config.hs: rm 'refresh' keybinding See previous patches: "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 for them to add refresh to a hook."

I'm ambivalent on this one. It is rarely needed, but it is important when you do need it.

...
Mon Jan 7 11:23:57 EST 2008 gwern0@gmail.com * Config.hs: implement my suggestion to make 'n' bind to next window

We already have several bindings for this -- it seems counter to your "war on keybindings" to add a third binding to the same action :P

Cheers, Spencer Janssen

Well, would you like it better if I removed the second binding instead? :) I like Tab personally... (But of course, for me, it isn't a third binding at all, since I already have such an entry in my config.hs.) -- gwern 5926 Belknap VIA rail DSNET3 FSB erco imagery William BOP

Wagner Ferenc

8 Jan 8 Jan

4:25 a.m.

gwern0@gmail.com writes:

...

a status bar requires a fair bit of configuration already [...] - you can happily use a status bar without being able to toggle it (right?), so this is for a subset of a subset of users already...

In my opinion it's pretty much so. I don't remember ever toggling the gap (intentionally). Actually, I even added the shift modifier to the bindig to make it available to Emacs. I'm on a laptop with no windows keys, but those keys are almost impossible to reach when touch-typing on any keyboard, so I let then alone on my desktop setup as well. Xmonad and Emacs can both use Alt without much problem, becase one can use Esc as a substitute in Emacs. Which is good enough for me.

...

...
The dmenu binding will stay -- users must be able to launch programs out of the box. Perhaps we can remove the gmrun binding, does anyone actually use it?

I don't think I've seen anyone use it.

Just to add a data point: I don't use it either.

...

As for dmenu: there's no more reason to think dmenu is installed than, say, gmrun or XMC's ShellPrompt.

Don't forget that most people are supposed to install Xmonad via their distributions' package manager, which does take care for such dependencies, if the respective Xmonad package declares them. Those who compile from source can be expected to read the documentation, which hopefully contains a hint for this.

...

...
...
Mon Jan 7 11:23:57 EST 2008 gwern0@gmail.com * Config.hs: implement my suggestion to make 'n' bind to next window

We already have several bindings for this -- it seems counter to your "war on keybindings" to add a third binding to the same action :P

Well, would you like it better if I removed the second binding instead? :) I like Tab personally...

I think the present double binding is good enough: j/k is convenient and historical, Tab is historical. Wasting one more binding for the same function seems... well, a waste. Even though the corresponding Emacs function is not too useful by default, so I don't feel too strongly on this. :) -- Thanks, Feri.

Isaac Dupree

9 a.m.

New subject: darcs patch: Config.hs: rm "Toggle the status bar gap... (and 3 more)

gwern0@gmail.com wrote:

...

On 2008.01.07 11:45:27 -0600, Spencer Janssen scribbled 2.1K characters:

...
On Mon, Jan 07, 2008 at 11:25:14AM -0500, gwern0@gmail.com wrote:

...
Mon Jan 7 11:17:16 EST 2008 gwern0@gmail.com * Config.hs: rm "Toggle the status bar gap" binding Per my discussion with Roundy in the thread '[xmonad] automatically generating template xmonad.hs if it doesn't exist'. Not very useful: " 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.)" It is true that mod-b is a no-op in the default configuration. However, once a user sets some status gaps, they'll immediately want to use this feature. Requiring the user to copy this keybinding makes configuration needlessly difficult.

Hm. I'm not sure; a status bar requires a fair bit of configuration already. This seems to be a feature on top of the feature of status bar already - you can happily use a status bar without being able to toggle it (right?), so this is for a subset of a subset of users already...

can we provide some easy way to add various/most parts of status-bar functionality when configuring, or is there a good reason it requires a "fair bit of configuration"?

...

...
...
Mon Jan 7 11:19:36 EST 2008 gwern0@gmail.com * Config.hs: rm dmenu and gmrun default bindings See previous patch: "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.)" The dmenu binding will stay -- users must be able to launch programs out of the box. Perhaps we can remove the gmrun binding, does anyone actually use it?

I don't think I've seen anyone use it. There *is* one recent config on the Haskell wiki which uses it -

http://haskell.org/haskellwiki/Xmonad/Config_archive/loupgaroublonds_xmonad....

...

- but I don't know if loupgaroublond actually uses it or whether it was just part of the copy-paste.

I packaged GMRun for GoboLinux because of this -- but I wasn't very impressed with it. Most command-prompts have the issue that if the command produces debugging output, I can't find it anywhere, so I usually use a shell anyway :-/

...

As for dmenu: there's no more reason to think dmenu is installed than, say, gmrun or XMC's ShellPrompt. This is still an external dependency for what you seem to think is core functionality. Replacing it with some call to ShellPrompt would actually be better because it'd avoid runtime problems (User A hears about XMonad, compiles and installs it, and wonders why she can't launch programs - what's this 'dmenu' thing she sees on the terminal prompt - assuming User A even looks there), and it'd be eating our own dogfood.

I don't really see any palatable choices here. Either: we have an external runtime dependency on something we can't assume the user has installed; or, we use ShellPrompt/the Prompt framework in general, and have a compile-time dependency on the previously optional XMC; or, we include bare-bones prompt functionality in the core.

as long as mod-shift-return still means "make an xterm" per default, it is _possible_ to launch programs. Funny that we can rely on xterm existing, but no such "prompt" program is an official part of X. I wonder if xterm can be used somehow as a command prompt. Anyway, now that ~/.xmonad/xmonad.hs is a program, it can run anything it likes, including xmonad-contrib. Perhaps we should make a default config that uses some things from xmonad-contrib (while still keeping xmonad-core usable), and somehow direct users to an install that includes contrib and that xmonad? An xmonadcontrib package could install an "xmonad-contrib" binary that works like the "xmonad" one but with different defaults. It seems the separation between "core" and "contrib" is useful for development even when some things in contrib are as stable as core? maybe?

...

...
...
Mon Jan 7 11:21:00 EST 2008 gwern0@gmail.com * Config.hs: rm 'refresh' keybinding See previous patches: "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 for them to add refresh to a hook." I'm ambivalent on this one. It is rarely needed, but it is important when you do need it.

IMO keep refresh somewhere. (although when it's really needed, how likely are you going to remember what its keybinding is? Does xmonad have some mod-? help binding like `screen` does?)

...

...
...
Mon Jan 7 11:23:57 EST 2008 gwern0@gmail.com * Config.hs: implement my suggestion to make 'n' bind to next window We already have several bindings for this -- it seems counter to your "war on keybindings" to add a third binding to the same action :P

Cheers, Spencer Janssen

Well, would you like it better if I removed the second binding instead? :) I like Tab personally...

mod-Tab is like in MacOSX, which was a familiar key combination, which made it friendlier to me at some point, though I usually use j/k. Here in Gnome (without xmonad), alt-Tab works to cycle forwards, but alt-shift-tab doesn't work to go backwards :-/ -Isaac

gwern0＠gmail.com

1:06 p.m.

New subject: darcs patch: Config.hs: rm "Toggle the status bar gap... (and 3 more)

On 2008.01.08 09:00:12 -0500, Isaac Dupree scribbled 5.6K characters:

...

can we provide some easy way to add various/most parts of status-bar functionality when configuring, or is there a good reason it requires a "fair bit of configuration"?

I think this is worth pursuing. At the very least, *some* options and settings could be factored out. Why not be able to write a config.hs like 'main = xmonad $ dzen $ myConfig'? For that matter, I see no reason we couldn't allow for 'emulations' of other tiling window managers - 'main = xmonad $ ratpoison'... It just needs someone to write it, is all. ...

...

...
As for dmenu: there's no more reason to think dmenu is installed than, say, gmrun or XMC's ShellPrompt. This is still an external dependency for what you seem to think is core functionality. Replacing it with some call to ShellPrompt would actually be better because it'd avoid runtime problems (User A hears about XMonad, compiles and installs it, and wonders why she can't launch programs - what's this 'dmenu' thing she sees on the terminal prompt - assuming User A even looks there), and it'd be eating our own dogfood. I don't really see any palatable choices here. Either: we have an external runtime dependency on something we can't assume the user has installed; or, we use ShellPrompt/the Prompt framework in general, and have a compile-time dependency on the previously optional XMC; or, we include bare-bones prompt functionality in the core.

as long as mod-shift-return still means "make an xterm" per default, it is _possible_ to launch programs. Funny that we can rely on xterm existing, but no such "prompt" program is an official part of X. I wonder if xterm can be used somehow as a command prompt.

To continue to play Devil's advocate: I'm not sure we can rely on that. My system doesn't have xterm installed, for example, and I think other distributions besides Gentoo have unbundled xterm from X.org.

...

Anyway, now that ~/.xmonad/xmonad.hs is a program, it can run anything it likes, including xmonad-contrib. Perhaps we should make a default config that uses some things from xmonad-contrib (while still keeping xmonad-core usable), and somehow direct users to an install that includes contrib and that xmonad? An xmonadcontrib package could install an "xmonad-contrib" binary that works like the "xmonad" one but with different defaults. It seems the separation between "core" and "contrib" is useful for development even when some things in contrib are as stable as core? maybe?

Dunno. I'm not entirely sure how that works. I think it's ~/bin/xmonad which compiles ~/.xmonad/xmonad.hs and compiles in XMC if it's installed and ~/.xmonad/xmonad.hs needs it, so I'm not sure how XMC would compile its own xmonad. -- gwern bullion 8182 PRIME pink Iran Centro sardine CISD Wireless FLAME

6343

Age (days ago)

6344

Last active (days ago)

List overview

Download

7 comments

6 participants

participants (6)

Brandon S. Allbery KF8NH
Don Stewart
gwern0＠gmail.com
Isaac Dupree
Spencer Janssen
Wagner Ferenc