Atom text editor 1.7.0 released | Hacker News Reader

Atom text editor 1.7.0 released

github.com

170 pointsalanfranz139 comments

You know what I would really enjoy? Being able to sign into your Github account and sync your preferences and packages to the cloud. Then if I sign in on a different computer, all my hotkeys, packages and themes are copied over seamlessly.

As a crappy workaround I have this: https://github.com/sergiotapia/atom-meteor-packages

But still, I would like this to be a core integration.

I've since switched to RubyMine and WebStorm because I just want something that meshes together for me, I don't want 'javascript fatigue' in my dev tools as well. RubyMine's built in visual studio-like debugger is killer.

Agreed that this should be built in. I've been using https://github.com/atom-community/sync-settings which stores everything in a gist and has worked out reasonably well so far. The pain points are that you have to manually set it up the first time with the gist id and (optional) private api key, and backups have to be triggered manually.

do you find when you sync-settings:Restore onto a new box, the atom app completely freezes up as it tries to suddenly download all the packages?

You can use `apm stars --install` for the package syncing part of this. It's reasonably close to what you're looking for.

http://blog.atom.io/2014/06/09/stars.html

For me, the Visual Studio-like debugger is killer in theory, but in practice, it hangs a lot and I have to shut down and restart RubyMine.

That sucks, it works flawlessly for me on my El Capitan and RubyMine 2016.1

Do you have a good resource for learning the debugger in RubyMine? I'm still using mostly puts and pry for debugging, but it sounds like the RM debugger could be a win.

http://confreaks.tv/videos/railsconf2015-ruby-debugger-inter...

This is a video by Dennis Ulshakov, the maintainer. I haven't watched this in its entirety but it's only 20 mins.

  cd ~/.emacs.d
  git init
  git add .
  git commit -m "My emacs config"
  git remote add origin http://github.com/myname/myemacsd
  git remote -v
  git push origin master

Just sayin' is all ...

That's not web scale /s

That being said, because I use a different OS every week, I have found this to not work as well as I'd like because I often forget to commit/push after a change.

Since I'm always committing/pushing, it seems to me like keeping ~/.emacs.d in Dropbox is the better solution.

I like to use:

    git push -u origin master

So then the next time all I need to do is:

    git push

That depends on your git.push settings. I have it set to current, which means `git push` pushes the current branch to only an origin branch of the same name.

Maybe auto-discovery for `.atom`-named project?

You can always try to make a Pull Request at see what it comes out!

Doesn't indicate perf improvements... Not trying to troll, but that surprises me given the large number of complaints about performance.

I'm making a bit of a habit of chipping in on Atom performance complaints with a counterpoint. I've now used Atom as my primary editor for more than a year, and I have no complaints about the performance. This could be because I'm using OSX on recent hardware - I've noticed that my friends using Linux desktops seem to have more issues than I do.

Having both Atom and VS Code installed on recent hardware I can say VS Code definitely feels snappier in multiple aspects. It's hard to believe both editors share Electron roots.

And not to make this an X is better than Y comment, but the much better (in my experience) high-DPI handling with VS Code does the same. I wonder what exactly VS Code does to manage to be the only Electron based application that I've used that scales properly across multiple monitors at different DPIs.

> I wonder what exactly VS Code does to manage to be the only Electron based application that I've used that scales properly across multiple monitors at different DPIs.

It's released by a company that has internal controls on making sure released apps are high-DPI compliant.

It's alright for small files, but whenever I paste in a huge csv or json file it hangs for minutes. And I use pretty recent macbook pro with high specs. This doesn't happen with other editors.

I've found that when pasting in huge files, disabling syntax highlighting makes a big difference. In fact, if you simply open a sufficiently large (I haven't bothered bisecting the size, but a few megs works) xml file, Atom will disable syntax highlighting by default and the performance will be slow but still usable. If you paste in the contents of a large xml file, syntax highlighting is not disabled and the editor either hangs or crashes, in my experience.

Atom should automatically disable syntax highlighting for large files.

Reminds me of old emacs' tricks.

For the gaudiest possible look, then, include the line

(setq font-lock-maximum-decoration t)

Same here, I only get issues after around 100MB.

Most editors start to struggle at such file sizes, which is a shame, but try loading 100mb into Excel. The only editor I found to work nearly instantly is vi; nano takes almost a minute to load large files.

