[Xmonad] xmonad is a zipper

[Donald Bruce Stewart]

droundy:
> On Thu, May 17, 2007 at 02:19:03PM +1000, Donald Bruce Stewart wrote:
> > I've written up the idea behind implementing xmonad as a zipper-based
> > data structure which tracks focus for us here,
> > 
> >     http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/17#xmonad_part1b_zipper
> > 
> > For those wondering how the new StackSet data type will work. The plan
> > is to merge in my zipper branch in the next few days.
> 
> I have a few comments.
> 
> First and foremost: it seems that your zipper idea is taking a change in
> the user interface, and expressing it in the data structure.  Wouldn't it
> make more sense to first have the discussion of what user interface is
> desired, and then implement it afterwards? Or did this discussion already
> occur on IRC, and everyone agreed that they didn't like the focus-stack
> behavior?

Right, its an attempt to implement the delete . insert == id model of
focus behaviour, which is the alternative to the focus stack model. I
promised to go off an implement this when we talked about the focus
stack idea, on irc, I think.

So this is a behaviour change from the focus stack code comitted while I
was away. I prefer it, since it is much simpler to understand the focus
movement behaviour, which fits with out goals of full predictability of
each operation.

Surely focus stack handling is an elaboration that could be achieved via
a contrib module?

> Personally, I prefer the idea of a focus stack, but will concur that your
> non-stack approach isn't much worse.  And the data structure is certainly
> beautiful--except that it presumes that there exists a fixed layout based
> on order of windows, which I don't prefer as a UI.  But I understand that
> most of you do.

Or more that it tries to return the same window list as the current
implmentation, while tracking focus in a more obvious manner. A focus
tracking workspace is just the one-hole context of a stack, after all! :-)

> 
> (totally different--related--topic...)
> 
> The dynamical number of workspaces is one of the reasons I like ion3--and
> it's something your current code change would remove from xmonad.  It's not
> advertised, but the number of workspaces is fixed in xmonad only because of
> the default choice of key bindings, and I like that.  I certainly have been
> using a dynamical set of workspaces via emulation (and someone else is
> doing the same, see FindEmptyWorkspace).

Now this is interesting, and I see no obvious reason not to do this.

> And actually, I have just one idea specific to your suggested API:
> 
>     new :: Int -> StackSet a
>     new n | n > 0 = StackSet t [] rs
>         where
>             (t:rs) = [ Workspace i Empty | i <- [0 ..n-1]]
> 
> Why not make this
> 
> empty :: StackSet i a
> insertWorkspace :: StackSet i a -> StackSet i a
> -- insertWorkspace sets the focus on the new workspace, and works like
> -- insert does on windows, obeying the same properties.
> deleteWorkspace :: i -> StackSet i a -> StackSet i a
> 
> This gives us control of workspaces if we choose, and costs you nothing.
> For those of us who like RotView, and FindEmptyWorkspace, we'd get these
> behaviors for free, and those who prefer to have a fixed number of
> (possibly empty) workspaces, they could have that for free also.
> 
> And of course,
> 
> new n = foldr (const insertWorkspace) empty [1..n]
> 
> I'd also vote for removing the tag :: Int from the Workspace.  It only
> costs O(N) to count workspaces to get to the Nth one, and N in general is a
> small number.  And the common operations are all O(1) since they access the
> first workspace.  The behavior wouldn't be affected, except that

Yes, that's true. We could avoid the tag -- its not terribly useful.
Its been pointed out that the 'master' tag is also not required, since
the 'integration' (idea from Conor's zipper paper :-) of the Stack
cursor gives us the list with master at the top anyway.

> insertWorkspace could change the numbering scheme.  But, I don't see that
> as a real problem.  You currently don't have an API for insertWorkspace,
> and I expect that those who use it will easily adapt to the idea that it
> works the same as windows.

Yes, I think we can look at this next.

-- Don