I really like the concept of Atom, but it always feels slow compared to VI. I think it's psychological though, because I can't point to any part of it and say "This is slow".
Now I want to see the results from neovim, or anything with a client/server architecture. I'm surprised emacs is so slow (compared to vim) and I wonder if that explains it.
This is one of the reasons preventing me to switch from Sublime.
The other reason is slowness to open a single file from the CLI, it seems Atom doesnt reuse the already open shell like sublime does, there was a tracked issue for that one.
It's super-slow, and freezes many times more than Sublime.
I like that it's more foolproof, though. Granted it's a product built for developers, it's nice to have a GUI for installing themes and plugins, and for configuring it. This aspect is what keeps me from switching to Sublime.
Yeah it has this weird UI lag, it always feels like using a website rather than an app to me, one of the reasons I always go back to sublime text (3) after trying out releases now and then to make sure I'm not being foolish or missing out on something better. I like the idea that it's open source but I really don't like the idea of it being a heavy javascript app, on my slower laptop you really notice it's memory usage after a short while also.
Atom is my editor of choice due to the Platform.IO extension for IOT development. On my machine, just starting Atom 1.13 involved two interruptions by message boxes saying "Editor is not responding" which had to be closed manually in order to continue with the start-up process. Those annoying boxes have vanished completely with 1.14., so there is some significant performance improvement.
For a while I stuck with Atom because it had a slight edge with plugins, but Visual Studio Code has caught up for what I use(though the Vim plugin is still a bit behind, but good enough) so I made the switch.
I use Atom in Windows and have constant issues with search and replace via selection and large file support. And while these issues are known, I've yet to see a fix.
First line in the post: "Atom 1.14 has shipped today with improved large file performance, a 64-bit Windows installation, improved MRU tab traversal, and more."
> Atom 1.14 has shipped today with improved large file performance
1. Updates to Atom 1.14
2. Attempts to open a 64MB SQL dump in Atom
3. "Atom will be unresponsive during the loading of very large files"
4. Clicks "Proceed"
5. "The editor has crashed"
Yet, I can open the exact same SQL dump in VIM and it displays immediately and I can scroll down with minimal lag. However, smaller files (5-10MB) used to do the same in Atom and now they are fine. So improved, yes. Fixed, no!
For me, however, this still makes the editor untrustworthy. I can't be sure if it's going to take a while to load a large log file or suddenly crash.
23 comments
[ 4.5 ms ] story [ 90.6 ms ] thread> A fundamental component of the text editor called the display layer has been redesigned to rely on a new data structure that is implemented in C++.
Congrats on the release.
Source: https://pavelfatin.com/typing-with-pleasure/
The other reason is slowness to open a single file from the CLI, it seems Atom doesnt reuse the already open shell like sublime does, there was a tracked issue for that one.
I like that it's more foolproof, though. Granted it's a product built for developers, it's nice to have a GUI for installing themes and plugins, and for configuring it. This aspect is what keeps me from switching to Sublime.
1. Opening large text files 2. Some frequent changes in one of the files in the tree being made by a different process
out of the box markdown support is second to none
and if you do Clojure, and like GUIs, proto-repl is amazing.
1. Updates to Atom 1.14
2. Attempts to open a 64MB SQL dump in Atom
3. "Atom will be unresponsive during the loading of very large files"
4. Clicks "Proceed"
5. "The editor has crashed"
Yet, I can open the exact same SQL dump in VIM and it displays immediately and I can scroll down with minimal lag. However, smaller files (5-10MB) used to do the same in Atom and now they are fine. So improved, yes. Fixed, no!
For me, however, this still makes the editor untrustworthy. I can't be sure if it's going to take a while to load a large log file or suddenly crash.