Latest Macbook here, opening files up to 10MB is fine but saving after making any change, even a minor one will cause Atom to hang for a few minutes. In contrast, Sublime has no issues. To be fair to Atom, it has no issues with actual code files in any language; it only struggles with log files and csv dumps. This limitation means I use Atom for most things and Sublime for the heavy files.

Even vi is going to bog down on a file that size if you leave syntax highlighting turned on.

Could be, but it could also have not much (nothing?) to do with hardware.

Anecdotal: back in the late 90s, or early 00s, unlike now, the pc hardware got old really fast in terms of performance. Unlike a classmate of mine I didn't keep up with hardware changes. When I bought my hardware and played games they ran really good, but after a while my pc was not fast enough even for low graphic settings, and the games stuttered really strong with fps probably below 30 fps and around the 20 fps mark (only a guess). At first this was horrible compared to the smoothness of playing games directly after buying the new pc, but after a while I got used to it and couldn't understand why my classmate (which kept up with the new hardware that came out) could not stand to play games on my pc. Later I bought a new pc and could play the games with smooth fps again. When I now played games on slow hardware I could not stand it, just like my classmate before.

Maybe this is (in some cases) also the case with people who have no problems with the performance of Atom.

Personally I also find the performance of Atom could be better (on both Windows and Linux) with a 5820k @ 4Ghz, 32 GByte Ram and installed on a SSD (Crucial MX 100/512 GByte). But I only try it from time to time to see how much better it got compared to my previous try.

I've been using Atom as my primary editor for over a year too, on various Linux distros, and it's been a very smooth experience. The only issue I've encountered is Atom can be sluggish with large (4MB+) files because it attempts to load the entire file into memory instead of streaming it like Sublime Text does for large files. Easy solution to it is to just use a plain text editor (gedit being my preference) to view your logs.

> Easy solution to it is to just use a plain text editor (gedit being my preference) to view your logs.

I had a license to Sublime before Atom was even released, so that's what I use :-) I used Atom for at least a year just to support the open source aspect of it (I do spend most of my time in RubyMine these days)

Yeah, I use atom on an mbp 2013 as well as a Linux desktop, and it runs fine. I dont have perf issues, even when opening a large 10k+ line javascript file (a built lib package, when I'm debugging occasionally). Of course, most of my source files are 100 - 1000 lines long.

I have a pretty good computer but atom is pretty slow, crashes often, and all that's with little to no plugins. vS Code on the other hand I've never had crash and handles lots of files with ease.

Tried Atom and it was a real memory hog on Windows - need to go back and try this version, but do enjoy using Caret for lighter touch work that doesn't need a full IDE (or at work where Chrome extensions are allowed, but installs aren't).

Thanks, I installed Caret-T[0], will play around with it. For those not interested in the fork and javascript Intellisense, have look at the caret website[1].

[0]: https://chrome.google.com/webstore/detail/caret-t/agiednhnlg... [1]: http://thomaswilburn.net/caret/

The performance problems on a clean Atom install are incredibly vexing. Microsoft's Visual Studio Code is built on similar foundations and has great performance, so I don't think Atom's performance problems are fundamental.

Yeah, I've been really impressed with how snappy VSCode is.

Visual Studio Code is a totally different foundation. The only shared piece is the Electron shell for embedding Chrome.

That's sort of the foundation though right? The editor built into the electron app is completely different, suggesting that atom is theoretically able to achieve similar performance.

I haven't used visual studio code myself, but does it use a mix of JavaScript and HTML to render and process the text? If so then isn't the major differences the algorithm choices for rendering and editing text?

> Microsoft's Visual Studio Code is built on similar foundations

This is my understanding of things:

- Electron is built on top of Chromium, where the technology was mainly driven by Google and their engineers.

- Vscode is based on Monaco which Erich Gamma and his team spear headed.

- Atom is based on work done by GitHub.

The analogy would be they both use Honda engines, but Microsoft appears to be able to use Honda's engine way more efficiently than GitHub.

No this is pretty wrong. They are both built on Electron which is just the window shell hosted in Chrome. The actual text editors are completely different code bases that have nothing to do with each other.

The better analogy would be they are both built using Honda doors, but they each have completely different engines.

