On a couple of occasions over the past few days, I’ve had the pleasure of editing code with other #haskellers, using the collaborative text editor gobby. It was quite a lot of fun, and (somewhat surprisingly, to me at least) rather effective. It could stand a good chance of becoming one of my preferred methods for collaborative programming.
Except.
Except that gobby doesn’t support undo! It doesn’t even have a way to go “back in time” to a previous version of a document (unless you have it saved locally, of course). This is, quite plainly, a huge show-stopper, and I don’t say that just in theory: I ran into this issue head-on after only a few hours of use. I wanted to delete a bunch of double quotes, so did a search-and-replace. It was taking too long to click “replace” for each double quote character, so I clicked “replace all”, thinking it would only replace double quotes from the current location to the end of the file. Well, as you can probably guess, it deleted all the double quotes everywhere in the file. Oops. Ten minutes of tracking down missing quotes ensued, and I don’t even want to imagine what it would have been like without the help of the typechecker.
This was ten minutes of wasted time. I should have been able to just hit “undo” and get on with life.
So, why doesn’t gobby have undo? I looked at their bug tracker, and sure enough, this has been a requested feature since 2005. But it’s never been done, since undo in a collaborative-editing context is a hard problem. Apparently someone is sorta-kinda working on an implementation, that works in some cases…
A hard problem, eh? What hard problems need is good theory. Well, gee goshums! If only there was some sort of theory of concurrent editing…
So, the upshot of all of this is that I am seriously considering writing a gobby clone in Haskell with some sweet, sweet patch theory goodness. (Other killer features under possible consideration: hpaste and darcs integration, a Yi frontend, integrated compilation/error annotations, chat support that doesn’t suck…) I do have a lot more thoughts on the particulars of how this might work, but I won’t write more about the specifics here since that’s not really the point of this post.
The point is that although I said “seriously considering”, in actuality I’m not sure exactly how serious I really am. This would be a pretty big project, and I certainly couldn’t get anywhere close to pulling it off myself. I’m not even sure that I understand all of what it would require; I’d be particularly clueless about the networking and UI stuff. I just think that it would be pretty sweet, and a great application of Haskell’s strengths. Mostly at this point I’m looking for feedback. What do you think? Is this an awesome idea? Is it a stupid idea? Most importantly, would you be interested in working on it?
blog :: Brent -> [String] 
This sounds like it could be fun, but wouldn’t adapting the current darcs machinery result in some serious performance concerns?
Unless I’m misunderstanding how granular the “patches” would be for a collaborative text editor, it seems like you’d get a hellalotta patches vary quickly and you’d be likely to run into the bad edgecases for darcs performance.
As I said, though, it sounds like it could be a pretty neat project to work on.
Nice idea, but rather than building something from scratch, perhaps an app could be built on top of darcs, making it realtime(ish)?
It wouldn’t even need to be an editor, it could just be a GUI app that told you (in real time) changes (ie patches) that haven’t been sent to a collab repo, and pending changes to be fetched from there.
(disclaimer: I haven’t used gobby).
It’s a good idea, but collaborative editing is very rare (in my experience). I shelled out for a sub etha edit license (since I liked the program so much) but never got a chance to really use the collaborative editing features much.
I was asking around a few years back about whether Yi could make use of a librarification of darcs for an action graph (undo/redo patches). Everyone seemed to agree it could work.
But it’s hard to be motivated to get support for an idea when not many people seem to use this sort of thing and GNU Emacs provides basic collaborative editing support under the X Window System, using the “make-frame-on-display” command.
Cool project, though.
There’s lots of math behind this stuff for anyone that wants to do it right: One good place to start might be: “Optional Locking Integrated with Operational Transformation in Distributed Real-Time Group Editors” (1999) [http://citeseer.ist.psu.edu/163486.html] I’m sure following citations from there will yield lots of other goodies too.
I think it sounds like a candidate for a collaborative project, using gobby and darcs. Now if only there were a convenient way to take the changes of gobby, and get an event server based on when someone starts/stops editing somewhere…
Well,
This was the idea behind the Splatch project at last year’s hac:
http://code.haskell.org/splatch/
Note that it is not yet completed, but it forms a good basis. We wanted to have undo in a collaborative editor like gobby.
I’ve actually been speculating, for the past week or so on writing a text editor in haskell.
My current wip can be seen at: http://mgsloan.nfshost.com/darcs/haskroom/
Screenshot: http://mgsloan.nfshost.com/haskroom.png
I’ve got quite a few UI ideas, some original, some from various sources. One thing I can say is it would be very very different.. With good design, peripheral UI would be pretty swapable.
So far I’ve just written some very basic buffer / display / edit stuff, most of which I will probably scrap and adopt gtk source view. If I can get it looking the way I want it to.
mgsloan:
Very neat idea. However that means it won’t work with collaborating. Zippers are not combinable. They’re not quite like iterators in that sense in that your data-structure is stored in the zipper, and thus you can’t have two random zippers into the same data-structure.
Some researchers in the ECOO team of the LORIA lab , have been working on collaborative editing for some time. They’ve published some papers on what they call “Operational Transformational” . It’s worth looking at, and if you are feeling courageous, comparing with what darcs does. They’ve actually developed a theory-backed distributed version control system, called so6, which I think is the only other version control system out that is backed by something like a patch theory. In addition to the little known so6, they have also been applying OT to collaborative text editing (I think).
Argh, wordpress ate my URLs:
http://ecoo.loria.fr/
http://en.wikipedia.org/wiki/Operational_transformation
Pingback: Collaborative work with LaTeX « The Lumber Room
Have you seen Palimpsest: A Data Model for Revision Control?
Pingback: Patch theory thoughts, part I « blog :: Brent -> [String]
Pingback: Patch theory, part II: some basics « blog :: Brent -> [String]
Pingback: Patch theory, part II: some basics « blog :: Brent -> [String]
I guess, even in a non-collaborative editor, undo is one of the most difficult features to implement well. It might be simple in theory, but it has to save more state than just the text, it has to consume little memory even when you’re editing a huge file and lots of small editing steps, etc.