I really want to love Atom, mainly due to the plethora of cool plugins being created lately. However, its inability to handle large files and the slow launch times are unfortunate.
On the note of Vim, i wonder what could make Plugin development as active as Atom?
To me, that is a large part of what makes Atom attractive is the development community. I don't feel like Vim or Emacs has that, despite having so many plugins/etc. There just isn't as much Zeal for it.
I wonder if something about Vim could simplify this. Make it easier to support, develop, extend and use plugins?
Don't use Vimscript? You can't beat the react and ease of use of JavaScript. Also, a lot of people like their editors minimal. Vim users especially delegate a lot of work to Unix tools.
Atom is ~30 years newer than the original version of Windows Notepad, and Atom runs on hardware that is orders of magnitude faster than the 286 on which early versions of Windows ran.
Yet Atom is still slower and laggier than Notepad running on Windows in 1986.
How did GitHub manage to pull off that feat? Given the fact that faster programs were made 30 years ago on vastly inferior hardware, Atom's performance absolutely deserves to be criticized.
I can start Visual Studio right now and make a simple Windows desktop app in an hour with a text editor whose performance ( startup/ file load / editing ) will blow Atom away.
> Yet Atom is still slower and laggier than Notepad running on Windows in 1986.
I would love to see something beyond just a void claim of this. Numbers, a video, literally anything. Even though Atom has a completely different use case than Notepad, one is for a quick edit of a file and one is for managing a project including file indexing, project search, and plugins, I still don't believe this is true. And I don't even like Atom!
It would be great to post a video or some actual performance numbers, but I don't know where I'd get my hands on a 286 running the original version of Windows.
I'd wager, if you somehow could find it, your nostalgic view of the speed of a computer from the 80s would quickly diminish. Especially when you had to deal with more than one file with Notepad.
This point gets brought up a lot, and the criticism is fair, but only to a point. Atom's primary innovation is being built with HTML, JS, and CSS, and running on top of Electron that's running on top of Chromium. This design makes its internals approachable for a large audience. For lack of a better term, it's a first-party tech demo for Electron.
At this layer, you're pretty far from bare metal, and it's nice that it works as well as it does. In the future, I believe the need for so many layers will be lessened, when native script hosts and renderers can be leveraged, API calls shimmed between platforms, when packaging full Chromium is no longer necessary. Therefore I fully expect Atom to get better, both on the below-Electron side as native platforms evolve [1], and above, through optimizations.
For me, it's about expectation management. I expect Atom to be a proper text editor, but not necessarily a performant one yet, because I know how it's built.
It's a significant indictment of the technology, and of GitHub's engineering that a product like Atom is slow on th high-end Dell hardware that my employer buys for me.
Atom's problem, which includes the astoundingly enormous amount of CPU and memory that it guzzles, is that the people who built it demonstrably didn't care about performance, didn't know better, or both.
Atom is a textbook example of how not to write software. I guess it's not only 'hackable to the core', but 'inefficient to the core'.
Yes, it is; much more so an indictment of the stack than Atom itself.
> didn't care about performance
Perhaps; I can see why they would prioritize features over performance.
> Atom is just a textbook example of how not to write software.
I disagree. I very much feel that Atom is about demonstrating an archetypal 'desktop application', like a text editor, in Electron. And Electron is about coding in HTML/JS/CSS, albeit currently it's backed by a entire shrinkwrapped Chromium, which means you're essentially stuck inside a particular browser and inherit all of its performance characteristics.
It's the Electron stack that must prove that it's viable in the long-term, but it's possible that Atom will catch a lot of the flak instead.
I guess that's part of the disconnect between happy users and folks who find it too slow. Atom is an effective IDE for me. I have smart auto-completion, version-control integration, task runners, linting, and, for many of the languages I work with, definition lookup, a debugger, a repl, and inline reporting of compilation errors. It makes for a great markdown writer as well. As a daily one-off text editor I can understand the complaints. But compared to a proper IDE, the startup time is pretty competitive.
I love Atom as well and didn't understand why there were so many complaints about its performance, but once I ran into one of these issues myself I was unable to use it for the time being.
This specific issue opened on github[0] seemingly would affect a large number of atom's userbase - "Windows users with git repos" - and yet the best course of action is to modify atom from a community workaround. I love the editor and can't wait to go back to it, but I do really wish they would make a push to fix the smattering of performance issues and transition to v2.0. I think the editor is going to continue to have a bad PR problem as long as each discussion thread is half-full of potential users complaining about performance.
It seems like some people have created VLF-like packages for Atom that employ similar workarounds to emacs for large files. This tickles me, but I assume long term this'll be solved more fundamentally.
I personally never cared much about emacs' similarly slow loading times, and don't see much of an issue with a modern editor taking time to start up. I'm happy just never quitting emacs on any of my machines, but it does mean you need something that interacts with sudo (i.e. tramp in emacs) to make quick edits to config files etc.
I know this gets viewed as overly negative, but to provide a bit more context: I still use my purchased Sublime text instance for: 1) Quickly opening single files, and 2) Opening large e.g. JSON files. I prefer everything else about Atom / VSCode, but in my experience they have not yet matched the performance of Sublime Text.
For me it's not so much the slow start-up time - that I can deal with since it happens so infrequently - it's the intermittent lag when typing or selecting text, and the high memory and CPU usage. A text editor should not be consuming 100% of a CPU core for almost any length of time and making my laptop sound like an aircraft carrier.
I love the concept of Atom (OSS text editor is awesome!), but it's bordering on unusable for me at the moment.
EDIT: Not sure why I'm being downvoted, but I'm genuinely curious. I searched the package manager and google, but couldn't find anything that offered this functionality.
So, the first 2 searches pulled back fairly poor results. It would perhaps be useful to have a cycle to next result shortcut, in order to keep searching until you find something of use. That said, the Atom plugin used the same search term and returned a better first result, so it might be worth using something like their method for determining the top result.
FWIW...
First search, "QuickSort" returned:
6 + 7 = 13
13 / 2 = 6.5
6.5 rounded down = 6
Next search, "BubbleSort", produced:
It depends on the way your data is distributed - if you can make some assumptions. One of the best links I've found to understand when to use a bubble sort - or some other sort, is this - an animated view on sorting algorithms: http://www.sorting-algorithms.com/
Atom does look very cool. Systems will get faster and any performance problems with Atom should diminish.
But Atom makes me sad. I've got years and years invested in understanding how Emacs works and being able to tweet the capabilities of Emacs and write my own commands and packages in Emacs Lisp. I feel kind of stuck with it now.
Don't get me wrong its a great place to be stuck--Emacs is the world's most powerful editor. Yet, a weakness that has always bothered about Emacs is it's reliance on an unpopular language, its own version of Lisp. There are so many Javascript programmers that, eventually, a Javascript based editor will exceed the capabilities Emacs which is written in Lisp and C. (I don't rule out success for NeoVim either, the foundation of vim with a clean way to write packages in Python, totally cool!)
I wish there was a Neomacs project or a true org-mode and magit for Atom.
Systems will not get faster since Moore's (not murphys) law is reaching its end. Though Atom could certainly get faster in a variety of ways. I think my biggest problem with atom currently is that its only useful on a personal computer in long sessions. I would never (could never) install it on a server and certainly cant use it to create a little script or project.
Is it reaching it's end though? I could foresee us simply scaling horizontally rather than vertically. Even if it ends up drawing more power, more total CPU could still mean an increase in raw performance, no?
(assuming systems were setup with better parallel processing. I'm aware that NodeJS is pretty terrible on this front)
The end of Moore's Law does not mean that processing power will stop improving. It just means that there will likely be a slower rate at which the number of transistors gets doubled. Say, 3 years instead of 2. I think there is a physical boundary to that, but Moore's Law doesn't really address that.
I'd be down for a new 'big bad editor' in the style of emacs' kitchen-sink philosophy (and hopefully completely modal by design, like spacemacs/vim). But basing the ENTIRE thing on Electron/JS/"web tech"...man, I hope not.
Being sad about that is like being sad about being emotionally invested in your collection of Beatles music when all the kids these days love Justin Bieber.
The analogy breaks with the fact that if few people use emacs, you don't get to benefit for all their effort in making it better - whereas with the Beatles, having more or less fans doesn't actually make new Beatles albums.
So it's now the hardware's job to adapt to poorly written software by "it should get faster"?
Sorry if this sounds salty, but I don't think it's justified to say performance issues can be swept under the carpet since the future hardware will be faster. Atom definitely needs to get faster, Visual Studio Code for example is built with the same underlying web techniques and performs way better.
I manage Atom at GitHub and I wanted to chime in here saying I agree! We're not waiting for hardware to fix this. My first PC was 386 running at 20 MHz. Modern hardware is insanely fast! Improving Atom's performance is positively a team priority. The overhaul of the display layer that shipped in Atom 1.9 represents a significant step down that path.
I just wanted to plug an up-and-coming editor called Howl (http://howl.io). Written in and extended using Lua (actually Moonscript), not Javascript, and definitely very easy to extend. As an ex-emacs users I do find it similar in some respects.
I'm biased of course since I use and develop for Howl :)
Yeah, I'd like to know when one of these new text editors will support plain text spreadsheets like Emacs and Org-mode do. Much of my notes include small sets of tabular data on which I perform basic calculations, and I love being able to include the data directly in my notes rather than refer to Excel or LibreOffice spreadsheets elsewhere.
Hey everyone ! I'm Nick - GitHub Campus Expert and the author of this tutorial. I'm glad that you all enjoyed hacking with Atom and can't believe that my post got to the front page! I would love to answer any questions about the content and would appreciate any feedback for this or future posts.
Automatically finding and dragging in code from stackoverflow is the most dangerous thing I've ever heard of. How accurate would you consider comparisons between yourself and J. Robert Oppenheimer?
Jokes aside it's a cool tutorial. Plugin development for many editors is unnecessarily hard and a detriment to their ecosystems. It's cool that it's that simple for Atom. But as someone happy with my current editors (Jetbrains derivatives + plugins for projects / Sublime + plugins for small stuff), what advantages would you say Atom has that would incentivize people to try it out?
While I advocate hacking Atom, I don't advocate actually using the plugin the tutorial teaches you to make as-is! A safer bet is Sourcerer (https://atom.io/packages/sourcerer) - it's got some neat features like previewing snippets and attributing credit to the SO author through added comments. I always thought of this plugin as an educational tool for learning new languages, rather than something to be used regularly when building real software. That said, So many of us use StackOverflow to find library/API examples, and this is a nice shortcut! I think that this is generally safe for finding one-line examples and shorter snippets, where it's easy to read and understand what the code does.
Before switching to Atom, I used vim and Sublime Text. The thing I enjoyed most about both of these editors was extending them with plugins. I think it's important to customise and personalise your editor because it's one of the few tools we use the most as developers, and any tweak/feature that saves us time doing a particular task means a great deal in the long term. I chose to switch to Atom because it's an editor designed around being easy to extend and customise - anyone who has done any web/Node development can dive right in. There are already nearly 5000 packages and themes available, and so far I found it much more open and easier to develop for than both Sublime and Vim.
Yay - it's great to get some more documentation about how to build plugins for Atom.
That said, this tutorial neatly avoids adding much to Atom's view layer. When you try to extend the user interface you'll eventually run into https://github.com/atom/atom/issues/5756 "Let's choose a view framework for docs, generated packages, etc." which has been open for nearly 18 months.
There's a commendable commitment not to force a single view framework on all plugin authors, but the cost of that seems to be that there's no single view framework that the project feels comfortable recommending and documenting as a starting point for new authors. And without a view framework to present as an example, there's little to go on to help figure out how to structure a plugin with some custom user interface components. The project generator used in this tutorial creates a sourcefetch-view.js file, but the tutorial never mentions it. The Atom flight manual talks about the view file in a little more detail, but stops short of explaining how responsibilities should be split between model and view in a more complex plugin. The best option available seems to be to go reading through the source code of other existing plugins out there, but as each chooses a different approach (see original problem) it's difficult to pick up what might be considered best practice and what has been deprecated - some packages use atom-space-pen-views for example, but that's the old recommended view framework that's been deprecated for a while.
I like Atom as an editor, and part of the reason is that I really would like to extend it by using the languages that I'm already familiar with. But writing a plugin will (for me) only ever be a side project, and the amount of research I need to do to understand how to build some meaningful UI in Atom is too great at the moment for me.
After 10 years in Vim and 5 years in Emacs, I recently switched to Atom. The reason I switched is how easy it is to extend. And it truly is: I was up and running in a few hours with my first plugin in Atom (the emacs legacy of code is daunting, while vimscript is truly awful). This is a great resource, which I had patched together while I was building my first plugins.
One major downide of atom is that while you can develop your own plugins, core atom modules are extremely slow to accept contributions. I spent a lot of time on something (https://github.com/atom/tree-view/pull/913) which makes sense in core but is hard to do as a package, and it's been ignored, along with 42 other PRs on the same repo.
I really like Atom for its hackability, but an important part of hackability is community contribution. Their roadmap is 404ing (http://blog.atom.io/2014/10/23/public-roadmap.html), they don't really take public contributions, and AFAICT there's no public product direction of any kind. I hope they solve this - Atom is too good to lose to bad community management.
Thanks very much for the feedback! We're always excited to hear when people enjoy using Atom.
It is true that we have been extremely slow to accept contributions. There are many causes for this, not the least of which is that we are a small team of maintainers working on a very large and ambitious project. Whatever the causes, it is something that I am committed to fixing. I'm working with the engineering manager on a new system of prioritization to burn down the backlog of PRs needing review (https://github.com/search?utf8=%E2%9C%93&q=user%3Aatom+is%3A...). We feel we've made some good progress because of it.
We took down the roadmap because it wasn't being maintained by the team anymore. (I'll amend the blog post to note that fact.) We felt that no roadmap is better than an incorrect one. The best we can offer right now for a public roadmap is what is currently being worked on by the official Atom maintainers. There is an easy GitHub search linked in the Atom FAQ on the subject (https://discuss.atom.io/t/is-there-an-atom-roadmap/21033). Longer term this is also something that we are going to be increasing transparency on.
Again, thank you for calling out these problems. Community contribution is important to us. We're having some growing pains right now, yes. We are committed to fixing them and I and the rest of the team hope that you and others with the same concerns will stick with us while we work out exactly how to fix them!
I'm the engineering manager lee-dohm mentioned and I just want to echo his sentiment.
We recognize this problem and are working hard to improve it! We're of course thrilled by how popular Atom is, but as you've seen, it's been a real challenge to keep up with the size of the community. The team is small, but growing!
In fact, if you're interested in getting paid to help us fix this, apply to join the team! Openings for engineers on the Atom team will be posted here later this week: https://github.com/about/jobs#positions
Atom is too good to have this comment be the top one on the article - alas I can't delete it.
It looks like I was wrong about the community contribution. They mentioned it elsewhere: the maintainers of the module I was happened to both be on paternity leave. I suspect they didn't mention it here because they didn't want it to seem like an excuse, but of course people should be able to take paternity leave without worrying about some errant comment on HN giving them a bad day.
As soon as they came back it was resolved quickly, my PR got a review, and another one was accepted. All in all, I'm feeling much better about the community part of Atom, and thoroughly sorry for raising a fuss!
Given the amount of complaints about this (from me as well) I would think this would be priority #1 for Atom developers, but that doesn't seem to be the case.
I remember some time ago there was an uber issue on Github for this, but I think I remember seeing it marked as resolved when I can absolutely tell not much has changed (and I have installed barely any plugins). :(
EDIT: This is even more disappointing after observing that the post author -- "GitHub Campus Expert". What a fantastic example being presented to students.
58 comments
[ 2.6 ms ] story [ 140 ms ] threadIt's also fine for me, and I love plugins like the merge conflicts one[1].
[1] https://atom.io/packages/merge-conflicts
(edit: holy downvotes, Batman! I thought I'd provide a helpful point about vim, since not everyone knows it has plugin capability. My bad!)
To me, that is a large part of what makes Atom attractive is the development community. I don't feel like Vim or Emacs has that, despite having so many plugins/etc. There just isn't as much Zeal for it.
I wonder if something about Vim could simplify this. Make it easier to support, develop, extend and use plugins?
Yet Atom is still slower and laggier than Notepad running on Windows in 1986.
How did GitHub manage to pull off that feat? Given the fact that faster programs were made 30 years ago on vastly inferior hardware, Atom's performance absolutely deserves to be criticized.
I can start Visual Studio right now and make a simple Windows desktop app in an hour with a text editor whose performance ( startup/ file load / editing ) will blow Atom away.
I would love to see something beyond just a void claim of this. Numbers, a video, literally anything. Even though Atom has a completely different use case than Notepad, one is for a quick edit of a file and one is for managing a project including file indexing, project search, and plugins, I still don't believe this is true. And I don't even like Atom!
I do remember typing reports in Notepad. We had a PC because my parents couldn't afford a Mac.
https://pavelfatin.com/typing-with-pleasure/
You can download the software he wrote and try it for yourself, on your different text editors with plugins etc.
At this layer, you're pretty far from bare metal, and it's nice that it works as well as it does. In the future, I believe the need for so many layers will be lessened, when native script hosts and renderers can be leveraged, API calls shimmed between platforms, when packaging full Chromium is no longer necessary. Therefore I fully expect Atom to get better, both on the below-Electron side as native platforms evolve [1], and above, through optimizations.
For me, it's about expectation management. I expect Atom to be a proper text editor, but not necessarily a performant one yet, because I know how it's built.
[1] https://msdn.microsoft.com/en-us/windows/uwp/get-started/cre...
They couldn't make it fast on modern hardware?
It's a significant indictment of the technology, and of GitHub's engineering that a product like Atom is slow on th high-end Dell hardware that my employer buys for me.
Atom's problem, which includes the astoundingly enormous amount of CPU and memory that it guzzles, is that the people who built it demonstrably didn't care about performance, didn't know better, or both.
Atom is a textbook example of how not to write software. I guess it's not only 'hackable to the core', but 'inefficient to the core'.
It's just bad software.
Yes, it is; much more so an indictment of the stack than Atom itself.
> didn't care about performance
Perhaps; I can see why they would prioritize features over performance.
> Atom is just a textbook example of how not to write software.
I disagree. I very much feel that Atom is about demonstrating an archetypal 'desktop application', like a text editor, in Electron. And Electron is about coding in HTML/JS/CSS, albeit currently it's backed by a entire shrinkwrapped Chromium, which means you're essentially stuck inside a particular browser and inherit all of its performance characteristics.
It's the Electron stack that must prove that it's viable in the long-term, but it's possible that Atom will catch a lot of the flak instead.
This specific issue opened on github[0] seemingly would affect a large number of atom's userbase - "Windows users with git repos" - and yet the best course of action is to modify atom from a community workaround. I love the editor and can't wait to go back to it, but I do really wish they would make a push to fix the smattering of performance issues and transition to v2.0. I think the editor is going to continue to have a bad PR problem as long as each discussion thread is half-full of potential users complaining about performance.
[0]: https://github.com/atom/atom/issues/9544
I personally never cared much about emacs' similarly slow loading times, and don't see much of an issue with a modern editor taking time to start up. I'm happy just never quitting emacs on any of my machines, but it does mean you need something that interacts with sudo (i.e. tramp in emacs) to make quick edits to config files etc.
AFAIK, there's no equivalent in Atom yet.
I love the concept of Atom (OSS text editor is awesome!), but it's bordering on unusable for me at the moment.
EDIT: Not sure why I'm being downvoted, but I'm genuinely curious. I searched the package manager and google, but couldn't find anything that offered this functionality.
I think it's really sad you're being downvoted. Dunno why anyone would do that, it's a good question.
FWIW...
First search, "QuickSort" returned:
Next search, "BubbleSort", produced:- https://code.visualstudio.com/docs/extensions/overview - https://code.visualstudio.com/docs/extensions/example-hello-...) to some getting started examples
But Atom makes me sad. I've got years and years invested in understanding how Emacs works and being able to tweet the capabilities of Emacs and write my own commands and packages in Emacs Lisp. I feel kind of stuck with it now.
Don't get me wrong its a great place to be stuck--Emacs is the world's most powerful editor. Yet, a weakness that has always bothered about Emacs is it's reliance on an unpopular language, its own version of Lisp. There are so many Javascript programmers that, eventually, a Javascript based editor will exceed the capabilities Emacs which is written in Lisp and C. (I don't rule out success for NeoVim either, the foundation of vim with a clean way to write packages in Python, totally cool!)
I wish there was a Neomacs project or a true org-mode and magit for Atom.
(assuming systems were setup with better parallel processing. I'm aware that NodeJS is pretty terrible on this front)
Sorry if this sounds salty, but I don't think it's justified to say performance issues can be swept under the carpet since the future hardware will be faster. Atom definitely needs to get faster, Visual Studio Code for example is built with the same underlying web techniques and performs way better.
I hope their efforts result in fast software we love to use..
I'm biased of course since I use and develop for Howl :)
Here's a link to video segment showing opening a large number of files: https://youtu.be/FmxKXWXj90c?t=24m50s
Jokes aside it's a cool tutorial. Plugin development for many editors is unnecessarily hard and a detriment to their ecosystems. It's cool that it's that simple for Atom. But as someone happy with my current editors (Jetbrains derivatives + plugins for projects / Sublime + plugins for small stuff), what advantages would you say Atom has that would incentivize people to try it out?
Before switching to Atom, I used vim and Sublime Text. The thing I enjoyed most about both of these editors was extending them with plugins. I think it's important to customise and personalise your editor because it's one of the few tools we use the most as developers, and any tweak/feature that saves us time doing a particular task means a great deal in the long term. I chose to switch to Atom because it's an editor designed around being easy to extend and customise - anyone who has done any web/Node development can dive right in. There are already nearly 5000 packages and themes available, and so far I found it much more open and easier to develop for than both Sublime and Vim.
That said, this tutorial neatly avoids adding much to Atom's view layer. When you try to extend the user interface you'll eventually run into https://github.com/atom/atom/issues/5756 "Let's choose a view framework for docs, generated packages, etc." which has been open for nearly 18 months.
There's a commendable commitment not to force a single view framework on all plugin authors, but the cost of that seems to be that there's no single view framework that the project feels comfortable recommending and documenting as a starting point for new authors. And without a view framework to present as an example, there's little to go on to help figure out how to structure a plugin with some custom user interface components. The project generator used in this tutorial creates a sourcefetch-view.js file, but the tutorial never mentions it. The Atom flight manual talks about the view file in a little more detail, but stops short of explaining how responsibilities should be split between model and view in a more complex plugin. The best option available seems to be to go reading through the source code of other existing plugins out there, but as each chooses a different approach (see original problem) it's difficult to pick up what might be considered best practice and what has been deprecated - some packages use atom-space-pen-views for example, but that's the old recommended view framework that's been deprecated for a while.
I like Atom as an editor, and part of the reason is that I really would like to extend it by using the languages that I'm already familiar with. But writing a plugin will (for me) only ever be a side project, and the amount of research I need to do to understand how to build some meaningful UI in Atom is too great at the moment for me.
One major downide of atom is that while you can develop your own plugins, core atom modules are extremely slow to accept contributions. I spent a lot of time on something (https://github.com/atom/tree-view/pull/913) which makes sense in core but is hard to do as a package, and it's been ignored, along with 42 other PRs on the same repo.
I really like Atom for its hackability, but an important part of hackability is community contribution. Their roadmap is 404ing (http://blog.atom.io/2014/10/23/public-roadmap.html), they don't really take public contributions, and AFAICT there's no public product direction of any kind. I hope they solve this - Atom is too good to lose to bad community management.
It is true that we have been extremely slow to accept contributions. There are many causes for this, not the least of which is that we are a small team of maintainers working on a very large and ambitious project. Whatever the causes, it is something that I am committed to fixing. I'm working with the engineering manager on a new system of prioritization to burn down the backlog of PRs needing review (https://github.com/search?utf8=%E2%9C%93&q=user%3Aatom+is%3A...). We feel we've made some good progress because of it.
We took down the roadmap because it wasn't being maintained by the team anymore. (I'll amend the blog post to note that fact.) We felt that no roadmap is better than an incorrect one. The best we can offer right now for a public roadmap is what is currently being worked on by the official Atom maintainers. There is an easy GitHub search linked in the Atom FAQ on the subject (https://discuss.atom.io/t/is-there-an-atom-roadmap/21033). Longer term this is also something that we are going to be increasing transparency on.
Again, thank you for calling out these problems. Community contribution is important to us. We're having some growing pains right now, yes. We are committed to fixing them and I and the rest of the team hope that you and others with the same concerns will stick with us while we work out exactly how to fix them!
We recognize this problem and are working hard to improve it! We're of course thrilled by how popular Atom is, but as you've seen, it's been a real challenge to keep up with the size of the community. The team is small, but growing!
In fact, if you're interested in getting paid to help us fix this, apply to join the team! Openings for engineers on the Atom team will be posted here later this week: https://github.com/about/jobs#positions
It looks like I was wrong about the community contribution. They mentioned it elsewhere: the maintainers of the module I was happened to both be on paternity leave. I suspect they didn't mention it here because they didn't want it to seem like an excuse, but of course people should be able to take paternity leave without worrying about some errant comment on HN giving them a bad day.
Also, the response was excellent: https://github.com/atom/tree-view/pull/913
As soon as they came back it was resolved quickly, my PR got a review, and another one was accepted. All in all, I'm feeling much better about the community part of Atom, and thoroughly sorry for raising a fuss!
I remember some time ago there was an uber issue on Github for this, but I think I remember seeing it marked as resolved when I can absolutely tell not much has changed (and I have installed barely any plugins). :(
EDIT: I guess I was wrong[0,1]
[0] https://github.com/atom/atom/issues/2654 [1] https://github.com/atom/atom/issues/9572
EDIT: This is even more disappointing after observing that the post author -- "GitHub Campus Expert". What a fantastic example being presented to students.