Why do all threads about Atom seem to be full of people opening huge files with text editors? I've never had performance issues with Atom with a 2013 MBA.
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 :)
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.
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 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.
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.
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.
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.