The point is that if Electron itself (i.e. using Javascript and the DOM) was the issue then both would suffer.

You might want to tweak the wording a bit - it reads like you're comparing Monaco to Electron, as if it were another app framework based on Chromium.

Since both VS Code and Atom use Electron as a base, so if the basic premise of using JavaScript + the DOM to render a code editor / IDE were flawed (i.e. it could never be performant), then both systems would be having issues.

This is what I was trying to state. If performance issues were fundamentally tied to the use of Electron, then you would see that manifest itself in both packages.

Oops, I thought you had written sdesol's comment [1]. Sorry.

[1] https://news.ycombinator.com/item?id=11493311

Yeah, Atom is really my favorite editor at the moment in terms of features and add-ons but is totally unusable for me due to various performance issues. Not only does it choke on large files but something like a full-project search can take upwards of 30s to finish while Sublime Text finishes it in about 2-3s. I'd like to switch personally, but I can't until some major performance improvements happen. YMMV.

Yes, search is really slow. But atom-fuzzy-grep is near instantaneous even on large projects. Uses ag pt ack or grep

https://atom.io/packages/atom-fuzzy-grep

The nice thing about Atom is that you can replace anything that isn't performing.

What kind of computer and OS are you using?

Late 2013 Retina MBP w/ 16GB of RAM

Unless you tell someone your OS and hardware, it's really not helpful for people to decide, or even address the problems.

Does Atom use a lot of ram or cpu? I've got a 2 year old Mac Book Pro with 16 GB RAM and an SSD. I downloaded Atom 1.6 after the announcement and leave it open to maintain my notes and I haven't noticed any performance problems with a couple dozen files. I might try to use it for another project once I evaluate the plugins.

You shouldn't need a $2000 laptop to run a text editor.

No one said you did. I simply stated what I owned and explained how I use it, and how it performed.

I imagine the same performance as my 2 year old laptop is equivalent to $500-$800 desktop today.

But you will most likely have it anyway.

Speak for yourself. My primary computer is a $200 laptop.

ok, try Atom and report back. The guy who was complaining had projects of several thousand files, some of which were 50,000 line xml files.

yes, I have a few thousand files, some of them are 50k+ line XML files. Sublime still searches my full project in many magnitudes of less time that Atom does. I use Atom for my small toy projects as well.

I don't know when the perf improved, but it definitely has recently. In the past month I downloaded Atom on OS X (for the third time) to see if the perf had improved and I was impressed! I added a huge project's folder and indexing was done insanely fast (iirc less than 30 seconds). I don't really have a need for Atom at the moment since Sublime Text exists, but I might recommend it for new programmers since it's free + hackable.

I think it's gotten much better this year. It used to be somewhat slow (especially on large files), but it's alright now. Still room for improvement though.

Many devs could get a faster computer, too. I'm considering getting a Surface Book.

I've been using Atom for over a year and haven't had any major performance problems. Luckily for me I don't have to regularly access code files that are megabytes long but I can see why not being able to do so would be annoying.

They had decent performance improvements in recent major releases. It's pretty good now, except for the initial boot time. Takes ages to launch it. But after that, runs smooth on my laptop.

Is Atom still collecting users data? Last I paid attention there was a big furore about having to opt-out and the legality in Europe.

Yep, but you can disable it by disabling the 'metrics' extension.

That's _after_ the first launch, correct?

Not necessarily. You can set the property in your ~/.atom/config.cson before the first run.

https://github.com/Couto/.dotfiles/blob/master/tag-atom/atom... in case you need an example

Example is appreciated, but not accessible. I personally use Little Snitch and stopped Atom from phoning back to Google Analytics, as I do with all the apps I use, but the comment I was replying to seemed to be shrugging off the data collection by saying "just turn it off" when the truth for most people is "it'll do it at least once but you can turn it off later"

It auto launches after installing in Windows.

Couldn't you just disconnect from the web until Atom was installed and metrics are disabled?

This is why I set windows firewall to disable connections by default and then opt programs in. Visual Studio tries to connect to the internet too.

So the metrics collection is ON by default?

Am I the only one who has no performance issues with Atom, except on insanely big files? I don't like my files to be 1000+ lines anyways (where possible) because it severely impacts readability/skimability.

