Don Stewart wrote:
lanek:
Hi,
Why not to use YAML, YAML Ain't a Markup Language, with XMonad's configuration files? ... Don't faint, there is no need to use full blown YAML.
Functions. You can't encode Haskell functions in YAML.
However, if we ignore arbitrary computable functions, all the value level configuration could be YAML, or JSON, or Read/Show or ...
See xmonad-light for non-function values only.
-- Don
The goals of xmonad-light and of this proposal are subtly different. xmonad-light was not created to prevent users needing to learn Haskell syntax (though it doesn't use it), it was created to remove the GHC dependency for xmonad. If that latter goal could have been achieved without sacrificing Haskell configs, xmonad-light would have used Haskell (see for example the proposal from the ML about an online compilation form as an alternative) xmonad-light includes several data structures mapping names from a user's plaintext config into Haskell functions (which are compiled as part of xmonad-light, and allows a user's config to be built into the data structures expected by xmonad without actually compiling). Now, if non-Haskell configs were really desirable to new users, xmonad-light would be a more popular way to at least get started with xmonad. The reality is that it's pretty easy for a programmer to see examples in contrib docs and assemble their own config in Haskell. #xmonad is there to help, and someone will cheerfully make and explain the edit if you can't get it to work yourself. The real reason why a non-Haskell config is undesirable is that it takes a new user about 90 minutes to want an extension xmonad-light doesn't offer. xmonad-light has, to my knowledge, no users. And that's fine; it exists mainly as a counterargument to the "it requires this massively heavy toolchain" gripe about xmonad. If you like, it should be very easy to write a converter in Perl from YAML to xmonad-light configs, allowing you to configure xmonad in YAML. Braden Shepherdson shepheb