[icebraining]

Yeah, hexdump shows:

    00000000  ef bb bf 2f 3e c2 a0 0a  20 20 20 20 20 20 20 20
    00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
    *
    00900000  20 20 20 20 20 20 20 20  3c 61
    0090000a

Which means that except for those first 8 bytes and the last two, the whole file is just 0x20 (space in ASCII/UTF-8) repeated ad nauseam.

[gnator]

Why would long lines crash editors?

[icebraining]

Well, VIM doesn't crash :) But edge cases in general are where the bugs lurk, and 9MBs of spaces is certainly an edge case. A possible cause might be that they try to render the whole line, try to allocate too much memory, and crash when the allocation fails. Whereas if the file had many lines, they'd probably be smart enough to only render part of it.

[pwg]

If the editor has some built in line length limit then exceeding that limit might lead to a crash (depending upon how the editor is coded).

[gnator]

Right but it looks like (i was able to load it for Atom and Notepad++ but very slow) they perform soft wrap on these long lines

[pwg]

Which would imply that their soft-wrap algorithm consumes an inordinate amount of time when confronted with a single, 9MB long, line of space characters.