ST3 might win me back when Package Control is integrated, but until then, Atom is more than fine. IntelliSense on VS Code looks really powerful, but it's personally a feature I do not enjoy.

Genuine, non-trolly question: why would I use Atom over Sublime Text?

I've used both and by and large they were very effective replacements for each other, but Atom had performance issues with large files so I went back to Sublime. What am I missing out on?

Obvious reason: Open Source vs Closed Source.

All the usual Open vs Closed Source arguments apply.

Atom has a much better extension API, which can do a lot more. Here's a quick list of cool uses of the API:

    https://atom.io/packages/hydrogen
    https://atom.io/packages/merge-conflicts
    https://atom.io/packages/minimap
    https://atom.io/packages/color-picker
    https://atom.io/packages/markdown-preview-plus
    https://atom.io/packages/preview-inline
    https://atom.io/packages/pdf-view

If you don't utilize the API, IMO Atom is just a noticeably slower, slightly prettier version of Sublime Text.

I used Sublime for 6 years (I migrated when TextMate was obviously dead) and am just recently attempting to switch to Atom. The package manager is fantastic, and the git integration is very nice as well. It's much better now than when it first came out. It can be very sluggish though.

That said, it's missing two very important features from Sublime that I used constantly. First, you can't use it like a scratch pad like Sublime. In Sublime you can open a file, write stuff to it, and it will be persistent. Atom seems to have an option to save your current work, but can't be used this way from my experience. The second is it doesn't have multi-select like Sublime. You can't drag your mouse and have a bunch of different carets. That was TextMate's killer feature imo, and Sublime as well.

Atom isn't abandoned.

And neither is Sublime Text. There was a new dev build released just today and there have been new builds every week or so this year.

$70

Really? If you're a programmer you probably spend 6-16 hours a day in your text editor. An artist pays $120+ a year for Photoshop. They don't generally settle for gIMP. The 2 are barely comparable. Similarly construction workers don't use tools from the 99¢ store.

If you value your time you shouldn't look at a few hundred dollars as the difference between using some software and not. That software is a force multiplier.

I'm not saying sublime text is better than atom. I'm only saying that price should not be the reason to choose something you use several hours a day.

You're kind of missing the essential part of alternatives here, and that argument also is a slippery slope. With the same logic, it might make sense to spend thousands of dollars on something you use for your job the majority of your day. Besides that though, yes, I agree it would make sense to spend $70 on a text editor that you use every day for many hours a day, but only if it is the single best option on the market. If someone believes that Atom is equally good, then no, it is not worth it to spend $70 on sublime text.

True. I'd honestly forgotten that I paid for Sublime Text all that time ago.

I wish one could flag questions. This discussion was done in hundreds of Atom related HN threads. Please look them up.

For you Atom users: Why have you chosen Atom over, say, Emacs?

Not sure if you're trolling, because that's a pretty ridiculous question. The obvious answer is Atom's immediate usability and the much easier learning curve over Emacs which requires an incredible amount of research and effort to set up properly and use.

For example how long do you think it takes for the average new programmer choosing Atom to figure out and learn to use the fuzzy file search versus them getting that working on Emacs? Seconds versus hours I imagine. It took me a non-trivial amount of time to set that up on Emacs.

Alright, so say they use Spacemacs (Which really should be the Emacs default). Now how would they justify their choice?

I downloaded and tried Spacemacs out of curiosity, after seeing your comment.

While I'm sure it adds a lot of usability features compared to the default Emacs config and it looks pretty cool, it's nowhere near as immediately accessible as Atom or Sublime - for example, I have no idea how to close an open file without Googling whereas in Sublime or Atom it's either click the "X" or use the standard Cmd-W shortcut. I also have no idea how to open a project or search for a file, and don't really know where to start discovering those things, whereas in both Sublime and Atom you can browse through the menus, or hopefully quickly discover the Cmd-P command launcher which lets you type a command.

If I wasn't somewhat familiar with Vim, I would have absolutely no idea what was going on as by default it uses Vim's modal keybindings. I also noticed an annoying lag when pressing spacebar to bring up the command list thing - slower than any lag in Atom!

It does look intriguing and I'd love to learn to use it more, but I don't think you can really say the usability of Atom/Sublime and of Spacemacs to a new user are anywhere near equal, never mind "how would they justify their choice?"!

