True, but as a programmer i very often generate and need to view files greater than 2MB.
Not to mention log files which commonly consume megabytes.
You shouldn't open log files with an editor unless your intent is to edit the file. There are a whole host of tools (grep, less, awk, sed, etc) useful for parsing and exploring log files.
Insisting on all tools having an X because X is a useful thing is how you get the very bloat the GP is talking about.
The limit came about because trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. It was just a hard problem to solve, having an HTML-based editor deal with so much text at once.
I'd love to test that. Anyone willing to privide an example file? HTML with css perhaps, no js. Should be pretty small when zipped.
Here's a 100MB HTML file (compressed to 300KB): https://curl.io/get/yt7zbmfq/0eb1564f570236acf1d9f304855a7c7...
As a side note, VIM opens it in an instant /troll
I remember opening HTML files in that size range (they were logs) in IE6 around a decade or more ago, on a machine with <1GB of RAM, and it handled them just fine - there was a noticeable delay, but it wasn't unusable. Even searching for strings worked.
So, it makes sense to me that they would assume only "human sized" data (and expect users to use another tool for looking at large files, "do one thing well" and all that) and opt for a slightly simpler programming model. Apparently, they decided that the assumption was wrong, and so changed the model.
https://github.com/atom/atom/commit/ec65a71d6dc8c3c44cb1b77a...
If I have 64GB of RAM, I expect my applications to be able to use all of it when asked to, and not just give up completely. It's fine to slow down, and giving a warning "Opening large files may be slow. Do you want to continue?" would be nice, but working with a 2097151-byte file and giving up if it's 2097152 bytes is really unpleasant.