Atom 1.24(blog.atom.io)
blog.atom.io
Atom 1.24
http://blog.atom.io/2018/02/13/atom-1-24.html
27 comments
Tree-sitter is impressive. When it's fully implemented, no other text editor in existence today will have the parsing capabilities of Atom.
Max Brunsfeld gave a talk about Tree-Sitter at FOSDEM 2018. You can check it out here.
https://ftp.osuosl.org/pub/fosdem/2018/UD2.119/code_tree_sit...
Max Brunsfeld gave a talk about Tree-Sitter at FOSDEM 2018. You can check it out here.
https://ftp.osuosl.org/pub/fosdem/2018/UD2.119/code_tree_sit...
And if it's truly better, the rest of them will pick it up eventually.
Seems like everytime there's a post about Atom, people keep talking about alternatives like VS Code.
I like Atom exactly for what it is. Simple at its core, very customizable, fast enough for regular use and under active development. Maybe other editors can do the same or more, but I don't really care.
I like Atom exactly for what it is. Simple at its core, very customizable, fast enough for regular use and under active development. Maybe other editors can do the same or more, but I don't really care.
Maybe you should care, since it's the other way around - VS Code is simpler and much faster, Atom is the heavy one.
Privacy Policy for VS code makes me glad that Google doesn't own it. With so many people mentioning it here, I decided to look it up, looks nice. The privacy policy links to an actually nice and extra thoughtful, 'opens your eyes to all kinds of different scenarios where microsoft gets your data" kind of thing, which was surprising and pleasant.
However broad the policy shows people various things with different products, it basically doesn't say much of anything about vs code, and starts discussing enterprise environments are situations in which you need to talk to your enterprise admin about privacy stuff, yada yada.
Going back to the vs code page, it says they use telemetry and crash dump reporting. It does say that users can follow a link for info about turning off crash reporting.
I am not sure what the exact definition of telemetry is, and if it varies from company to company. After seeing that MSoft was sucking in every keystroke typed on a windows machine, and having a terrible experience with UN-removable one-drive with an office 201X install, I've lost faith in what Msoft has become, and trust them less than free products from google.
Maybe there is some way to run vscode in a VM that is 100% blocked from the internet and that would prevent it from sending tons of data?
Maybe I am missing something this early and no coffee yet.
However broad the policy shows people various things with different products, it basically doesn't say much of anything about vs code, and starts discussing enterprise environments are situations in which you need to talk to your enterprise admin about privacy stuff, yada yada.
Going back to the vs code page, it says they use telemetry and crash dump reporting. It does say that users can follow a link for info about turning off crash reporting.
I am not sure what the exact definition of telemetry is, and if it varies from company to company. After seeing that MSoft was sucking in every keystroke typed on a windows machine, and having a terrible experience with UN-removable one-drive with an office 201X install, I've lost faith in what Msoft has become, and trust them less than free products from google.
Maybe there is some way to run vscode in a VM that is 100% blocked from the internet and that would prevent it from sending tons of data?
Maybe I am missing something this early and no coffee yet.
> Maybe there is some way to run vscode in a VM that is 100% blocked from the internet and that would prevent it from sending tons of data?
Wouldn't these user settings be enough?
Wouldn't these user settings be enough?
"telemetry.enableCrashReporter": false,
"telemetry.enableTelemetry": false,VS Code completely messed up our commits when using it in macos because it did not update open files. We threw it away and never looked back. I'm using Atom now, was using Sublime for about four years.
I wonder how most people work with their source control system. In general, I find it far easier to use git or svn from the command line because when I'm bouncing around between editors and OSes, it's always the same user experience so you get to leverage that experience better. Works for me anyway.
I’m using Vs Code pretty much exclusively for git commits. The reason is that it really quickly lets me review all my changes als diffs before committing. From time to time I find some stuff there which I added for debugging but which shouldn’t be pushed. I don’t think watching diffs in the console is a great experience. And other IDEs always felt more heavyweight in that regard.
> I don’t think watching diffs in the console is a great experience
Depends on the console and on what you're used to. If you can maximize it in full screen and especially if the diffs are colored like git's, then it's a very pleasant experience.
What I like about Atom is that it's not an IDE. It's an editor. If you want it to be an IDE, then you can add language specific plugins that turn it into an IDE. Even the integrated git/github plugin is useless to me because we're using fossil. In contrast, VS Code comes packed with features for Js/Ts which make it an IDE rather than an editor.
Depends on the console and on what you're used to. If you can maximize it in full screen and especially if the diffs are colored like git's, then it's a very pleasant experience.
What I like about Atom is that it's not an IDE. It's an editor. If you want it to be an IDE, then you can add language specific plugins that turn it into an IDE. Even the integrated git/github plugin is useless to me because we're using fossil. In contrast, VS Code comes packed with features for Js/Ts which make it an IDE rather than an editor.
[deleted]
We're also using it from the command line. I at least expect the text editor to warn you when a file has changed on disk and you try saving over it as Vim or Micro do or to reload it automatically like Atom and Sublime do, as opposed to happily continuing to use the old version and allowing you to save it over the update without any warning, like VS Code <= 1.18 for macOS does.
Try VS Code. It works well out of the box, plugins are easy to install, it's faster than Atom, and very actively developed, with major feature releases coming out every few months.
The customizability specifically is key for a lot of people. I maintain an Atom package for finding and opening files by path in a similar way to Emacs' find-file, and at this point I can't really go back to not having something similar. I tried looking into how I'd implement a similar interface in VSCode and couldn't find any UI primitives that would have worked.
There's a definite performance cost for this customizability, but I'm willing to pay for it.
There's a definite performance cost for this customizability, but I'm willing to pay for it.
Before using VS Code, Atom was my favorite editor, but I don't think I can go back to it. VS Code is just simply amazing.
I like the idea of tutorials for generating language grammars [1]. I've made a couple grammars myself for both Atom and vscode and I can never find as much info as I'd like. For instance, what labels should various tokens get in order to have them show up as the proper semantic constructs in syntax themes? Last I checked, it was difficult to find a reference of what "standard" syntax themes recognize, and I ended up just looking through the source of existing themes for labels to try.
Going beyond a tutorial, what could be really cool is a GUI where someone can paste in a code snippet of a language they want to colorize, then manually go through tokens classifying them as literals/keywords/whatever. Making a proper grammar for an entire language just to get some basic colorization gets old fast.
[1] https://github.com/atom/flight-manual.atom.io/pull/374
Going beyond a tutorial, what could be really cool is a GUI where someone can paste in a code snippet of a language they want to colorize, then manually go through tokens classifying them as literals/keywords/whatever. Making a proper grammar for an entire language just to get some basic colorization gets old fast.
[1] https://github.com/atom/flight-manual.atom.io/pull/374
I used atom as my text editor exclusively for over a year, but when I started coding in TypeScript I reached for VS Code and haven't looked back.
Atom used to feel slower than VSCode, but I gave it another try and it feels more responsive today. I even wonder if it doesn't feel faster than VSCode.
One thing I like very much in Atom, and I miss in VSCode, is the ability to amend a commit: you check "Amend", your commit is displayed, you do your changes, you click "Commit", done.
One thing I like very much in Atom, and I miss in VSCode, is the ability to amend a commit: you check "Amend", your commit is displayed, you do your changes, you click "Commit", done.
> Right-clicking no longer locks up the event loop!
I think I've never noticed it was blocking. Great work.
I think I've never noticed it was blocking. Great work.
Post links to the Github releases, but here's the announcement post.
http://blog.atom.io/2018/02/13/atom-1-24.html
http://blog.atom.io/2018/02/13/atom-1-24.html
OK, we'll change to that from https://github.com/atom/atom/releases/tag/v1.24.0.
Is it faster yet
I'm mostly reminded of Brackets, https://github.com/adobe/brackets, which I moved away from as a general-purpose text editor, but still seems solid for specifically doing frontend development.
Everyone focuses on Atom as a general-purpose editor, and its performance isn't so great in that regard, but if it focused on a specific area, it would be something I might consider using again. It feels easier to have editors for different things, than manually enabling different sets of plugins, for different projects.