Switching to Atom from Sublime Text


#4
  • 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.


#5

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


#6

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.


#7

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


#8

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.


#9

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


#10

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


#11

redbassett, correct


#12

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…


#13

Nice
Thanks


#14

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


#15

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


#16

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.


#17

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.


#18

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.


#19

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.


#20

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.


#21

#22

While package maintainers can and should optimize their code, some packages are always going to be beefy. You’re never going to have snappy load times with Nuclide installed, even if they did a big optimization pass and cut its load time in half (the machine I have Nuclide on reports 7935ms).


#23

Of course some packages, especially the ones that actually enrich the editor a lot - possibly transforming it into sort of an IDE - will be beefy. But if these beefy packages could load (actually load from the disk, with the require() part and all, and then initialize) some parts of their functionality at the time they are needed, maybe the user experience could be better: the load time of Atom could be reduced to 4s in the specific case and the remaining 3.935s could be split in chunks that would be barely noticed in interactive use. If the “stub” paradigm were used, maybe load time could be reduced even further.

I didn’t inspect how much time Atom spends in building menus and assigning keystrokes, but I’d bet it’s not as much as initializing core parts of plugins. Obviously plugins that affect the behaviour of buffers as they are created would probably need to be fully loaded at startup time in most cases, but the ones that provide extra functionality via menus and specific keystrokes may wait until the user requires them.

This said, I think that the Facebook team that works on Nuclide is already striving to make the package as fast as possible and already implements this “good practice”. However there are possibly other modules out there that just bring up the code, initialize and sit down waiting for the user to say hello.