Live data from Hacker News

Code together in real time with Teletype for Atom

blog.atom.io

51–60 of 230 posts

Re: Code together in real time with Teletype for Atom

#51
post #44

Earlier quoted context omitted.

Microsoft is not known for finesse in their marketing tactics. Just had a déjà vu with Microsoft's NetPC, announced just after Sun Microsystem's Network Computers. That said, I do like VS Code very much. Gave Atom a try, but it felt sluggish and its add-ons were very fragile.

VS Code is certainly neat, but with the rush to cram everything into it, it's starting to feel more like emacs than vi.

But?

Re: Code together in real time with Teletype for Atom

#52

i prefer this over floobits in that i don't need a floobits account, just a github account, which pretty much all devs will already have. it would be nice if there was a way to do this without needing the github account though.

With floobits though you can go ahead and use atom while I chill in vim or sublime. It doesn't demand that you both use the same editor.

Re: Code together in real time with Teletype for Atom

#53
post #39

Is it only a coincidence that real-time collaboration is being announced both for Atom and VS Code ( https://news.ycombinator.com/item?id=15704376 ) at the same time?

Why is there breakneck competition here to offer the best free code editor?

I know, right? Vim and emacs should ease off a little :)

Re: Code together in real time with Teletype for Atom

#54

Earlier quoted context omitted.

For certain definitions of 'high-end', maybe. You've been able to configure workstation-class laptops with 64 gb for a few years now. And most mid- high-end laptops will happily accept 32GB, again going back a few years. (Broadwell removed the density limitation that made 16GB DIMMs a no-go; anything that takes DDR4 should support 16GB SODIMMs, excepting the very low end Atom, Celeron etc.)

Why am I expected to have a workstation-class laptop to run my text editor?

You really aren't. Atom runs fine on a Macbook Air. There are definitely performance issues, but we're addressing them; it's just that our team is small and our initial goal at launch was to produce the most hackable text editor possible.

Re: Code together in real time with Teletype for Atom

#55
post #6

Really gave atom a hard try. Back to notepad after a few months. The add-ons are the only advantage, but are grossly overshadowed by the resource consumption this behemoth requires.

Sorry to hear that. We’re improving Atom’s efficiency all the time, but there are definitely areas that we just haven’t gotten to yet.

In your opinion, what, if improved, will give Atom the biggest performance boost?

Re: Code together in real time with Teletype for Atom

#58
post #55

Earlier quoted context omitted.

Sorry to hear that. We’re improving Atom’s efficiency all the time, but there are definitely areas that we just haven’t gotten to yet.

In your opinion, what, if improved, will give Atom the biggest performance boost?

I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump:

In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations.

1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter.

2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box.

3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements).

4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.

Re: Code together in real time with Teletype for Atom

#59
post #8

Is it only a coincidence that real-time collaboration is being announced both for Atom and VS Code ( https://news.ycombinator.com/item?id=15704376 ) at the same time?

The fact that VS Code's version isn't ready yet, and Atom's is makes me think that Microsoft wanted to respond to Atom's announcement. But I honestly have no idea if that's the case. Just pure speculation. Edit: Atom's announcement was yesterday. Microsoft's was today. That further fuels my speculative hunch. :)

I have a hard time imagining that Microsoft would make a decision like that in under 24 hours.
Post reply on HN