Collaborative Text Editor

[Bengt Richter]

On 14 Jul 2004 23:21:38 +0100, jjl at pobox.com (John J. Lee) wrote:

>Ed Suominen <ed-no at spam-eepatents.com> writes:
>
>> I'm thinking of implementing a real-time collaborative text editor in Python
>> using Twisted.
>
>Cool!  I've wondered about this in the past.  Not sure how useful it
>would turn out to be, but would be fun to find out.
>
>
>> An initial plan is to use a Twisted PB server daemon that
>> accepts user:password:file connections from text editor clients to make
>> changes to a specified file on the server, and have the text editor clients
>> update their local copies of the file based on local user input or input
>> entered from other users, relayed via the server.
>
>I wonder if client-server is the way to go here.  On the surface, P2P
>seems more natural fit.
>
>The way I've always imagined it working is as follows.  I'm sure
>experimentation is the way to find out what works, though, so Twisted
>certainly sounds like a great idea.
>
>- At any time, exactly one person has control.
Why not like a multiplayer game, where everyone sees the same world
(document with signs of other player's activity) and all are able
to play (select text for editing) at the same time (just not on overlapping text).
>
>- The only person able to move the cursor and edit text is the one
>  with control.
Why? Why not have two windows, one with the common world view, where
anyone can select thus-far unselected text -- which on selection changes
appearance and may have hint-info floating to say whose selection is is, etc --
and the other window to edit the selected text, which would only change in
the common view when an editing person did a save. A save-and-release would
make the text selectable by others again.

>
>- Anybody may flag up that they want control.  Everybody is notified
>  when this happens.
See above. They just do a selection, and either succeed or not, according
to first come first served.
>
>- Control passes from one person to another by means of the person
>  with control yielding it to a specified person.
Too bothersome. Also, if someone goes off and forgets to close his session,
there should be a timeout. Perhaps a selection should have a for-how-long entry,
and it should show counting down in the hint.

>
>
>If I were doing this (which I'm not, of course), I would go out of my
>way to meet the following goals:
>
>- Critical: the way should be left open to implementing the protocol
>  on any decent editor.
>
>- Important: the protocol should be efficient, so that latency is
>  minimised.  I imagine this requires pushing changes out rather than
>  polling to check for changes, and having reasonably high-level
>  primitive operations -- maybe insert, cut, paste, move, maybe
>  rectangle-wise cut/paste operations too, maybe indent / dedent, plus
>  operations on a circular clipboard stack (strange image ;-).
>
I'd ask game people how they manage and cache common state.
>
>> Jabber compatibility would be nice, as would color-coding of different
>> users' text, etc.
Not excluded from game-like approach.
>
>Jabber certainly seems an entirely secondary thing: if it helps meet
>your goals, great.  If not, who cares?
Being able to communicate separately with the current editor of any of all the
active areas would seem useful.
>
>I don't see how colour coding would work, other than to have text that
>has been entered since the last switch of control coloured
>differently.
I'd use one slight background color change or such to indicate a text area under edit,
and use hints or right-click popups or such for additional details and comm access.
Selection in structured text such as xml etc might operate with useful constraints,
or optionally as with raw text.
>
>[...]
>> I'd appreciate pointers to any existing, simple Python-based text editors
>> suitable for being adapted to this purpose. "Suitable" means under an
>> OSI-approved license and written cleanly and modularly to facilitate
>> incorporation into another project.
>[...]
>
Since selection and common-state viewing would be in a separate window,
the result of a selection could be getting a temp file locally for editing,
and any editor should be able to handle that.

The save and save-and-release functions might require some specialized macros,
but I'd guess any decent editor could be made to do it. Or maybe wrap editor
execution in a shell that notices file updates and the final editor exit...

>I know vim is Python-scriptable, and has a fairly wide user base
>(especially if you count).
>
>For a number of reasons I've been meaning to learn vi properly for
>ages, but find it very hard to kick my emacs habit...
>
>have-the-appropriate-amount-of-fun-ly y'rs
>
>
>John
Just OTTOMH...

Regards,
Bengt Richter