I also would like to say about big files. Generally speaking both editors have acceptable speed. But this is also can be applied to Emacs. Atom is slow because of the platform it is being written at, and maybe because some packages are not well written. Emacs usually because it's ELisp machine is not very fast, and garbage-collection may slow you some times. What I mean, is that bot Emacs and Atom have some problems with speed. Atom is pretty fast though, and Emacs is too. And even if it is possible, web based interface is much more responsible for such thing.Ītom is slow, Emacs is also slow.
I don't think that it is possible to do something like what Hydrogen does in Atom by using just plain text and images. Emacs still can compete by using something like this, but it's not the same. This means that Atom has a first class rendering engine that is capable of anything, modern browser is. If we compare Atom and Emacs further than just comparing the approach, you get some more points to reason with: Want another tabs? Write your own tabs that you will like! This extends to any editor feature, much as Emacs does. Atom on the other hand can be changed pretty wildly - Don't like tabs? It's a package, turn it off. Though VS Code can also be extended by packages, there are less possibilities, because Microsoft has a view on how VS Code should look and operate.
Sure, Atom lacks some features, like major-minor mode distinguishing, but it wraps this to packages still pretty nicely.
everything is a package that can alter editor behavior how it needs to. Well if you can put it that way.Ītom uses kinda the same approach as Emacs does - e.g. If you know difference between VS Code and Atom than perhaps you know difference between VS Code and Emacs.
0 kommentar(er)
