Yeah, I actually started on a package that would render comments as markdown, allowing you to create 'notebook'-style source code. I gave up when exploring the API and not finding a good way to replace lines with (possibly variably-height) content.

There's also the problem that Atom doesn't have any debuggers worth speaking of so far. That could change now.

I'll have a look into this. Sounds great anyway.

I've recently started using more, but I still have to turn to sublime fairly often due to speed (dealing with larger projects, bigger data files, more complex regex searching).

That being said, the performance has been getting steadily better, enough to the point I can do most of my coding in it without noticing a problem. I'd suggest giving it another go and see how it does for you! It's quite a joy to hack on.

I've been using Atom full-time for about a year, after switching from Sublime. I'm happy with it as an editor, and like the momentum behind the plugins ecosystem. Performance has been completely adequate, and I've seen none of the issues that always seem to crop up whenever Atom is mentioned on HN. There may be a platform difference - I use it on OSX, but friends of mine on Linux have been less satisfied.

I do still resort to vim on the command-line for some things, but as a "daily driver" code editor, Atom has been excellent.

I tried installing it recently and adding on the facebook react extention, and whilst installing it completely broke.

Restarting made it end up in the same install cycle as before.

Atom fixes what is broken in Sublime, but has it's own issues that are currently far worse.

I've been using Atom full time for about a year and a half now. I've never noticed performance issues though, so I've always been curious about where these complaints come from.

I just ran a find over the project I've been working on full time, and the largest file, by a long shot, is 8kb, and a little under 100 lines. That's just an autogenerated enum of the HTTP status codes though, so it isn't indicative of real code.

In the vast majority of cases, all of my files are less than 4kb, and hover around 40 lines or so. Atom handles this use case just fine, and I'm hard pressed to think of a situation where I'd run into performance concerns. The entire process itself is using less than 80mb of RAM, and 0.2% of my CPU. A single tab of Chrome is worse than that.

What are people doing with their text editor that they need blazing speed?

It actually has. Atom became unusable for me, but the most recent version fixed a bug involving the .git file. It's not sublime fast, but it's enough that I enjoy using it now.

I use it regularly for editing the front-end portion of our project. Granted it's not the biggest project (36 folders and 158 total files.) but it performs quite well. I have some problems using git from the command line as atom seems to lock random files from time to time. I really have no complaints. I enjoy using it and find the community packages that are available quite useful.

It's still kind of bad. Just try opening up a minified JS (or any kind of large file) file and watch your Atom become unresponsive for 5 minutes.

Yeah I really like a lot of Atom packages and there's a lot of cools stuff coming out for it. It starts out kinda slow and sometimes it takes a bit to highlight syntax (less than a second but still), but otherwise I like it.

It has improved but it still has pain points, it's good to have backups. Had to revert to enact for dealing diffs and git commits.

People always complain about performance, but you just have to be conscious when using it. Don't open a massive file and you should be fine.

> Why CSON and CoffeeScript... in 2016?!

All new code is ES6: https://twitter.com/nathansobo/status/670047510258253828

Pretty sure they're moving to ES6 these days: https://github.com/atom/toggle-quotes/pull/26#issuecomment-1...

I've never done it, but id assume the effort to do a rewrite would be tremendous.