Quick reply to address your issues:

- the binding menu idle time is configurable with the variable `dotspacemacs-which-key-delay`, check the docstring.

- The key binding you missed (should be listed in the quick start guide) is `SPC h SPC` which is used to find various info like FAQ, layers, packages config, dotfile variables etc... try it for yourself: `SPC h SPC which-key` and choose `dotspacemacs-which-key-delay` then RET, you can now modify its default value of 0.4sec to 0.

- `SPC :` to access _all_ interactive commands of Emacs (`SPC SPC` in develop, shortcut configurable of course).

- to discover how to close a window just press `SPC` then look for `window` and so on, it takes 10 seconds to discover it ;-)

- If you were not familiar with Vim you can choose to opt for Emacs key bindings and `SPC` becomes `ALT-m`, everything else is the same. But you are familiar with Vim so I don't see what issue you want to raise.

Thank you for trying Spacemacs :-)

Thanks for the detailed reply, very helpful :)

I wasn't trying to raise an issue at all, merely state that Spacemacs isn't as obvious to a new user as Atom - but I'm not saying that that's a bad thing, obviously (Spac)emacs has a lot more power under the hood potentially and I am sure is worth the additional effort to learn.

I have to say I'm impressed with what a good job you have done of making it user friendly :)

>I have no idea how to close an open file without Googling whereas in Sublime or Atom it's either click the "X" or use the standard Cmd-W shortcut.

You can just use the menu bar for that.

>I also have no idea how to open a project or search for a file, and don't really know where to start discovering those things, whereas in both Sublime and Atom you can browse through the menus, or hopefully quickly discover the Cmd-P command launcher which lets you type a command.

You can, as it tells you, use the fuzzy command search by typing M-x. Same as Atom, just a different command.

Honestly, and sorry for sounding rude, to me it just seems like you intentionally tried to not understand in order to prove a point; Just because in your mind you have this idea of emacs just having to be inferior in some way.

As it stands though, it's not.

> Honestly, and sorry for sounding rude, to me it just seems like you intentionally tried to not understand in order to prove a point; Just because in your mind you have this idea of emacs just having to be inferior in some way.

Not at all and I didn't mean it to come across in that way, apologies if it did. Thanks for pointing out those things - I actually for some reason didn't think of using the menu bar at all, I guess because it looks like a non-GUI app. That's my fault anyway!

I was just interested in the "absolute newcomer" user experience, as that is how a lot of people will judge things, which for me after a few minutes was "I can't work out how to do what I need to do" and so I stopped. I'm sure that with an hour or so playing around, I would get used to it, and I intend to!

A text editor is a tool. I don't think accessibility matters that much - it's something that can and should be sacrificed for improved efficiency of working with said tool. You spend 5 minutes Googling up (oh, omg, reading the built-in manual or running the tutorial that happens to be shown pretty much on startup) how to do some things and now you can do those things much more efficiently than by clicking around "discoverable" menus and toolbars.

I was a happy spacemacs user for a while, but my install kept getting broken by updates. Atom has never just fallen over dead like that.

After quite a while it was still mysterious to me how to change simple things or to even trace where certain behavior was implemented. (that can be a problem in Atom too).

In short: I didn't have the time. I have a lot of work to do, no time to fiddle.

I still miss a few things from spacemacs.

helm-swoop mode is awesome. That could be done in Atom.

I'd like a <SPACE>-x-y command interface for atom. Proton seeks to achieve that: https://github.com/dvcrn/proton

I'd love to be able to handle panes with the agility of Emacs.

I don't understand your reasoning here.

>my install kept getting broken by updates. Atom has never just fallen over dead like that.

Could you elaborate on that? This has never happened to me. If this happened because you wrote a bunch of custom layers then I'd argue that it's a non issue because in Atom you cannot do that at all (or at least experience the same problems if you do)

>After quite a while it was still mysterious to me how to change simple things or to even trace where certain behavior was implemented.

As you stated, the same is true for Atom.

>In short: I didn't have the time. I have a lot of work to do, no time to fiddle.

Time for what? The superior modification capabilities in Spacemacs by no means force you to fiddle. It seems to me that all your problems were caused due to you not being able to stop yourself to fiddling with the very sane and good defaults.

