No, recent patch increased the limit to blazing 4 MEGABYTES!

Yeah this is crazy. I regularly work with log files in the 100mb to 300mb range which open perfectly fine in Vim/Sublime. If I had to invest time in learning Atom I'd have to multitask between editors for certain use-cases. Maybe if they could switch to a light-weight read-only type of text "viewer" for large files, that would even work. But I really do need to open big files on a weekly basis.

Do you really want to open log files in a code editor? It's not unreasonable to say that these are two different classes of programs, with different basic requirements.

I find this to be a really tired discussion/response that pops up whenever new software comes around.

"X doesn't do Y" "Did you really want Y"?

Of course they do, they just complained about it.

> It's not unreasonable to say that these are two different classes of programs, with different basic requirements.

But it is reasonable to hold a piece of software up to standards set by the majority of other software in the same realm. Other text editors can open log files, this one probably should be able to, too.

> "X doesn't do Y" "Did you really want Y"?

> Of course they do, they just complained about it.

It's just a rhetorical way of saying "I don't understand why that is a problem", and a request for explanation. I would say that's a pretty reasonable response to "I found this is a problem".

I've been opening log files in either vi, notepad++, or sublime text for as long as I can remember. I've never had any issues accomplishing exactly what I needed. You insinuate that's a bad thing without providing any examples or solutions that are "better", so I can only assume your rationale is: My tool is awesome even though it doesn't fit your requirements, so you should change your requirements.

I definitely don't mean to insinuate it's a bad thing, but for me it is not a core requirement. Atom is supposed to be a code editor, and it's no hardship to use a different program for opening non-code text files. I actually find native text editors (I've tried Scratch and Gedit) don't work better than Atom for largish text files of a megabyte or thereabouts, so it's clearly a relatively common issue with editors which are built on the assumption you're going to be looking at smaller files. If the Atom devs manage to write the code which will allow these files to be handled, great, but in the meantime the program remains excellent for editing code.

I do not understand the need to separate a "code editor" from a text editor. What is code before it is interpreted or compiled? Text.

I do not object to the existence of Atom -- it scratches some people's itches, so that's fine -- but I do not buy "it's supposed to be a code editor" as enough of a justification for using it versus other text editors.

Not really, in my mind it should be the expectation that in 2015 we can use modern editing tools to open large files.

IMO the fact that vim is so versatile is part of the reason it has come so far.

A code editor that doubles as a text editor is major benefit, especially if you're needing to consume logs while testing.

Atom is a text editor and logs are text files that may need to be edited. It's not unreasonable to expect a text editor to be able to open the various text files littered through a system, and it obviously is a problem to a lot of people. I know that for me personally, I sometimes end up wanting to mangle logs in ways where grep falls short and stream editing with sed or awk is either more cumbersome than using the various tools at my disposal in vim, or just beyond my understanding of these tools.

I can open larger files with emacs, nano, vim, nvi, ed etc., so I think that it's fair to say that the limited buffer size plaguing Atom is a solved problem generally. Somehow it has a built-in package manager, but falls short of ed on very basic text editing facilities.

Without code highlighting though, if I remember correctly. I don't see myself editing a >2MB file containing code, but still...

Code? Sure, probably not. But JSON? Certainly I've come across requests with more than 2MB of JSON.

(You might consider it an abuse of the format, but it is not completely without reason.)

ST3 (well, the plugin for doing it) breezed through prettifying and un-prettifying of the data.

how about something like sqlite3?

https://www.sqlite.org/download.html

shows the amalgamation, which is the main thing you'd build, having a 5.4 MB sqlite3.c file. I can easily see someone making a change to it if they wanted slightly different behavior - or to consult it for canonical behavior - and I was pleased I could glance through it in Sublime.

People editing files longer than that are certainly in the minority.

Of course, but if you find yourself in one of these instances of editing a large file (search and replacing database dumps is a common use case for me), you'll be disappointed. It's easy to argue that should be left to command line tools, but ST3 actually does a pretty good job at this.

Unless it's a CSV. Or XML. Or JSON, Or <insert another popular format>

I severely doubt that. You don't edit them every day, but:

1) It comes up sometimes, and your editor should cope 2) Having a hard file size limit so low is (to me) indicative of you doing something wrong.

They've removed the hard limit on this, but the app will still lag or freeze on large files. Sublime is much, much smoother on a 10mb file for example.

No. See these release notes: https://github.com/atom/atom/releases/tag/v0.208.0

Handy tip: If you ever have a really large file to edit, Textwrangler is awesome. I've opened 1GB SQL dumps in there, and it happens almost instantaneously -- with syntax highlighting. Strangely, BBEdit and Sublime Text took longer to open the same files.

I've not tried Textwrangler, but for the 100 MB or so XML files that are the project definition for the primary system I support, Ultraedit works well.

This has been improved and no longer has this limit. However, I still find Brackets more responsive in general and is what I still use mostly.

I think the future has a lot of potential though, as Visual Studio Code has demonstrated you can indeed have a very responsive editor built on javascript.