floobits is really cool, although I've never really gotten into it myself because the projects I would use it on include some large (10MB+) XML files, where floobits seems to make things slow / sync slowly (at least it did when I last tried some months ago); also, it seems to either require adding all files in a dir and using ignore-files, or starting a fresh folder – I'd rather just say "share this and that file only"
I found this the other day and thought it was pretty cool, real world application unfortunately didn't go as well as my local experiment. The file we were trying to work on ended up being repeated multiple times in the same session and characters were missing randomly at the beginning of some lines. Very wierd. That said, I still think it's a really nice concept and will give it another try.
When we tried on an empty file it seemed fine, I wasn't in voice chat with my friend but I wouldn't say it was but, unfortunately once we got to real work it wasn't behaving properly so I can't tell.
Feel free to raise an issue and I'll take a look at it for sure - Jamie (the author). This could sometimes happen on earlier versions of the package, but has since been amended. But I would love to know more and see how best to rectify it.
I will see if/how I can reproduce it. This happened less than a week ago and it was just to try help a friend with a little script so I didn't go very far with it but i'll see what I can do to help! I actually thought it was really nice and having it working would be amazing.
This is cool for Atom users! But it's also a sign of how text-based interfaces are extremely versatile in their simplicity.
If Atom like many other great editors (vi, emacs, yi) was text-based at the core (although the examples have graphical frontons available) you get this without effort with tmux.
Not true. This supports each collaborator manipulating text in tandem, each with her or his own caret position. Also you can work in different files. That is simply not possible by throwing some tmux on it.
Virtually our entire team has migrated to vim for this reason. We do a lot of pair programming and about 25% of the team is remote full time, so it is a big deal. Even the non-remote people tend to be remote about 20% of the time.
It's strange that since I've switched to tmux and vim, I vastly prefer it to any other setup. I even ssh/tmux/vim pair when the person is sitting right next to me -- it's just so much more comfortable.
What's even stranger is that I have returned to an almost all-terminal existence - vim (and emacs for org-mode :-) ), mutt, irssi (connected to slack...), cmus (for music). The only thing I use X for is my browser.
Wow, this really is the holy grail for my small team. We have junior developers who would really gain a lot to see the senior's programming, but still able to work on other things at the same time.
As was posted somewhere else in the thread, Floobits is a collaboration plugin that supports the IntelliJ family of IDEs, as well as Sublime, emacs, and neovim.
It works really well, even cross-editor. Though I've had a few issues when two users are editing lines too near each other (but the last time I used it was almost a year ago).
Most people hate pair programming. I opened up pairprogram in freenode IRC. When people had problems in other programming channels and I suggested to pair program to work it out, most refused. They just wanted the answer pastebin to them. I used http://tmate.io/ running inside an LXC container running inside a VM.
I think your experience has been skewed by doing pair programming with someone on the internet, as opposed with a coworker or lab mate. Very different dynamic when you're pairing on something you'll personally work on again, as opposed to just fixing someone else's problems.
I'm always fascinated how the editors we use tend to bloat. It seems like they get more and more features till they are a full blown IDE. I come from a Unix/Vim background and I thought "can Vim have a pair program… uh… wait! WAT?!" It does and it is call TMUX/GNU Screen. See in the Unix world programs do one thing and they do it well. You compose them or layer them to accomplish a bigger picture. So running Vim edits text while running TMUX/Screen lets you pair with multiple tabs and/or interact with the same Vim instance. So again I must ask "Why do text editors need to feature creep?"
Jesus guys, enough with the white knighting for Atom. I think you should use whatever editor you want, I'm just countering the point that it's not bloated because it's modular.
I don't think anyone is against the idea that you should use what you're comfortable with. I'm just backing up the idea that Atom is bloated, and even with all of the modules removed it's still going to be huge.
I have a machine with 6 1TB HDDs and a 512GB SSD, why do I care?
As long as it's not so big it becomes inconvenient to download it (IMO in the 10+GB range) I simply don't care about it's size, it doesn't effect me at all.
Use what you want to use, this field has too many holy wars already.
Many people don't explicitly for this reason. I know I can't, its just too much stuff stuck together. I'd expect something like VS and Atom to be made well polished and optimized. The projects are rather large and both have well staffed teams behind them. I'll take sublime, eclipse, or even JetBrains products over VS/Atom because those editors/IDEs are polished and simple to use. I don't need to RTFM just to add three lines to a text file.
But does it really matter? We are not developing using potatoes. Even a 5 year old computer bought at a department store should have no issues running Atom.
The more useful metric would be, what's the actual performance like? I couldn't care less if it used gigabytes of otherwise unclaimed memory for caching. Unused memory is wasted memory.
Atom has more potential, as it embeds a full web browser. That potential is mostly untapped right now, but it is there.
As someone who uses Tmux for this purpose every day, pair programming with a content aware pair programming editor is a very different experience.
Typing at once in different parts of the code would be a huge boon to pair programming (that isn't even possible with in-person pairing, yet). Imagine being able to jump in and fix a typo while your pair keeps writing the next line.
There's no product that does this well enough for reliable daily use across a range of project types, but I can dream.
While not for code, Google Docs does this well enough that I've written things while a friend literally fixes typos, starts on the next paragraph, and sometimes edits the same line i'm on.
Neat project. I was going to ask why you’d use Pusher instead of a WebRTC data channel as this is 1-to-1 P2P, but then I saw that it’s a Pusher project so I suppose there’s my answer.
Atom, with a single source file open and freshly started, already weighs in at 500 MB resident when adding all processes together . It still lacks mode sensitive toolbar support, button bars, and basics Emacs has. I wish I could find a good editor that didn't kill my machine. Computers have far more memory and computing now that 10 years ago, but everything seems to run so much slower because of the cavalier attitude towards performance nowadays.
I use notepad++ (windows) on about 10 computers that I use at work to quickly edit python files, mostly sublime text and PyCharm (OOB auto-completion, refactoring, documentation feature, and easy git integration) for more extensive coding on my main computer, and use VIM on remote servers. I've tried EMacs several times in the past but I found the commands a little hard to remember and little bit harder to get around in the editor than on VIM. I use atom time to time to get that feeling of sublime text on my other work computers but I tend to steer towards notepad++ because it's very snappy and i can do things more quickly for simple tasks. I prefer Sublime in most situations but I tend to just use whatever fits the best for the system and tasks at hand. I think this pair programming feature will be very useful when I'm working remotely with my team members located in other states.
This looks like a great idea, but this was unfortunately it was really buggy and I couldn't get it to work. Would be very happy to try it out again once the bugs get ironed out.
Was excited to try this out, played around with it for about 10 minutes but gave up because there are too many bugs (all that I encountered have been reported as issues already). I'll try again once those issues are fixed.
54 comments
[ 3.0 ms ] story [ 121 ms ] threadIf Atom like many other great editors (vi, emacs, yi) was text-based at the core (although the examples have graphical frontons available) you get this without effort with tmux.
It's strange that since I've switched to tmux and vim, I vastly prefer it to any other setup. I even ssh/tmux/vim pair when the person is sitting right next to me -- it's just so much more comfortable.
What's even stranger is that I have returned to an almost all-terminal existence - vim (and emacs for org-mode :-) ), mutt, irssi (connected to slack...), cmus (for music). The only thing I use X for is my browser.
I wish JetBrains also had this!
It works really well, even cross-editor. Though I've had a few issues when two users are editing lines too near each other (but the last time I used it was almost a year ago).
It's incredibly convenient to just install an extension, as opposed to an external program, configure paths and the like.
Edit:
Jesus guys, enough with the white knighting for Atom. I think you should use whatever editor you want, I'm just countering the point that it's not bloated because it's modular.
You can spend your life proving that your editor is the truth, or you can get on with it and build something awesome.
As long as it's not so big it becomes inconvenient to download it (IMO in the 10+GB range) I simply don't care about it's size, it doesn't effect me at all.
Use what you want to use, this field has too many holy wars already.
But does it really matter? We are not developing using potatoes. Even a 5 year old computer bought at a department store should have no issues running Atom.
The more useful metric would be, what's the actual performance like? I couldn't care less if it used gigabytes of otherwise unclaimed memory for caching. Unused memory is wasted memory.
Atom has more potential, as it embeds a full web browser. That potential is mostly untapped right now, but it is there.
Typing at once in different parts of the code would be a huge boon to pair programming (that isn't even possible with in-person pairing, yet). Imagine being able to jump in and fix a typo while your pair keeps writing the next line.
There's no product that does this well enough for reliable daily use across a range of project types, but I can dream.
At least it's possible...
(I'm not affiliated, just have used it for pair programming before with success)
Because source code is text. Text is edited using a text editor or an IDE.
(Hint: those are all visual or hybrid textual/visual programming languages.)