Collaborative Editing Options for Emacs | Hacker News Reader

Collaborative Editing Options for Emacs

emacswiki.org

90 pointspabs327 comments

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:

    (use-package crdt
      :straight (crdt :type git :repo "https://code.librehq.com/qhong/crdt.el"))

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/

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.

> solve the discovery problem

That would make it pretty killer. I'll have to look into that…

I used Rudel some 10 years ago. I was impressed, though I remember having some wonkiness regarding leftover state files, but the memory is hazy.

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.

First time hearing of straight.el (I already use use-package), great find thanks!

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.

I'm emacs for life, but when it is time to collaborate I use VSCode live share. With the emacs keybindings installed it is tolerable.

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.

Neat, thank you for posting. Though the biggest problem for me is not technical, but finding a collaborator who uses Emacs...

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.

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.

Ouch! But true.

Fortunately, most Emacs users are likely hermits anyway.

so true... in 15 years using emacs I never came across another emacs-user in real life.

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.

In about the same time frame, I saw one user in RL, in the train to be exact. And she was not coding, she was like writing some physics paper...

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...

On a tangentially related note, has anyone used the Code With Me plugin for IntelliJ? Is it worth the setup hassle?

I just tried crdt.el today and it worked pretty great. I had to set up port forwarding via a VPS though.

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).

I just run emacs in screen at the office, so I can always ssh into it from home.

Can't you do an emacs server, ssh into the box and have a local emacs attach to it?

You could by jumping through some hoops (you'd need to set up an SSH tunnel). But what's the point?

Oh yeah! Good ol’ M-x make-frame-on-display…

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.

Yes, but then both users would need to be on the same virtual screen.

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.

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.

Oh, I've heard this so many times before! Too slow, to old, too unIDE, too non-javascript, too Lisp, too this, too that.

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.

Reply on news.ycombinator.com