[Xmonad] dynamic configuration? (e.g. hsplugins)

[Donald Bruce Stewart]

droundy:
> On Wed, May 30, 2007 at 02:27:58PM -0500, Spencer Janssen wrote:
> > David Roundy <droundy at darcs.net> wrote:
> > > I know others here have far more experience in this arena than I do,
> > > but are there any plans to support hsplugins or the ghc api, or just
> > > plain running under ghci, so that a recompile-reinstall cycle won't
> > > be necesary to update one's configuration? I'd assume this'd be in
> > > the works for version 0.7 or so, but thought I might as well ask.
> > 
> > 0.7?  I don't think any of us have planned that far ahead :).
> > 
> > I think the current 'restart' (serialize state, exec, deserialize) is
> > more promising than dynamic code reloading.  We just need to make
> > additional pieces of state serializable (layouts, especially).
> > 
> > You can cut out the reinstall stage by pointing 'restart' straight at
> > your xmonad repo.  You can skip the recompilation step by telling
> > restart to 'runghc my/xmonad/dir/Main.hs'.
> 
> Ah, that's what I haven't tried.  That almost seems to get us there--but
> not really, as you still need one copy of the source code per user, and
> the user interface actually becomes worse than compiling by hand, rather
> than better.
> 
> It leaves us with xmonad having no way to gracefully exit in case of syntax
> error.  I'd prefer if xmonad itself could do the compiling, and in case of
> an error in ~/.xmonad/Config.hs it would fall back on using
> /etc/xmonad/Config.hs (or whatever), and displaying an appropriate error
> message to the user (and if /etc/xmonad/Config.hs fails to compile, it'd
> fall back on /usr/share/xmonad/Config.hs).
> 
> It'd be nice to know that there's a plan (or at least desire) to make
> xmonad useable by folks who aren't willing to compile their own software,
> and who don't think that one copy of each program per user is a good idea.

There's some desire, but it is balanced by the constraint that existing
extensible systems in Haskell aren't really suitable: either too
heavyweight (hs-plugins, ghc-api) or not supporting the language (YHC).

Also, these are all relatively more unstable solutions. If something
changes in this area, we can look again at it.

-- Don