Config File Format
Hi all (long time no see), There's been chatter about a *shudder* GUI configurator, primarily because people are having trouble with xmonad.hs. Observing some of the syntax troubles people are having, I think there are some easy wins we can make with xmonad.hs, before resorting to GUI. Mainly, the problem seems to be with irregularity. Oh, you want to say layoutHook = layoutHook defaultConf ||| simpleTabbed. No, not layoutHook = layoutHook defaultConf ||| smartBorders. No, withUrgencyHook doesn't go inside the record syntax. Yes, a dollar sign goes there; don't ask me why... Back when I existed last fall, sjanssen mentioned FRefs. I think that's a Very Good idea. Imagine, if you will: main = xmonad $ defaultConfig <:> modMask <=> mod4Mask <:> terminal <=> "urxvt" <:> layout <+> simpleTabbed <:> layoutHook <+> smartBorders <:> keys <-> "M-b" <:> global <+> withUrgencyHook dzenUrgencyHook ["-bg", "darkgreen"] How easy would that be to document? "Just add a line saying, <blah> after your 'main =' line." The only remaining oddnesses are: 1. the ordering importance with layout and layoutHook. (If people are willing to reseparate layout and layoutHook, that goes away.) 2. ultra-global functions like dzen and xmobar. Perhaps do something like main = xmonad =<< return defaultConfig -- could sugar this and then <:> ultraGlobal <+> dzen -- needs a better name could spawnPipe. (I'm not sure what to do about the keys/modMask relationship. One answer is to let the user say: <:> keys <-> (modMask, "b") And let keys take care of the magic. This means defining "FRefs" for mod1Mask, controlMask, (.|.), etc. Kinda hackish.) All this by means of saying: I'm thinking of adding this to EZConfig, but if there's stronger interest in this, I won't, and we can make the change to core (to prevent confusion). Perhaps EZConfig is the best way, though. Let it settle in and see whether it's actually useful for newbs. Thoughts? P.S. - I mean, if we're going to get My Mom configuring xmonad, we'll need a GUI. Then again, My Mom will probably never configure anything. Oh yeah, and I still haven't convinced her to switch to a Mac, despite telling her that her computer will stop crashing and slowing to a crawl if she does. XMonad is not for Moms (a certain xkcd series excepted); it's for people who want to learn something about their system (i.e. Arch users :).
On 2008.05.11 12:46:18 -0700, Devin Mullins
Hi all (long time no see),
There's been chatter about a *shudder* GUI configurator, primarily because people are having trouble with xmonad.hs. Observing some of the syntax troubles people are having, I think there are some easy wins we can make with xmonad.hs, before resorting to GUI.
Mainly, the problem seems to be with irregularity. Oh, you want to say layoutHook = layoutHook defaultConf ||| simpleTabbed. No, not layoutHook = layoutHook defaultConf ||| smartBorders. No, withUrgencyHook doesn't go inside the record syntax. Yes, a dollar sign goes there; don't ask me why...
This looks like an interesting approach, and better in some ways (more uniform, less deliberately Haskell stuff). But I think there's some downsides to revamping everything instead of, say, mandating that examples avoid '$'*, making the functions to use more consistent, etc.
Back when I existed last fall, sjanssen mentioned FRefs. I think that's a Very Good idea. Imagine, if you will:
main = xmonad $ defaultConfig <:> modMask <=> mod4Mask <:> terminal <=> "urxvt" <:> layout <+> simpleTabbed <:> layoutHook <+> smartBorders
For example, why do we have all these repeated <:>? If monads are 'programmable semicolons', surely we could get rid of them. :) Another thing: when I cast myself into a beginner's mind, I see no reason that modMask and terminal use '<=>', but layout and layoutHook must use '<+>'. All look like they're updating a variable.
<:> keys <-> "M-b"
This is just mysterious. What is keys doing, why does it want a String with internal keysym formatting, and what's this '<->'? If <=> adds and updates state, does a minus somehow remove or subtract M-b?
<:> global <+> withUrgencyHook dzenUrgencyHook ["-bg", "darkgreen"]
Here again: based on the above, perhaps I could tentatively conclude '<+>' has some special layout meaning, but all of a sudden it's being used with some 'global' variable. Yes, it mentions hooks, like layoutHook, but layout has apparently nothing to do with hooks... So I worry that this approach might lead to too much 'magic' and mysteriousness. The current config file at least is discoverable: once you learn haskell syntax, you can then consult the haddocks and find out everything you need to know, and why everything is the way it is. And if you already know Haskell, then it's just a matter of learning some libraries, something you do all the time. But a list of variable updates, that can be just a mess. It reminds me of my .zsh config files, as much as I try to structure and write it elegantly. * Actually, would anyone lynch me if I did something like go through XMC and remove all the $s from the examples and docs? -- gwern Layer domination missile PFS sweeping Hitwords grove CTP Ingram charges
On 2008 May 15, at 1:20, Gwern Branwen wrote:
main = xmonad $ defaultConfig <:> modMask <=> mod4Mask <:> terminal <=> "urxvt" <:> layout <+> simpleTabbed <:> layoutHook <+> smartBorders
For example, why do we have all these repeated <:>? If monads are 'programmable semicolons', surely we could get rid of them. :)
As discussed on haskell-cafe yesterday, there are limits to how far you can abuse monads (set by the necessity of type agreement). -- 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
On Thu, May 15, 2008 at 01:20:08AM -0400, Gwern Branwen wrote:
For example, why do we have all these repeated <:>? If monads are 'programmable semicolons', surely we could get rid of them. :) That is an interesting option. (I wasn't being that clever.) However, a (non-programmer) beginner probably won't ask "why are there repeated semicolons?", but rather tell himself, "oh, I use semicolons to configure xmonad". This could, of course, teach a bad habit. :)
Another thing: when I cast myself into a beginner's mind, I see no reason that modMask and terminal use '<=>', but layout and layoutHook must use '<+>'. All look like they're updating a variable. Again, try to imagine you're not a programmer, and hence don't know what 'updating a variable' is. :)
The distinction I was trying to draw (and perhaps failing at) was that <-> removes something <=> sets something, and <+> adds something. Not every thing supports every operation. For example, you can add and remove keybindings (or set the whole list from scratch), but can only add new layout choices, or set the list from scratch (since our types won't allow removal).
So I worry that this approach might lead to too much 'magic' and mysteriousness. Fair point.
The current config file at least is discoverable: once you learn haskell syntax, you can then consult the haddocks and find out everything you need to know, and why everything is the way it is. Is learning basic Haskell syntax and semantics too much to ask new users? This is a genuine question; I'm not sure what xmonad's "mission statement" is, here. :P
And if you already know Haskell, then it's just a matter of learning some libraries, something you do all the time. I think if you know Haskell, you'll be okay with the higher-order functions that it employs.
But a list of variable updates, that can be just a mess. But that's what it is now. When we write: layoutHook = smartBorders (layoutHook defaultConfig ||| simpleTabbed) the result is equivalent, just in mixed order (middle-to-right-to-left), whereas main = xmonad =<< do addTo layouts simpleTabbed addTo layoutHooks smartBorders All happens from top-to-bottom order.
* Actually, would anyone lynch me if I did something like go through XMC and remove all the $s from the examples and docs? Hrm... not off-hand, no. I was going to whine re: UrgencyHook docs, but
(There's your monadic syntax. :) then my reasons for the dollar there are more aesthetic than anything. :P Thanks for your thoughts. I will chew. I hope you will, too.
On Thu, May 15, 2008 at 01:52:31AM -0700, Devin Mullins wrote:
main = xmonad =<< do addTo layouts simpleTabbed addTo layoutHooks smartBorders (There's your monadic syntax. :)
Well, for what it's worth, I tried this, but couldn't get past layouts. I'm going back to <:> foo <+> bar syntax*, but for those brave existentialists among you who dare, I've left its remains here, warts and all: http://hpaste.org/7726 Devin * Actually, I'm looking at `& foo <+ bar'.
On 2008.05.15 01:52:31 -0700, Devin Mullins
On Thu, May 15, 2008 at 01:20:08AM -0400, Gwern Branwen wrote:
For example, why do we have all these repeated <:>? If monads are 'programmable semicolons', surely we could get rid of them. :) That is an interesting option. (I wasn't being that clever.) However, a (non-programmer) beginner probably won't ask "why are there repeated semicolons?", but rather tell himself, "oh, I use semicolons to configure xmonad". This could, of course, teach a bad habit. :)
Another thing: when I cast myself into a beginner's mind, I see no reason that modMask and terminal use '<=>', but layout and layoutHook must use '<+>'. All look like they're updating a variable. Again, try to imagine you're not a programmer, and hence don't know what 'updating a variable' is. :)
Well, I'll be blunt: if a user doesn't even know what updating a variable is, I don't see them ever mastering xmonad to a point they can enjoy using it more than Fluxbox or Metacity or something. Why? Because a tiling WM, particularly xmonad, is very abstract and complex internally. We've got all kinds of hidden state and stuff going on: You have the ideas of focus follows mouse, you've got the whole window stack thing, you've got the distinction between floating and tiled, you have the invisible layout stuff (when I've closed out all windows on workspaces, what layout is xmonad going to use when two or more windows get opened up? this is hidden state), you have undiscoverable keybindings which need to be memorized (is anyone going to claim that vi-inspired bindings are 'intuitive'?), what workspace am I on now?, heck, what are these invisible workspace thingies, and so on. You see my point - once you've learned the model, things are great. I wouldn't be using xmonad if I didn't think it suited me. One no longer has to manually manage memory^Wwindows. But xmonad is like a command line shell, I hope I've made clear: I don't see any hope for someone who wants to be as effective in a CLI as in a GUI but won't learn about variable updates. So I think we need to accept that there's always going to be something elitist about using xmonad or haskell, or heck, just being programmers period.
The distinction I was trying to draw (and perhaps failing at) was that <-> removes something <=> sets something, and <+> adds something. Not every thing supports every operation. For example, you can add and remove keybindings (or set the whole list from scratch), but can only add new layout choices, or set the list from scratch (since our types won't allow removal).
So I worry that this approach might lead to too much 'magic' and mysteriousness. Fair point.
The current config file at least is discoverable: once you learn haskell syntax, you can then consult the haddocks and find out everything you need to know, and why everything is the way it is. Is learning basic Haskell syntax and semantics too much to ask new users? This is a genuine question; I'm not sure what xmonad's "mission statement" is, here. :P
See my above point. We (humanity) have been developing programming languages for more than half a century. So far, all the software I've heard of which try to let you do all the arbitrary complex things power users want to do ultimately wind up using a language - with syntax and semantics. Yes, perhaps we could develop a GUI to write xmonad.hs or even replace it entirely. But will it ever be as powerful or flexible as xmonad.hs? History suggests no, when even bloody music players like Amarok need to add scripting capabilities (Ruby, in Amarok's case). -- gwern recondo boobytraps sigvoice UT/RUS nkvd TDYC Smith utopia n WANK
On Thu, May 15, 2008 at 01:20:08AM -0400, Gwern Branwen wrote:
* Actually, would anyone lynch me if I did something like go through XMC and remove all the $s from the examples and docs?
I wouldn't lynch you, but I don't think it's a good idea. When parens replace $s, edits become nonlocal, and I don't think that's an improvement. But I also don't work on (or really use) the docs, so probably my opinion doesn't matter. David
On 2008.05.15 04:15:11 -0700, David Roundy
On Thu, May 15, 2008 at 01:20:08AM -0400, Gwern Branwen wrote:
* Actually, would anyone lynch me if I did something like go through XMC and remove all the $s from the examples and docs?
I wouldn't lynch you, but I don't think it's a good idea. When parens replace $s, edits become nonlocal, and I don't think that's an improvement. But I also don't work on (or really use) the docs, so probably my opinion doesn't matter.
David
Well, the hope was that matters would be clearer if examples looked like "define a 'foo = bar (baz (quux 1))'; just from basic mathematics, people understand this syntax, while "foo = bar $ baz $ quux 1" differs quite a bit - $s are non-standard and quite different in other languages, we've obfuscated the function application, and now we can't paste in the definition of 'foo' somewhere, because other operators might mess things up. eg if a user tries to take 'main = foo >>= xmonad' and pastes in the parenthesized version, 'main = bar (baz (quux 1)) >>= xmonad', I think it would work, but pasting in the dollar version would give you 'main = bar $ baz $ quux 1 >>= xmonad', which gets parsed as something odd, maybe 'main = bar $ baz (quux >>= xmonad)' or something. Which leads to a relatively non-obvious error. -- gwern recondo boobytraps sigvoice UT/RUS nkvd TDYC Smith utopia n WANK
Devin Mullins wrote:
Hi all (long time no see),
There's been chatter about a *shudder* GUI configurator, primarily because people are having trouble with xmonad.hs. Observing some of the syntax troubles people are having, I think there are some easy wins we can make with xmonad.hs, before resorting to GUI.
I have to think a more important goal for a non-xmonad.hs configuration system would be independence of GHC. Simplification is a secondary benefit, more a side effect of removing the unfamiliar syntax.
main = xmonad $ defaultConfig <:> modMask <=> mod4Mask <:> terminal <=> "urxvt" <:> layout <+> simpleTabbed <:> layoutHook <+> smartBorders <:> keys <-> "M-b" <:> global <+> withUrgencyHook dzenUrgencyHook ["-bg", "darkgreen"]
... snip ...
All this by means of saying: I'm thinking of adding this to EZConfig, but if there's stronger interest in this, I won't, and we can make the change to core (to prevent confusion). Perhaps EZConfig is the best way, though. Let it settle in and see whether it's actually useful for newbs. Thoughts?
I started some of this thinking a few months ago by proposing and then setting out to write what has become PlainConfig, a plain-text configuration file for configuring xmonad. It's done for all the core configuration, and could be easily extended to use some common bits of XMC. There's talk of a release in the near future, so it hasn't been pulled into the xmonad codebase yet. But the principal goal is not simplification of configuration so much as removing the GHC dependency. The target users here are people downloading the Debian or Ubuntu packages for xmonad, who'd like to change their mod key to Windows instead of the massively overloaded left alt default. Whoops, they need to install GHC, get the template xmonad.hs, make the change, and get it compiling. If someone just wanted to "try it out", do you think they'd continue? But if the process was "create ~/.xmonad/xmonad.conf, and put the line 'modMask = 4' in it, then press mod+q", that's not a big deal. Simplification comes along with this, at the obvious cost of vastly reduced flexibility and power. That's why none of these alternative configuration ideas can really replace xmonad.hs files. I certainly won't be using PlainConfig myself, I have some complex keybindings I want to continue using. But J. Random Ubuntu User doesn't want to install GHC just so he can use left alt again. On the philosophical front, I think there might be some fundamental differences of viewpoint. I am entirely unwilling to sacrifice the control that xmonad.hs files give me, and I would fight very hard against their removal. But I also think that every new xmonad user is a win, whether they be a master Haskeller like Yitz Gale or some Ubuntu user who hadn't heard of Haskell before reading that xmonad was written in it. The latter doesn't want the power of xmonad.hs files, certainly not right away. He wants a fairly obvious way to change some basics like mod keys, the default terminal, maybe use blue borders or add a keybinding to spawn Firefox. Someday later, he'll want window copying or some other feature, and will come to #xmonad. And we'll say, "oh, you need to get GHC and use this contrib module", the same as we do now. Finally, about a GUI configurator. I must admit I don't like that idea, but I would at least suggest that such a tool be based on PlainConfig or built similarly, to not require GHC. Braden Shepherdson shepheb
Braden Shepherdson wrote:
But the principal goal is not simplification of configuration so much as removing the GHC dependency. The target users here are people downloading the Debian or Ubuntu packages for xmonad, who'd like to change their mod key to Windows instead of the massively overloaded left alt default. Whoops, they need to install GHC, get the template xmonad.hs, make the change, and get it compiling. If someone just wanted to "try it out", do you think they'd continue?
But if the process was "create ~/.xmonad/xmonad.conf, and put the line 'modMask = 4' in it, then press mod+q", that's not a big deal.
I don't see why a ghc dependency is a big deal in environments like debian and ubuntu, other than the fact that they lagged way behind on versions until recently. The overhead of installing ghc in order to edit the config is similar to the overhead of installing, say, python so that you can run a python app. Disk space is cheap and package management is transparent these days. I kind of disapprove of there being more than one type of configuration in the core, as I think it will just make things more confusing for new users (and how do you deal with it if somebody uses both configurations? Debugging new users' problems when they show up on irc is that much harder, and thus discouraging). A very minor gui configurator, on the other hand, could just be a series of simple prompts (what do you want your mod key to be?) that address the things people very commonly change. _____ Justin Bogner
Hi, Am Donnerstag, den 15.05.2008, 22:09 -0600 schrieb Justin Bogner:
Braden Shepherdson wrote: I don't see why a ghc dependency is a big deal in environments like debian and ubuntu, other than the fact that they lagged way behind on versions until recently. The overhead of installing ghc in order to edit the config is similar to the overhead of installing, say, python so that you can run a python app. Disk space is cheap and package management is transparent these days.
It’s not cheap for everyone, ghc6 might be lagging behind on certain architectures and I’m sure that some Debian users would like the possibility of having a simple configuration file
I kind of disapprove of there being more than one type of configuration in the core, as I think it will just make things more confusing for new users (and how do you deal with it if somebody uses both configurations? Debugging new users' problems when they show up on irc is that much harder, and thus discouraging).
It doesn’t have to be in the core. Something I’d welcome would be a module (can be in contrib) that provides a function like: parseSimpleConfig :: (LayoutClass l Window, Read (l Window)) => XConfig l -> IO (XConfig l) which takes some defauls and modifies them according to the users’ configuration (if any). Then the debian maintainer (happens to be me) could compile the system wide /usr/bin/xmonad from this code: import XMonad.Main (xmonad) import XMonad.Something.SimpleConfig (parseSimpleConfig) debianDefaults = XConfig {...} main = parseSimpleConfig debianDefaults >>= xmonad so users without any configuration get the debian Defaults, users with a simple configuration get that (without ghc!), and users who want the full flexibility can use ~/.xmonad/monad.hs as ususal. So with the debian package maintainer had on, I’d welcome such a module, and would probably use it in the Debian package. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de
On Fri, May 16, 2008 at 12:41:06PM +0200, Joachim Breitner wrote:
Am Donnerstag, den 15.05.2008, 22:09 -0600 schrieb Justin Bogner:
Braden Shepherdson wrote: I don't see why a ghc dependency is a big deal in environments like debian and ubuntu, other than the fact that they lagged way behind on versions until recently. The overhead of installing ghc in order to edit the config is similar to the overhead of installing, say, python so that you can run a python app. Disk space is cheap and package management is transparent these days.
It's not cheap for everyone, ghc6 might be lagging behind on certain architectures and I'm sure that some Debian users would like the possibility of having a simple configuration file
Does debian really allow binary haskell packages to be uploaded for architectures where they can't be built using a ghc haskell?! That just seems insane. I agree with Braden that adding yet another config file format won't do our users any good, and that the issue of a ghc install is a red herring. David
Hi, Am Freitag, den 16.05.2008, 04:45 -0700 schrieb David Roundy:
Does debian really allow binary haskell packages to be uploaded for architectures where they can't be built using a ghc haskell?! That just seems insane. I agree with Braden that adding yet another config file format won't do our users any good, and that the issue of a ghc install is a red herring.
No, but there might be delays with a new ghc6 compiler or other corner cases. Maybe very unlikely, but still possible... Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de
First, I believe there's a problem with the quoting in David's post; he appears not to agree with me after all. Hopefully not too much confusion will arise. To elaborate a little further on the idea for PlainConfig. First, it works generally as Joachim described; a minimalist xmonad.hs that can be precompiled, and it reads the config file (~/.xmonad/xmonad.conf in this case) to construct the XConf, rather than using values from xmonad.hs. I see the argument about not fragmenting our configuration into many languages and forms, it would be too confusing. However, PlainConfig and xmonad.hs aren't going to coexist on one user's system at once. The former is extremely simple (key=value file) in form, and corresponds directly to familiar parts of xmonad.hs files. For a user who comes to xmonad, the PlainConfig file is a much lower learning and software dependency curve for him to climb at first. If he later wants more power than PlainConfig can provide, he should be able to use a planned tool for PlainConfig, that would "compile" the plain text xmonad.conf into an equivalent xmonad.hs file. That makes the transition to using an xmonad.hs file smoother, and the software demands are the same as they are now to starting with xmonad. As a practical example, I helped a friend install xmonad last weekend. The process went like this: 1) Install Ubuntu 8.04's GHC 6.8.2 package. 2) Grab the 0.7 source for core and contrib. 3) Grab X11 source and compile that. 4) Try to compile xmonad but it needs mtl. 5) Download and install mtl. 6) Finally compile xmonad. I knew what I was doing and it still took far longer than it should have. Not a good evangelism experience, and I'm fortunate it didn't put him off. (He likes xmonad, but thinks it's responsible for a problem he's having with a couple of apps, I'm looking into it.) In retrospect, the xmonad-0.7 packages from 8.04 might have been a better plan. I'm not sure if they depend on mtl or not, so there still might have been that manual step to get to xmonad.hs compilation. I'm not going to become the next arossato if the consensus goes against using PlainConfig. I think it's a good idea, but I respect the views of the other devs, and if this isn't a direction we want to go in, I won't storm off. I'm just of the opinion that this is a good idea, and I want to see it happen. Braden Shepherdson shepheb
On Fri, May 16, 2008 at 11:57:31AM -0400, Braden Shepherdson wrote:
I'm not going to become the next arossato if the consensus goes against using PlainConfig. I think it's a good idea, but I respect the views of the other devs, and if this isn't a direction we want to go in, I won't storm off. I'm just of the opinion that this is a good idea, and I want to see it happen.
I see no reason why you can't develop in in contrib, now, and move it over when ready and/or agreed upon. Was there push back on that? Similarly, would there be push back if I developed NewConfig (now with monads! thanks gwern) in contrib? Perhaps we need a "selection of the fittest" approach to improving config. (Also, now, I'm just curious.)
me:
On Fri, May 16, 2008 at 11:57:31AM -0400, Braden Shepherdson wrote:
I'm not going to become the next arossato if the consensus goes against using PlainConfig. I think it's a good idea, but I respect the views of the other devs, and if this isn't a direction we want to go in, I won't storm off. I'm just of the opinion that this is a good idea, and I want to see it happen.
I see no reason why you can't develop in in contrib, now, and move it over when ready and/or agreed upon. Was there push back on that?
Similarly, would there be push back if I developed NewConfig (now with monads! thanks gwern) in contrib? Perhaps we need a "selection of the fittest" approach to improving config. (Also, now, I'm just curious.)
Any new config systems in contrib are welcome. The more, the merrier.
Devin Mullins wrote:
On Fri, May 16, 2008 at 11:57:31AM -0400, Braden Shepherdson wrote:
I'm not going to become the next arossato if the consensus goes against using PlainConfig. I think it's a good idea, but I respect the views of the other devs, and if this isn't a direction we want to go in, I won't storm off. I'm just of the opinion that this is a good idea, and I want to see it happen.
I see no reason why you can't develop in in contrib, now, and move it over when ready and/or agreed upon. Was there push back on that?
Similarly, would there be push back if I developed NewConfig (now with monads! thanks gwern) in contrib? Perhaps we need a "selection of the fittest" approach to improving config. (Also, now, I'm just curious.)
They certainly don't hurt as contrib modules. I'll probably convert PlainConfig into such a module. That leaves package maintainers free to use one or the other, though I don't think we really want many different xmonad packages running around. On the other hand, the two don't really solve the same problem. PlainConfig doesn't require GHC, while NewConfig (a more descriptive name might be a good thing?) is an alternative to xmonad.hs files. Braden Shepherdson shepheb
participants (8)
-
Braden Shepherdson -
Brandon S. Allbery KF8NH -
David Roundy -
Devin Mullins -
Don Stewart -
Gwern Branwen -
Joachim Breitner -
Justin Bogner