Atom text editor 1.7.0 released

[sergiotapia]

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.

[pmlamotte]

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.

[robenkleene]

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

[innocentoldguy]

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.

[jarcane]

  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 ...

[mirekrusin]

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

[kalendos]

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

[nickpeterson]

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

[cortesi]

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.

[santaclaus]

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.

[llamataboot]

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.

[shakeel_mohamed]

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.

[sandstrom]

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.

[seanwilson]

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.

[eknkc]

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.

[_Wintermute]

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.

[juli3n]

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

[lowmess]

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.

[untog]

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?

[manaskarekar]

Obvious reason: Open Source vs Closed Source.

All the usual Open vs Closed Source arguments apply.

[Veedrac]

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.

[pram]

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.

[Touche]

Atom isn't abandoned.

[imaginenore]

$70

[erikb]

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

[ywecur]

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

[levemi]

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.

[kennywinker]

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.

[grayrest]

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.

[pugio]

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/

[plexicle]

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.

[cageface]

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.

[taylorwc]

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.

[ApolloRising]

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

[jakswa]

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.

[oneeyedpigeon]

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.

[agentgt]

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.

[connorshea]

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

Also, why do you want that feature?

[thewhitetulip]

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

[tuananh]

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.

[currysausage]

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]

[maxehnert]

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).

[vemv]

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

[rezistik]

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

[l33tfr4gg3r]

I so wish they would fix the FreeBSD build

[kingnight]

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.

[berfarah]

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.

[type0]

Great news!

[terda12]

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