Atom now using Io.js

atom-shell absolutely has made the switch to io.js, that's where Atom's node comes from.

Regular expressions are not the way to do syntax highlighting yet many of the popular editors do it this way. Create a super huge string in vim, textmate or sublime text and watch it blow up. Then try it in Xcode or Intellij and see that there is no problem. The reason for Xcode and Intellij's fast syntax highlighting is because these do not use regular expressions, they use a lexer. They're examining the text one character at a time with some amount of forward and backward looking state and building the syntax highlighting and smart completion/features that way. As long as your editor is using regular expressions for syntax highlighting this will be a problem for you.

> Moore's Law should apply, and eventually processing power should catch up. I think we'll see the 2MB limit removed by 1997/1998.

That's a nice summary on the quality on web technologies.

2009: "Hey guys, we can now draw on a widget; we called it Canvas!"

2011: "Wow, look at this cool OpenGL wrapper that locks up your system in ways VoodooFX didn't manage to do in 1998! But you can use it on your web site, which is what people want, right, guys?"

Because no one wants to use a laggy text-editor, it doesn't matter how sleek and hip it is if they can't fix that.

It depends on your usage. Sure, source files are (hopefully) not going near that size, but many people regularly open multiple-MB log files or data files.

Also, for me at least, it's the principle of the thing -- we are talking about a measly few MB of text; if you can't even open that, IMO something has gone horribly wrong.

Today I learned that in 2015 a 2MB text file is "huge."

99% of the files I open are less than 2MB, but every once in a while I have a large file to open. I think this is typical.

VisualStudio handles them instantly, but even Sublime Text seems to take a bit of time "processing" it.

The C++ project I'm working on at the moment has many dozens of 1Mb header files. Its very frequent for source files to go past the two megabytes mark. Splitting these files is no option either; there are over three thousands of them and compilation times are slow enough already (many hours without distributed build systems).

As for data files, we have XMLs (yeah, I know..) over 50Mb in size.

Atom is a long way from supporting such projects. This probably doesn't apply to most web projects, but 2Mb is far from a huge file :)

Even my ~10 kb files syntax highlighting & scrolling lags on a computer where I play Battlefield 4 at almost highest settings.

Why do all threads about Go seem to be full of people who cannot live without generics?

Snark aside, feature X is rarely absolutely needed (you can replace your generics by some boilerplate; you can use grep instead of your text editor to process huge files), but in some cases it can make your work significantly easier and that's why people want it.

In my own case, opening video files in Sublime and having the hex and ASCII side-by-side made my job significantly easier when I was writing a parser. I could easily select portions of the data (e.g. an embedded metadata), annotate it with comments from the spec, then paste it in a unit test.

I have Atom installed, but see no reason to migrating since Sublime works well enough. My only concern is that the Sublime package ecosystem will likely start rotting now that Sublime itself is essentially abandonware, so at some point I might need e.g. autocompletion for Typescript and the best package will be on Atom, not Sublime.

Atom chugs even with small files, at least when compared to Sublime.

I like that my editor can edit hex and it doesn't barf if I give it a giant file. But yea, it's only maybe once a year I open a file that big.

Seriously. 2MB files have to be doing it wrong. Right?

Ever need to peek inside a browserify'd bundle with inline source maps to check transformations (e.g. 6to5)? Those can easily be over 2MB.

The 2MB/slowness isn't something that can just be "coded away". It's a direct result of the technology stack chosen. It is not a solvable problem. Therefore Atom cannot succeed beyond niche usage.

It needs to be amazing at something though.

And well... it isn't. The biggest thing I can tell is that it's "hip". Meanwhile Sublime Text spins around it at 40MPH doing donuts.

I tried. I really tried to use Atom. But the text editor is just so slow and unresponsive, and that is a flat out dealbreaker for a text editor. Its extensibility isn't any better than Sublime's, and I feel like Python's a way better language than Javascript, so I'm happier tooling against Sublime.

I too wish Sublime Text was open source, coming from an open source development background, but I understand exactly how hard it is to develop open source software and feed and clothe yourself - people only buy "support contracts" for the first year and rarely renew, and only for software they feel is technically complex enough that they might actually need help or customizations.

For the record, I also backed GNOME Builder (which I also already find superior to Atom) in the hopes of some day it becoming the text editor and development environment I lust after. But my greatest fear is that more time will be spent on the shiny features and not enough time on the things I really care about like a decent GUI debugger so I don't have to live with poking at GDB, ahead-of-build compiler warnings/errors, and code refactoring tools.

Sublime Text. I've used it for files > 2GB and it seems to handle them fine.

vi, nano, micro emacs, vim, emacs, gedit, geany, Kwrite, Kate, notepad++, sam, acme

I haven't looked at it for long, but as I remember it could help if there was a visualized for those files. Often it's a png, a jar, it would be less frustrating if it could open anyway, just in the right editor?

What do you define as a large file?

For example Atom seems to think a 2 MByte file is large.

I personally think 100 MBytes files are quite large.

But some users with massive log files consider Giga Byte files as being large.

On the mac BBEdit is incredible. A several hundred MB log file will bring Sublime Text to it's knees, and BBEdit has no problems at all. +1

Thank you for this! I was a little confused.

if i read this correctly, even 6to5 supports 77% of ES6, which is interesting.

too bad its taking so long, i cant wait until full support comes to browsers

This doesn't explain it, why do you need to compile ES6 at run-time? Plugin authors should compile before distributing.

This would annoy me as a user, I don't care that you really want the await/async feature. ES5 is not that bad. It's not like the difference between Lua and Vimscript. Just use ES5 or compile your ES6 prior to distributing.

This is bigger news for io.js than it is for atom. <<< I think is the lede.

Why would the io.js team bother merging their changes "upstream" to Node? io.js has momentum and mindshare.

I would not think the merge back is going to happen. The longer they separate, the more unlikely (and apparently harder) for them to merge

It's for plugins: https://github.com/atom/atom/pull/5299