This is similar to the argument I see about people who switch to an iPhone all the time. "I just didn't have time to fiddle. I wanted my phone to just work." So just don't exercise your freedom to fiddle then! The defaults in both cases are just as sane and if you some time in the future need to customize something for the sake of productivity, the you can!

Sound to me like somebody moving to China from the US because they "Didn't have time to participate in politics anymore."

Uh... additionally I'd like to add that anytime I discuss problems that I had with Spacemacs I was treated to this kind of blaming and argumentative tone.

Sorry, my intention was to try to help you, not offend you :(

> panes

https://atom.io/packages/atomic-emacs

I use vim-mode. I do have key commands to move panes around, but it's not as immediate and pleasurable as Emacs or Vim.

> how long do you think it takes for the average new programmer

If they're taking advantage of Google, a few seconds for either one. Discoverability in both kinda sucks.

It does not take a few seconds to get fuzzy search working on emacs in any shape or form. You have to add an addon like helm or icicles to get anywhere near atom's functionality. And you have to learn how to get addons to work. It works without an add on in Atom, and you don't need to do a Google search to figure it out.

I actually hate Atom and I resent you making me defend it. >:|

You could just use something like https://github.com/syl20bnr/spacemacs/ and have working fuzzy-search out of the box (with VIM-like key bindings if you like)

spacemacs bro

Atom and Emacs are so different I don't think it's worth it to provide reasons for one or the other. Vim/Emacs/etc vs. Sublime/Atom/etc are simply a matter of which type of editor you prefer or need for a particular purpose (classic vs. modern, GUI-based vs. usable over ssh, and many more giant differences...)

For me, it is feeling like part of my OS. I have to use a whole bunch of other Mac apps, and Emacs (or vim) don't fit in. Mouse cut+paste is dodgy, and they use a whole bunch of different shortcut keys (I just instinctively type apple+s for save, apple+f for find, etc).

There seems (based on other users I know) two sweet points -- put your whole life in emacs, and give the other apps you have to use Emacs shortcuts, or no Emacs.

Some people's brains might find it easier to switch between two sets of shortcuts when switching between apps of course.

The handling for modern Javascript development tools is superior than any other editor I've used, Vim and Emacs included unfortunately. I use Vim for everything, except JS development. For that I use Atom.

Have you tried brackets+theseus? I've heard it's quite good for js.

Have you used VS:Code? If so, what do you prefer about Atom for JS development?

I find the JS intellisense, while heavily dependent on what kind of code you write, leaves every other editor standing.

Flow type integration. TypeScript in VS:Code is better, of course, but for Flow or Purescript Atom leaves it in the dust unfortunately

What plugins do you use for JS?

As Javascript is Atom's native language, support for JS is very good to start with.

Have a look here for additional plugins: https://atom.io/packages/search?utf8=%E2%9C%93&q=keyword%3Aj...

Anything with more than 10K users is likely to very useful.

I've been using Visual Studio Code a bit this past month and there is a lot I like about it. Anyone have thoughts on Code vs Atom? I know Code is based on Atom, but I'm not really clear on how they differ

edit: correction. After asking this, I read up a bit and Code is based on Electron which is the core of Atom, but they're fairly different after that.. Code is not a fork of Atom as I thought it was.

Code is not based on atom, it's based on Electron, which is the runtime (node+webkit without the UI chrome).

VSCode has lower typing latency and a more considered system for building / debugging / code completion. Atom has a richer plugin api and has been around longer so it has more plugins. I've done basic plugins for both and plan on using/developing for VSCode but I've been too lazy to write Vim bindings and not willing to use the editor without them.

You may want to try my vim extension for VSCode - amVim. It works best on VSCode's insiders build now. I'm planning a big update as soon as VSCode releases 1.0(which is said to be 4/14)

Thanks for making amVim. It's the only usable vim extension right now. It's a shame you aren't being featured on the marketplace

Glad you like it. I'm using it everyday at work. I implemented all commands I use regularly and make sure they work well.

Nitpick, Electron is Node + Chromium (not webkit).

Visual Studio Code is NOT based on Atom, it is based on Electron[1], a wrapper around V8/Node for the creation of desktop apps. Atom is also based on Electron (and the Electron project is run largely by the Atom people), but other than that the projects use entirely separate code bases, and have vastly different feature sets and performance profiles as a result.

[1]http://electron.atom.io/

Code is noticeably faster than Atom on both my Linux and Windows machines.

While that's my personal experience, it matters the most to me. Makes the decision easy... for the moment.

Code seems nice but the plugin ecosystem seems much richer. I depend a lot on the linters available for Ruby and JS in Atom and they seem much less mature in Code.

I like both. VS Code does indeed feel significantly snappier, but I really love the tabbed view on Atom, and Atom's plugin ecosystem is more developed as of now.

Quick question: Does anyone know why a basic thing like printing seems to not be included in the default atom app?

Is your printer one of those combo printer + fax machines? You can copy/paste the code you want to print into an email, email it to a computer with a fax connection, and then fax it to that printer.

I was going to suggest telephoning it in to someone with a tablet, have them transcribe it into a note taking app, scan the tablet with your personal scanner and then print the scan from your original computer using the photo printing tool.

You forgot the step where someone needs to make a hand written copy, which is then translated to Hungarian and back. But I understand you, it's an easy step to miss.

HP Laser Printer (Not Combo) nothing fancy.

Pure conjecture: someone worked out that the use case for printing out your code is incredibly rare? I don't think I've done it for several years, and if that's widely representative, I strongly support removing it from the core application.

Funny thing is I sort of like how many many apps do not override ctrl/command p and respect it.

Almost every editor I use I use the print commands (ctrl/command p + some other keys) as my global personal short cut chain.

That way I have the same short cuts for intellij, eclipse and even emacs (sadly remapping the default ctrl-p).

Some recent editors though don't respect leaving ctrl/command-p alone (sublime, atom, vs code) which means I have to override what is there. Which sort of pisses me off... they found my secret unused keys ... damn them :)

Worse though are editors that do not even allow you to override ctrl/command-p but I have yet to see those.

Have you opened an issue about it? They may not realize anyone would even want that feature.

Also, why do you want that feature?

For printing code, obviously. Personally, I do that when doing big refactors on some module I didn't write (or wrote it so long ago I don't remember much), or basically when I can't focus. I actually learned that from 'edw519, who summed up my worries about paper use with "Paper is cheap. Focus is golden.".

