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.
> 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.
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.
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.
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.
