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

[Isaac Dupree]

gwern0 at gmail.com wrote:
> On 2008.01.07 11:45:27 -0600, Spencer Janssen <sjanssen at cse.unl.edu> scribbled 2.1K characters:
>> On Mon, Jan 07, 2008 at 11:25:14AM -0500, gwern0 at gmail.com wrote:
>>> Mon Jan  7 11:17:16 EST 2008  gwern0 at 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 at 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.hs>
 > - 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 at 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 at 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