I've been using Atom for a couple of weeks now, mainly for a few Laravel applications. I use the git-hide package to remove the ".git", "node_modules" and "vendor" directories from the tree view which does seem to have a nice effect on speed.

That said, here are the issues I face:

- I frequently find that I type too quickly for the editor to pick up the keys and I end up missing off the beginning of some lines.

- I still use Sublime text daily for quickly opening a file, rather than waiting for a new Atom instance to open.

- PHP support is awful. Auto complete for class names in any used packages is something that I sorely miss from the Sublime plugin I use.

- Start-up time still takes a few seconds which means I only use it for projects.

- Listing of installed and discovery of packages is _so_ slow. Sometimes I just don't bother installing a package anymore because it takes at least 10 seconds to show me what I have installed or search for one.

Regardless of me using Atom, I'm still loving the updates to Sublime and continue to moderate the forums, knowing that Jon will deliver :)

That's not to say that it doesn't have its own problems. One massive pain-point: I was assisting with a getting a complex build system working a few months back. The VSCode build integration is scenario-driven garbage. Because I deviated from the most basic of scenarios I had to resort to all manner of nasty hacks to avoid having contributors open a CLI.

I feel it'll never be a sensible choice until people no longer have to type sentences like this.

I may be wrong, so please let me know :)

  "tree-view":
    hideIgnoredNames: true
    hideVcsIgnoredFiles: true

EDIT: Do I really need to say /s ?

A piece of software like a programming editor, which until now leaves a lot to be desired, even in the most popular implementations (Vim, Emacs, ST, Atom, etc), sure needs constant reinvention and refinement until someone finally gets it right.

Atom would be close to that if it was not fucking based on web technologies. ST3 would be that if it was open source (so the APIs/internals could be improved faster). Emacs would be that if it wasn't based on a 30+ year old UI model and elisp. Vim would be that if it was more extensible and not 100% focused on the CLI experience.

Also, your underlying point is practically offensive to the hacker mindset. Though there is nearly a cult-like devotion to the editing tools of yore, the devotion is not universal.

With emacs and vim around, I'd argue that text editors is a solved problem, if there ever was one. It is very hard to match emacs in terms of useful features or adaptability. Granted, the learning curve has a reputation for being steep, and elisp could need a facelift, but I think addressing these problems would provide much more value than reinventing the wheel with another shiny editor.

[1]: https://github.com/atom/electron

It still somehow manages to feel faster than many other editors.

Is there any plugin/editor combination that still does C completion like SublimeClang used to do?

[1] http://limetext.org [2] https://github.com/quarnster/SublimeClang

I have been using atom now full time for 3 weeks and gave it another chance as I love a lot of the plugins it has and the community and I am very impressed.

Regarding its slowness it has improved a lot. The only complaint I have with its speed compared to a native app like sublime is that it is slow in starting. This doesn't affect me much as when I am working on a project I leave it open all the time anyway :-)

Give it a try and get some of the useful plugins and you will never look back.

Atom is fine for many people's usage of it, and it does some interesting things. It is not without merit. But until issues like this go away, I can't consider it. I regularly need to work with text files several hundred megabytes large. Atom cannot handle this usage. And before you say "Well, you're deliberately being difficult"... I am either taking a quick look at big csv files or automatically generated XML files that store configuration information for some of the systems I work on. A 120 MB XML config file isn't unusual.

ST3 is a great editor. My biggest problem with the recent pause in development is that I have to install a plugin to get Rust syntax highlighting.

I just wish Node-based editors were as nimble as ST.