5 ms·

Atom 1.24

96 points by seanwilson 9y ago

SquareWheel 9y ago
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
- dang 9y ago
  OK, we'll change to that from https://github.com/atom/atom/releases/tag/v1.24.0 https://github.com/atom/atom/releases/tag/v1.24.0.
mavhc 9y ago
If only the Windows version had a normal msi installer that installed it in a normal place so it worked properly with multiple users.
- jimnotgym 9y ago
  It's worse than that, it generates paths so long that it sometimes fails to install with a 'path too long' exception.
jakear 9y ago
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 https://github.com/atom/flight-manual.atom.io/pull/374
croshan 9y ago
I think the last time I saw an Atom post on here (a blog post), it ignored VS Code, and here we've got a very minor focus on responsiveness/performance. I'm mostly reminded of Brackets, https://github.com/adobe/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.
jpmoyn 9y ago
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.
spiderfarmer 9y ago
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.
- ricardobeat 9y ago
  Maybe you should care, since it's the other way around - VS Code is simpler and much faster, Atom is the heavy one.
  - dawnerd 9y ago
    I disagree. VS Code does quite a bit by default.
    - Froyoh 9y ago
      I disagree. VS Code is much smoother in that regard.
  - petre 9y ago
    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.
    - h_r 9y ago
      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.
      - deleted 9y ago
        [deleted]
mandazi 9y ago
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.
alissasobo 9y ago
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_sitter.mp4 https://ftp.osuosl.org/pub/fosdem/2018/UD2.119/code_tree_sit...
- castis 9y ago
  And if it's truly better, the rest of them will pick it up eventually.
hartator 9y ago
> Right-clicking no longer locks up the event loop! I think I've never noticed it was blocking. Great work.
plg 9y ago
Is it faster yet
ngrilly 9y ago
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.

96 points by seanwilson 9y ago

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

dang 9y ago
OK, we'll change to that from https://github.com/atom/atom/releases/tag/v1.24.0 https://github.com/atom/atom/releases/tag/v1.24.0.

mavhc 9y ago

If only the Windows version had a normal msi installer that installed it in a normal place so it worked properly with multiple users.

jimnotgym 9y ago
It's worse than that, it generates paths so long that it sometimes fails to install with a 'path too long' exception.

jakear 9y ago

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 https://github.com/atom/flight-manual.atom.io/pull/374

croshan 9y ago

I think the last time I saw an Atom post on here (a blog post), it ignored VS Code, and here we've got a very minor focus on responsiveness/performance. I'm mostly reminded of Brackets, https://github.com/adobe/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.

jpmoyn 9y ago

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.

spiderfarmer 9y ago

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.

ricardobeat 9y ago
Maybe you should care, since it's the other way around - VS Code is simpler and much faster, Atom is the heavy one.
- dawnerd 9y ago
  I disagree. VS Code does quite a bit by default.
  - Froyoh 9y ago
    I disagree. VS Code is much smoother in that regard.
- petre 9y ago
  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.
  - h_r 9y ago
    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.
    - deleted 9y ago
      [deleted]

mandazi 9y ago

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.

alissasobo 9y ago

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_sitter.mp4 https://ftp.osuosl.org/pub/fosdem/2018/UD2.119/code_tree_sit...

castis 9y ago
And if it's truly better, the rest of them will pick it up eventually.

hartator 9y ago

> Right-clicking no longer locks up the event loop! I think I've never noticed it was blocking. Great work.

plg 9y ago

Is it faster yet

ngrilly 9y ago

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.