StackSet: non-positive argument to StackSet.new with mroe monitors than workspaces

[GoogleCodeExporter]

At http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706149 this bug was 
reported (Version 0.10):

My xmonad configuration only sets up a single workspace: I create the
rest dynamically as I need them. I use a laptop, and sometimes have an
external monitor. If I have a single workspace when I attach the second
monitor, xmonad fails to start.

A minimal .xmonad.hs that exhibits the problem:

--- 8< ---
import XMonad
import XMonad.Config.Gnome

main :: IO ()
main = do xmonad $ gnomeConfig { workspaces = ["GTD"] } 
--- 8< ---

Procedure for reproducing:

* Use the above .xmonad.hs.
* Log into a GNOME+Xmonad session in wheezy.
* If there are two monitors, xmonad fails to start.
* If there is a single monitor, this works. If I attach a second monitor,
  xmonad does not crash. However, re-starting it (e.g., due to a
  change to .xmonad.hs) doesn't work.

The error message xmonad gives when starting up:

xmonad-x86_64-linux: xmonad: StackSet: non-positive argument to StackSet.new

I am probably unsual in liking to create my workspaces dynamically on
demand. However, it would be good if xmonad would at least start even
if it can't have something on every monitor.

Original issue reported on code.google.com by nome...@gmail.com on 25 Apr 2013 at 2:48

[GoogleCodeExporter]

Here's the relevant code from XMonad.StackSet:

-- | /O(n)/. Create a new stackset, of empty stacks, with given tags,
-- with physical screens whose descriptions are given by 'm'. The
-- number of physical screens (@length 'm'@) should be less than or
-- equal to the number of workspace tags.  The first workspace in the
-- list will be current.
--
-- Xinerama: Virtual workspaces are assigned to physical screens, starting at 0.
--
new :: (Integral s) => l -> [i] -> [sd] -> StackSet i l a s sd
new l wids m | not (null wids) && length m <= length wids && not (null m)
  = StackSet cur visi unseen M.empty
  where (seen,unseen) = L.splitAt (length m) $ map (\i -> Workspace i l Nothing) wids
        (cur:visi)    = [ Screen i s sd |  (i, s, sd) <- zip3 seen [0..] m ]
                -- now zip up visibles with their screen id
new _ _ _ = abort "non-positive argument to StackSet.new"

As you can see the comment even explicitly states the precondition that there 
must be more workspaces than screens.  Unfortunately a fix for this is not 
trivial because of the way we keep track of screens in the StackSet, where each 
screen is actually a wrapper around a visible workspace.  So if we don't have 
enough workspaces we are literally unable to construct the required Screen 
objects.

Perhaps changing the definition of Screen to include a  Maybe Workspace  would 
work, though I am not sure what other changes that would require.

Original comment by byor...@gmail.com on 28 Apr 2013 at 8:07

[GoogleCodeExporter]

Given that we already support dynamic workspaces, maybe the easiest fix is to 
just generate the necessary workspaces on the fly.

Original comment by allber...@gmail.com on 28 Apr 2013 at 3:23

[GoogleCodeExporter]

That would be easiest, perhaps, but I think it kind of misses the point.  For 
one thing, what should those workspaces be called?  And presumably OP does not 
want some auto-generated workspaces hanging around to be cycled through or 
switched to etc., they want just one workspace.  Having fewer workspaces than 
screens seems like a perfectly reasonable edge case to me. 

Original comment by byor...@gmail.com on 29 Apr 2013 at 2:51

[GoogleCodeExporter]

Has there been any progress on this one? I stumbled on this issue when setting 
up dynamic workspaces. XMonad failing to run still while compiling made me 
think that this is not very elegant, and unintuitive towards new users.

Original comment by Sindre.D...@gmail.com on 21 Feb 2015 at 8:46

[GoogleCodeExporter]

Maybe the auto-generated workspaces should be prefixed somehow that when 
creating a new workspace, it first just renames or deletes/creates one of those?

Original comment by MathStuf@gmail.com on 22 Feb 2015 at 4:38