I recently used enscript [1] to create pdf's from code, can recommend.

[1] https://www.gnu.org/software/enscript/

I wonder why they have not fixed the performance issues in Atom. VSCode is based on Electron yet it is blazingly fast than Atom.

The most important thing about Atom is probably the community around it. TextMate is also opensource yet I haven't seen many plugins built for it.

Plugins and users are big part of what make Atom great.

Without further comment: remove_atom_from_context_menu.reg

  Windows Registry Editor Version 5.00
  [-HKEY_CLASSES_ROOT\*\shell\Atom]
  [-HKEY_CLASSES_ROOT\Directory\Background\shell\Atom]
  [-HKEY_CLASSES_ROOT\Directory\shell\Atom]
  [-HKEY_CURRENT_USER\SOFTWARE\Classes\*\shell\Atom]
  [-HKEY_CURRENT_USER\SOFTWARE\Classes\Directory\Background\shell\Atom]
  [-HKEY_CURRENT_USER\SOFTWARE\Classes\Directory\shell\Atom]

They hijacked the way you open files now and from what I can see reading through release notes and commits there's no way of opening a file permanently without double clicking.

With preview mode enabled I have to dbl click the tab and with it disabled I have to dbl click the file name. It would be nice if opening a file had regular single click functionality when preview mode was disabled. Or maybe another setting for this in the config.cson file.

It seems like a trivial thing to complain about but it's usually the small things like this that are the most annoying (for me at least).

Here's the PR for that https://github.com/atom/tree-view/pull/804/files

It's in settings. You can disable preview panes. Agree it was annoying.

I still have to double click on the tab to get the italics to go away like the op said. Do you not have to do that?

I so wish they would fix the FreeBSD build

Atom really should save all buffers instead of just project-linked ones. There's too much opportunity for data loss as it currently is and it removes the ability for the text editor to double as a scratchpad or quick notepad.

I'm unreasonably excited about `do` `dop`'s order being changed. I didn't realize that's what had happened in an earlier release, and writing blocks in Ruby has just been ever so slightly annoying.

Great news!

Still not gonna use it because it's just laggy.

Reply on news.ycombinator.com