I learned that not all text editors go to the effort of loading the file data very carefully with careful underlying data structures when I tried to open a 67K LOC COBOL file on a 32bit system, a while back. (Sidenote: COBOL has a 999,999 LOC hard limit in the compiler spec.)

So very many editors just couldn't open it.

Some would use so much memory that the system would either freeze, or the OS would kill them.

Some would silently truncate at 65,535 lines.

Some would produce a load error.

Some would pop up with an error indicating the developer thought it was an unreachable state. e.g. "If you're seeing this error... Call me. And tell me how the fuck you broke it."

Others would manage to open it, but were completely unuseable. Where moving the cursor would take literal minutes.

There were exactly three editors I found at the time that worked (none of which were graphical editors). And they worked without any increased latency, letting you know that the developers just thought through what they were doing: vim, emacs, nano.

(A few details because people are probably curious - the vast majority of that single file project was taxation formulae. It was National Mutual's repository of all tax calculations for every jurisdiction that they worked in, internationally, for the entire several hundred years of the company. They just transcribed all their tax calculation records into COBOL.)

Emacs is actually quite poor at opening large files, at least comparatively—depending on the machine, 65K lines may be enough. However, there's an addon, i.e. a ‘mode’, that implements editing of large files somehow.

Vim, on the other hand, does it splendidly: it keeps only a chunk of the text in memory, and iirc the ‘swap file’ that it creates for every opened file, keeps the changes in some kind of a sparse structure, so they can be tracked at various places in the original file. This ‘swap file’ also serves as a savepoint of the editing session, so the changes can still be recovered even if the machine crashes while the user never saves.

Alas, editors still tend to deal badly with very long lines (just in the low thousands characters). IIRC both Emacs and Vim drop into a big think if the user attempts to put the cursor further down that line.

> Emacs is actually quite poor at opening large files, at least comparatively—depending on the machine, 65K lines may be enough. However, there's an addon, i.e. a ‘mode’, that implements editing of large files somehow.

Yeah, essentially this (apparently) mostly occurs when the file has no newlines (like json often does). I think the hacks are around turning off font-lock mode and one or two other things (install long-lines-mode if this is a problem you're having).

This is probably the most current implementation of a ‘view large files’ package: https://github.com/m00natic/vlfi