3 ms·

To be fair, only very large text files trouble Atom. And when does any dev ever actually open massive text files in text editors. I'm a Vim guy and have only br

To be fair, only very large text files trouble Atom. And when does any dev ever actually open massive text files in text editors. I'm a Vim guy and have only briefly tried Atom, but I still wouldn't dream of opening a huge text file in Vim, even though it would cope a lot better than Atom. If it's a log file or something I'm going to be using tail/grep etc. to deal with it. Yeah exactly emacs is hackable if you want to write lisp, which has a very small audience. So sure there is absolutely a desire for an editor written in a 'nice', hackable language like Python or JS (forgive me JS haters) to prosper.

comex 11y ago
Depends on your definition of huge. On my computer, vim takes about a second to load a 100MB text file, 1.4 million lines - not as fast as less (although less's search feature is slower). Vy's slower but it appears to load the file asynchronously, so at least you can start browsing while it's doing that. But 100MB is fifty times the sibling comment's 2MB for Atom... For the record, while Python's pure interpreter is always going to be slow at this type of thing, JS's overhead factor compared to C is small enough that it's certainly possible to write an editor in it that feels just as fast as vim - maybe faster in some cases, e.g. since JavaScript engines JIT compile regexes and C regex libraries generally don't, or by making relatively slow operations asynchronous/multithreaded (while vim is highly synchronous). Atom seems to be just badly designed.
- coldtea 11y ago
  >Atom seems to be just badly designed. I think the problem with Atom speed is using the DOM / web stack, not Javascript itself.
griffinmb 11y ago
Atom's filesize limit is 2MB, so it's not really 'massive.' When I was using it, I ran into that limit more often than I would have expected. Mostly when taking a peak at a db dump, or misc files from the odd CTF challenge.

comex 11y ago

Depends on your definition of huge. On my computer, vim takes about a second to load a 100MB text file, 1.4 million lines - not as fast as less (although less's search feature is slower). Vy's slower but it appears to load the file asynchronously, so at least you can start browsing while it's doing that. But 100MB is fifty times the sibling comment's 2MB for Atom... For the record, while Python's pure interpreter is always going to be slow at this type of thing, JS's overhead factor compared to C is small enough that it's certainly possible to write an editor in it that feels just as fast as vim - maybe faster in some cases, e.g. since JavaScript engines JIT compile regexes and C regex libraries generally don't, or by making relatively slow operations asynchronous/multithreaded (while vim is highly synchronous). Atom seems to be just badly designed.

coldtea 11y ago
>Atom seems to be just badly designed. I think the problem with Atom speed is using the DOM / web stack, not Javascript itself.

griffinmb 11y ago

Atom's filesize limit is 2MB, so it's not really 'massive.' When I was using it, I ran into that limit more often than I would have expected. Mostly when taking a peak at a db dump, or misc files from the odd CTF challenge.