
gwern0:
David Roundy
writes: On Sun, Apr 15, 2007 at 03:21:26AM -0500, Spencer Janssen wrote:
I'm tabling this one for now, because: - xmonad is in a feature freeze until 0.1 (coming soon) - it warrants a good discussion about the aim of xmonad (features, minimalism, etc).
Agreed. Hopefully we (you?) can come up with a minimal core that is nevertheless sufficiently extensible that a suitable Config.hs file can do anything a reasonable person would want. -- David Roundy
Yes, definitely. I think the best idea would be to have that stable extensible core, and let people swap around variants of Config.hs, perhaps including the better ones in the repository. ie, you could have a Ratpoison-style Config.hs, an Ion style Config.hs, etc. I think the editor yi does something similar with different keymap personalities for the emacsers & vimers among us. The question is, what's left to add? Right now, the biggest lack which I can identify in Xmonad as compared to my old Ratpoison/Stumpwm setup is the lack of any sort of status bar or
Agreed. Our plan for this is to dump the xmonad state to disk, and use an external hacked version of dmenu to display this state, along with other strings from stdin. That way the status bar is entirely optional, and configurable independently.
display area where I can dump the output of 'top -n 1' or 'uptime' an' so on. Input seems handle-able by dmenu (despite a bad habit of changing apostrophes to backticks) and similar programs so output is the problem.
Simiarly, a run program would be welcome.
(Although, I'm not entirely pleased with Config.hs since it keeps changing and inducing conflicts, but I suppose that's what I get for changing a lot of defaults and adding stuff.)
Yes. This is an interesting issue. Not sure what the best approach to solve it is: using cpp or other preprocessing to generate Config.hs doesn't appeal to me. -- Don