Sublime Forum

Remote Collaboration inbuilt?

#1

With VSCode having Live Share and Atom having Teletype; I think sublime needs a remote collab plugin as well; since the best plugin so far (https://floobits.com) is not working well anymore for everyone and the last commit was over 4 years ago (except for an SSL cert update recently, triggered by me).
Floobits had it’s own set of problems: you can’t edit in the same/immediate close lines as the other person else it just f’s it up completely and inserts random characters. and had some performance problems.
Otherwise, the latency was good and the servers were figured out pretty well. (it followed a server to peer system; all files were stored on a server(“workspace”) and we join that workspace to edit.

An inbuilt feature in st for pair programming/remote collaboration will be very handy for a lot of people and especially teams that work in a distributed setting.

3 Likes

#2

Either that or an additional official package or extra tool by ST, to avoid bloating the base app for those who might no wish to have/use this feature. If real-time collaborative editing was made available via an officially maintained package, it would be as if it was part of ST since users would have the guarantee that the package will always be updated along with ST.

I agree with you, this is a superb feature that would greatly increase the value of ST. I had experimented with it in the past using a free editor which I came across, but it was more on the experimental side of things than a full blown editor, so it lacked many desirable features for production work.

I’m confident that is ST developers were to take on working on this feature they would turn it into something amazing and reliable.

1 Like

#3

I strongly believe this should be a 3rd party package and not something official. It’s just an extra overhead now for the developers, who somehow have to now dedicate their already limited time on another package besides ST and SM.

I think the best way forward is for ST to provide the necessary API’s to make building such a package easier. That’s what was done for LSP during the ST4 beta cycle. Instead of having LSP built in, they just provided the necessary API’s to make LSP package function more smoothly in ST4.

2 Likes

#4

I agree with both of these points, they can provide the necessary APIs and open source can develop and maintain the new package. For reference, we have the floobits package; which provides a great starting point for this I guess.

0 Likes

#5

Indeed, LSP is a good comparison example since like collaborative editing it might be a feature determining whether some end users are willing to adopt an editor in their workflow, based on their needs.

Many users who depend on LSP (me included) have migrated to VSCode for all their LSP based work for this reason, since LSP is quite a fast-evolving standard and wish that the editor support for the protocol is always up-to-date with the latest LSP release (which of course in VSCode this is always guaranteed, since LSP and VScode are strongly bound together, being from the same developers). Most official language servers created by the developers of a specific language do provide various clients implementations, including for ST, but they usually recommend switching to VSCode to enjoy the full LSP experience.

Just like LSP, collaborative editing might be a decisive factor for some teams, in which case they’d need guarantees that its support comes from the official developers, rather than from a third party plug-in. Even though Floobits is a commercial product, still being sold, we can see that it hasn’t been updated to work with the latest ST. For a team who relies on an editor for a specific feature, official support can be important, because when the the third party package for that feature stops working it can mean having to switch editor, which is always disruptive in production terms.

Obviously, officially supporting any new feature is going to imply a maintenance burden on ST developers, so it’s up to them to decide whether it’s worth the effort and commitment or not.

1 Like

#6

Related: Im in VSCODE hell at work! lol

2 Likes

#7

My only experience of live-colaboration on the same piece of content is limited to Attlassian Confluence. I feel very uncomfortable to see someone else change content of a document at the same time. Confluence even has a bug which causes my incomplete content to be published as soon as someone else publishes his changes. Not sure how VS Code does hande such things, but I don’t think such kind of stuff is the right way to do remote collaboration in a safe and productive manner! It’s just a toy.

Serious discussions need everybody to review changes make up your mind about it and do some commenting. All of that should be trackable for everyone. Nothing of that can be achieved by hacking the same content at the same time by multiple engineers.

0 Likes

#8

That seems like a workflow problem to me. There’s a lot of value in sitting side-by-side looking at the same code, but you have the restriction that only one person can grab the keyboard. I could imagine that there is a way to achieve that remotely that could also be productive. I’ve never felt the need for this crunching on a problem, but bringing someone new / inexperienced onboard is more common.

Just to be clear though, I personally couldn’t care less about having it built into my editor - share the screen and yield control of the screen when you agree to seems to cover it, and enforces control in a way that seems a lot safer and more controllable

0 Likes