I rarely open gigabyte single-line files, but when I do, I don't want to switch editor.

Most of the time I only realize that everything is on a single line after opening the file.

A good editor doesn't require me to think about these things.

Sure. I'd not be able to actually do anything useful with a gigabyte single-line file so what I'd want my editor to do is say "Longest line is over 100k characters, truncating display to the first 100k".

issue is that the editor can't tell if it's a multiline file with a first big line or an editor with one big line if it's cut at the first line. But I'd rather have the editor bail at the first 100k line than not opening it.

I would rather open it in editor, strike a "reformat all" shortcut, and have the file right there.

I don't want to chase separate tools that can format different text files, that's what editors are for.

It's still annoying if your editor hangs and you have to find some way to kill it before your computer becomes usable again.

Sure, but this one isn't 10% faster on gigabyte multiline text. Others in this thread are testing wrapped text and Ox still chokes.

99% of files I work with are <1000 lines, so I don't mind. For larger files I will fall back to Vim.

The important thing to realize is that text editor performance is less about the technology used and more about the data structures and i/o.

This is not an excuse for an editor being claimed "fast". Textadept is written in C and is also very fast but has the exact same issue -- choking on huge files when Vim and others are able to handle it.