Re: Collaborative editing.

[Tim Cross]

"Perry E. Metzger" <perry@piermont.com> writes:

> Howdy!
>
> For years now, pair programming has been of interest to loads of programmers,
> and I've done quite a bit of it myself. For a long time, I'd do this with 
> Emacs
> by running Screen on a machine and having myself and whoever I was pairing 
> with
> both connect up to the same Emacs (running in a terminal) that way.
>
> However, it's increasingly difficult to get the full benefits of Emacs in
> ordinary terminals; there are too many things a gui can do that a terminal
> can't.
>
> I've also discovered that many other editors (such as VSCode and Atom) seem to
> now have dedicated modes for doing collaborative editing, and apparently do it
> quite well. Indeed, many people I asked directed me to VSCode for this when I
> asked around about methods to do it for Emacs. (SubEthaEdit, which is now free
> software, also allows such things, but it is a much more limited editor.)
>
> Especially with more and more working programmers doing their jobs from home 
> but
> wanting to work with colleagues far away, it would seem like having truly good
> support for collaborative editing baked in to Emacs by some means would be a
> good idea.
>
> I know there have been some experiments with collaborative editing modes in 
> the
> past that were written purely in Elisp but none seem to be currently 
> maintained
> and I'm not sure if any were actually very good to begin with.
>
> Anyone have thoughts on how one could get Emacs to be a really top flight
> collaborative editing environment, especially for programmers? Just to be 
> clear,
> one would want both programmers to be in distant locations, but to get
> essentially the same view of the file being edited, the same view of any UI
> elements like popups, and to be able to control the keyboard and mouse more or
> less simultaneously. Presumably one of the two Emacsen would be the primary 
> one
> and the other one just a remote display, though other architectures are
> possible.
>
> Obvious design alternatives are dealing with some sort of quite literal 
> display
> sharing mechanism in which a VNC-like protocol is used, a slightly more
> "semantically" based display sharing protocol in which a remote display is 
> sent
> a series of high level commands about updates, some sort of more literal
> collaborative editing in which diffs to text get sent back and forth (but this
> would not make it easy for both programmers to see the same view of the text,
> including popups etc.), and there are probably other places in the design 
> space.
>

Just as another data point, I've done this similar to your screen
example (except we used tmux). We also used spacemacs, which has it's
'hybrid' mode, which supports both traditional Emacs key bindings and
Evil, which was handy because the other user was not an Emacs user, but
they were familiar with VI. It worked OK, but was definitely not as
'polished' as VSCode's remote collaboration/editing mode. The VSCode
model does work very nicely.

A remote/pair programming mode for Emacs would be nice. What would be
very nice is if it was possible for Emacs to leverage off the same
protocol as VSCode. It would be very nice if you could pair program with
someone who is using VSCode while you are using Emacs (and vice versa).
One of the limitations with the screen/tmux model is the expectation
both parties are Emacs users. It is rare I find many other Emacs users
on teams I've worked with. In the last few years, VSCode and Atom seem
to be far more common.