Switching to Atom from Sublime Text


I need a few things to consider switching from Sublime to Atom:
Tab autocomplete,
Good highlighting for .conf files,
I need it to open 5mb+ files as quick as sublime,
The shortcuts(equivalent):
Highlight multiple lines then command + shift + L to separate into lines,
Control + shift + W to wrap things in a tag then type that tag out, such as ‘< div>’

Can we confirm that these things, close enough, or better exist?

  • Tab autocomplete - done … whether or not there is an autocomplete provider for the kinds of things you’re working on might be another story
  • Good highlighting for .conf files - I’m not sure what those are, can you give me an example?
  • Open 5mb+ files as fast as Sublime - Isn’t there and may not be for a while (actually, this is kind of complicated … do you mean from the command line without the editor already open? or what?)
  • Shift+Cmd+L - Same keybinding in Atom does the same thing
  • Wrap things in a tag and stuff - Packages exist for that (I don’t use them though, so I’m not the best person to pick suggestions)


Here’s an example of .conf highlighting https://dpaste.de/PRcc
No, I mean when I open a 5mb+ file in sublime, it opens immediately and i can scroll down as fast as I want(this is huge for me and a lot of people i know)
What is the most popular package to do the code wraping thing?

  • I couldn’t find a package that specifically stated it covered conf files but I only looked for a couple minutes
  • If the utmost in performance is a high priority for you, then Atom is probably not the editor you’re looking for
  • As I said, I don’t use that feature … so I don’t know

You can always search the list of packages at https://atom.io/packages.


Thank you, Lee
You’ve been very helpful and informative.


The atom-tag-wrapper package by tehapo will allow you to wrap selections in tags:

The default keybinding is alt-shift-W, but you can change it to ctrl-shift-W with your own keybinding.


Aw man, this would have been better than Emmet’s alternative if it didnt do this
<div class=">fdsafadfsad</div class=">
looks like this one is better


Oh, crap! Sorry, I never realized it did that. Yeah, that’s a no-starter. The one you suggested is better. Although, it doesn’t look like you can change the keybinding.


That is invalid code. There is an unmatched quote. Is that what was generated or did you type it?


I believe that is a demonstration of what happens if you try to type attributes in the new tag with the former package.


redbassett, correct


There’s a package here (by @leedohm, actually) that does basic highlighting for .conf files: https://atom.io/packages/language-generic-config

There are also more specific packages for different kinds of config - there’s a nginx one, and Apache one, etc…




All my package does is differentiate between comment lines and non-comment lines. It seemed like @dannymichel was looking for something more.


Is this still, and will this always be the case? Seems like something atom devs should work toward, no?


It is still, yes. Will it always be the case? I don’t know.

What is it you’re suggesting the Atom devs work toward? Your question is unclear.


Making Atom faster(at least as fast as what we’re used to) and handling large files as well as other apps is something Atom devs should work toward.


Making Atom faster and able to handle large files is something that the dev team is working towards, yes. We’ve made a lot of progress in that regard. Performance is a higher priority than handling larger and larger files.


One thing I’ve been thinking about lately is that it would be nice to have configurable wait times for loading packages. As an example, the Remote FTP package adds 1251ms to my startup time when I have it on. If I never need it when I start Atom, this is excessive. I can go and enable it manually, but having to do that every time I want to use it would be tedious (and then if I forget to disable it or I have a crash, it’s still on the next time I start Atom). If I as the user could say, “I don’t want you to load this package until you’ve gotten everything else up and running,” that would be a fire-and-forget solution that would cut 1.2 seconds off of the loading time and move that work to a point in time where Atom isn’t really doing much.


Maybe an even more effective way to handle this could be to defer the action of even loading a package to the first time it’s used. But it possibly would depend on how a package is written: for instance, to achieve this, a package might need to consist of a fast loading “stub” file (e.g. to define menu entries and key bindings) and a heavier library with all the bells and whistles. I don’t know much about Atom packages, maybe there is already the possibility to write a package in such a way, and in this case some good guidelines on how to do it could be a good starting point.

Of course this wouldn’t apply to all kinds of package, but many - such as the one you mentioned - could be good candidates.