I did that in 2002 or so. Two X servers on different workstations, we started one window on the second X server and I could happily edit the same buffer as my colleague.
I did this back in the late 90s (one xemacs with frames on two displays). I remember there was an issue when someone was in the minibuffer (both people got focus in the minibuffer), but aside from that it worked fine.
I also would leave emacs running at the (school) office, ssh in, and attach a tty to it from home (for reading mail/news).
You can also attach to the same tmux session. I've used that quite a bit during the pandemic for courses and instructions and if you are the person who work in a terminal and can log in to the same system then it's as simple as it could be.
The problem with many of these is the security of them. Giving someone access to an emacs session gives them a full shell running as your account. I used rudel several years ago, which synchronizes changes between server/client emacs sessions, rather than sharing a single emacs session with multiple frames.
We’re out there, in clusters. The agency I most recently contracted through was probably a quarter Emacs users, and entirely the heavy-collaboration/always-pairing sort of developer.
It seems to me that the goal should be not to require the other user to be using Emacs, since the underlying data is text files anyway. The open protocol approach seems most exciting, enabling people to use whatever editor they like best with the same documents simultaneously.
I tried Rudel a little while ago, and I just had some troubles. Probably my fault. I wasn't nearly as well-versed with Emacs back then.
I just tried crdt.el[^1] and holy crap that's cool. I love that it's all built in Emacs, like, there's no special server I have to run to get this to work. I'm blown away.
I use straight.el[^2] and use-package[^3] for package management; if you want to give crdt.el a whirl, just use this:
A fun alternative if you're in the terminal is tmate[^4], which is a fork of tmux. That one uses a central server to negotiate the connection though, I believe.
Yeah I just tried crdt.el and it works great, out of the box. I presume some issues would pop up with more intensive usage. It's a bit odd to host it wherever it is hosted now. Also, if qhong would solve the discovery problem, then this could be The Package for collaborative editing. I can imagine something along the lines of how magic wormhole works, or some publicly hosted DHT.
I set up a special account on my Mac, found one other coworker who's used and likes Emacs (but doesn't main it at work), and did a little experiment involving us both logging into the account and using emacsclient to connect to a running Emacs instance.
It worked rather well. Bit of setup hassle and it's stinking insecure, but not too bad on those fronts even compared to the VSCode solution.
But Emacs lost. All the developer effort is behind VSCode and the IDEs now. So if you want a robust, supported solution for this kind of thing, you have to leave Emacs behind.
I also have been impressed by Live Share with Visual Studio on Windows. Multiple independent (and labeled) cursors is great.
Wanting to get back to emacs, I setup a guest account (on linux) for trusted users and share an emacs editor through a shared tmux session. Only one cursor, but it makes it easier to follow along.
There are collaborative editing options for paper pencil coding too but really you should just bite the bullet and use vscode. Emacs is not a personality trait, might be time to drop it and move on.
27 comments
[ 3.2 ms ] story [ 72.8 ms ] threadI also would leave emacs running at the (school) office, ssh in, and attach a tty to it from home (for reading mail/news).
Fortunately, most Emacs users are likely hermits anyway.
But even if I would find one and we wanted to use emacs together - How is that supposed to work? My config and how I use it is quite personal.
Also I don't understand what it could provide. Screen-sharing can be done with Teamviewer etc.
And not long ago a few student were mind blown because I was, as they put it, "working in the console" :-) The times they are a'changing...
I just tried crdt.el[^1] and holy crap that's cool. I love that it's all built in Emacs, like, there's no special server I have to run to get this to work. I'm blown away.
I use straight.el[^2] and use-package[^3] for package management; if you want to give crdt.el a whirl, just use this:
A fun alternative if you're in the terminal is tmate[^4], which is a fork of tmux. That one uses a central server to negotiate the connection though, I believe.[^1]: https://code.librehq.com/qhong/crdt.el
[^2]: https://github.com/raxod502/straight.el
[^3]: https://github.com/jwiegley/use-package
[^4]: https://tmate.io/
That would make it pretty killer. I'll have to look into that…
We were pairing a lot with a friend in our "startup" that was using Clojure, sometimes from our respective homes.
And well that was it, it was a pretty specialized use case. Sad to see it go but it's a really niche need, sharing a live Emacs buffer.
It worked rather well. Bit of setup hassle and it's stinking insecure, but not too bad on those fronts even compared to the VSCode solution.
But Emacs lost. All the developer effort is behind VSCode and the IDEs now. So if you want a robust, supported solution for this kind of thing, you have to leave Emacs behind.
And yet, Visual Studio is fading away, Eclipse is gone, Netbeans (of "just stop using Emacs for Java" fame ) is on life support.
Emacs is here to stay.
Wanting to get back to emacs, I setup a guest account (on linux) for trusted users and share an emacs editor through a shared tmux session. Only one cursor, but it makes it easier to follow along.