4 ms·

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

by romanovcode 11y ago

hugozap 11y ago
People editing files longer than that are certainly in the minority.
- neverminder 11y ago
  Unless it's a CSV. Or XML. Or JSON, Or <insert another popular format>
- debaserab2 11y ago
  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.
- SCdF 11y ago
  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.
andreamazz 11y ago
Without code highlighting though, if I remember correctly. I don't see myself editing a >2MB file containing code, but still...
- eterm 11y ago
  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.
- logicallee 11y ago
  how about something like sqlite3? https://www.sqlite.org/download.html 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.
laichzeit0 11y ago
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.
- Brakenshire 11y ago
  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.
  - bduerst 11y ago
    A code editor that doubles as a text editor is major benefit, especially if you're needing to consume logs while testing.
  - smrtinsert 11y ago
    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.
  - tw04 11y ago
    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.
    - Brakenshire 11y ago
      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.

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

hugozap 11y ago

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

neverminder 11y ago
Unless it's a CSV. Or XML. Or JSON, Or <insert another popular format>
debaserab2 11y ago
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.
SCdF 11y ago
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.

andreamazz 11y ago

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

eterm 11y ago
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.
logicallee 11y ago
how about something like sqlite3? https://www.sqlite.org/download.html 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.

laichzeit0 11y ago

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.

Brakenshire 11y ago
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.
- bduerst 11y ago
  A code editor that doubles as a text editor is major benefit, especially if you're needing to consume logs while testing.
- smrtinsert 11y ago
  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.
- tw04 11y ago
  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.
  - Brakenshire 11y ago
    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.