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

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

SOAP dependency?

No, just data definitions used by the application. Most of it uses generated parsers and serializers but we still need to manually edit the files now and then.

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

Right. I think this is the point that people are really making.

Right now, Atom is just too slow when compared with other editors such as Sublime. Given enough time it shouldn't be an issue (maybe), but right now I think it's a huge pain point for a lot of devs.

I'm not sure I can think of any editor that's as laggy as atom.

In all fairness though: I wouldn't notice 99% of the time, and I can well imagine that this problem will disappear with time.

Emacs' performance can be pretty damn bad sometimes, but I don't use Atom enough to know their relative positions.

I just switched back to emacs from testing atom for a few weeks, and my biggest issue with it was the speed in opening files from a closed client. emacs deals with it by daemonizing emacs-server, atom deals with it by trying to be performant, but failing. In this day and age, i'd rather sink some cheap memory and keep the daemon running.

If atom has a daemon feature that I never found, or one upcoming, I'd consider it again. Until then my workflow involves too many client closes for me to not notice the significant delay that atom has when opening a new file.

I feel like daemonizing Emacs should be the default. I can happily add random stuff to my init.el which causes it to take a little while to cold start, but I never see a cold start so from my perspective Emacs is instantaneous for editing a random file. I keep hundreds of files open at all times and never have an issue with performance. I just go through and prune my open buffers once a month or so, for organizational reasons more than resource usage.

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.

Why are you opening log files with a text editor?

If you are looking for unusual conditions, scanning through visually is sometimes easier than it would be to try to grep for the particulars of an entry, especially if you don't know the particulars of the unusual condition yet.

Some editors with "minimap" functionality (Sublime Text and Emacs that I'm aware of, maybe others) can give you a fairly good visual overview of large swaths of a file at once. Sometimes strange entries are obvious just because of the shape of the line and in those cases the minimap makes it easy to see when something unusual is happening.

Please enlighten us.

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

How often do you find yourself editing a 2MB file of code? If the answer is "often", I'd strongly suggest refactoring.

Never code, but data, all the time. I write scrapers and such that produce MBs worth of output text. For quick hacks, large text files are great. I even drop large binaries into my text editor just to search for a string sometimes (easier than opening up a cli to strings | grep). At my job I frequently work with XML files measuring 100+MB, I didn't make that design choice, but I gotta work on it now.

OK! Let's refactor this 2MB file!

Wait... we kind of need a text editor that can open the file, don't we?

I frequently find myself sifting through dozens or hundreds of megabytes worth of data. Sublime handles it just fine, FWIW.

I often use ST to analyse some log files. Do you have any other tooling suggestions besides the command line with grep/awk/... ?

Not really, no. I can't say I've ever used a text editor to search a huge log file in that way.

It is rather large to be editing by hand.

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.

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.

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.