Comment by 0x1ceb00da

The problem with long lines was reportedly markedly improved in Emacs 29:

Emacs is now capable of editing files with very long lines. The display of long lines has been optimized, and Emacs should no longer choke when a buffer on display contains long lines. The variable 'long-line-threshold' controls whether and when these display optimizations are in effect.

A companion variable 'large-hscroll-threshold' controls when another set of display optimizations are in effect, which are aimed specifically at speeding up display of long lines that are truncated on display.

If you still experience slowdowns while editing files with long lines, this may be due to line truncation, or to one of the enabled minor modes, or to the current major mode. Try turning off line truncation with 'C-x x t', or try disabling all known slow minor modes with 'M-x so-long-minor-mode', or try disabling both known slow minor modes and the major mode with 'M-x so-long-mode', or visit the file with 'M-x find-file-literally' instead of the usual 'C-x C-f'.

In buffers in which these display optimizations are in effect, the 'fontification-functions', 'pre-command-hook' and 'post-command-hook' hooks are executed on a narrowed portion of the buffer, whose size is controlled by the variables 'long-line-optimizations-region-size' and 'long-line-optimizations-bol-search-limit', as if they were in a 'with-restriction' form. This may, in particular, cause occasional mis-fontifications in these buffers. Modes which are affected by these optimizations and by the fact that the buffer is narrowed, should adapt and either modify their algorithm so as not to expect the entire buffer to be accessible, or, if accessing outside of the narrowed region doesn't hurt performance, use the 'without-restriction' form to temporarily lift the restriction and access portions of the buffer outside of the narrowed region.

The new function 'long-line-optimizations-p' returns non-nil when these optimizations are in effect in the current buffer.

— <https://www.gnu.org/software/emacs/news/NEWS.29.1>

Right- but if you have a long line that is, for example, a JSON object, then surely it can't be properly be validated or syntax-highlighted before the entire line is scanned?

I do agree that Emacs can be slower than the terminal when handling long lines/files, although (depending on your case) this can be easily mitigated by running a terminal inside of Emacs.

Generally though, for everyday use, Emacs feels a lot snappier than VSCode.

Not every modern editor. Neovim bogs on long lines too.

The long-line issue is real, though my statement was specifically about building UIs with widgets/overlays/text properties - not handling arbitrary files. In that context, Emacs's display engine is genuinely well-optimized: it handles overlays, faces, text properties, and redisplay regions efficiently.

When you're building a UI, you control the content. Lines are short by design (form fields, buttons, lists). The pathological case of a 50KB minified JSON line simply doesn't occur.

The long-line problem stems from how Emacs calculates display width for bidirectional text and variable-pitch fonts - it needs to scan the entire line. That's orthogonal to rendering widgets or interactive buffers.

The buffer is the UI, rendered by Emacs's extremely optimised text display machinery

The author is known in the community as a mere packager whose knowledge of the nitty-gritty derives entirely from hearsay. Perhaps he read the long-winded preamble to xdisp.c written in 1995 boasting of all manner of optimisations. But they were written so long ago, almost no one believes most of them matter anymore, what with thirty years of bitrot.

https://emacs.stackexchange.com/questions/598/how-do-i-preve... has some answers (and solutions).