[xmonad] darcs patch: Config.hs: rm "Toggle the status bar gap...
(and 3 more)
isaacdupree at charter.net
Tue Jan 8 09:00:12 EST 2008
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
> 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
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 -
> - 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
>> 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 :-/
More information about the xmonad